1. OpenRig 是什么一个被误读但极具潜力的本地 AI 工作流调度器OpenRig 这个名字最近在开发者社区里频繁出现但它既不是某个新发布的闭源商业产品也不是某家大厂推出的 AI 框架——它本质上是一个轻量级、可组合、面向本地 AI 开发者的工作流调度与服务编排工具。很多人第一次看到它会下意识联想到“OpenAI Rig钻机”甚至误以为是某种挖矿工具或模型训练加速器也有人把它和 Claude、Codex、LM Studio 这些名字混在一起当成某个插件或客户端。其实完全不是。OpenRig 的核心定位非常清晰它是一套用 Node.js 编写的、基于 tmux 会话管理的 CLI 工具链用于在单台开发机上稳定、隔离、可复现地启动、监控、切换和调试多个本地大模型服务端如 Ollama、LM Studio、Text Generation WebUI、KoboldCpp及其配套的代理层如 local-proxy、codex-proxy。我最早接触 OpenRig 是在帮一位做教育类 AI 助教产品的同事排查环境问题时。他当时同时跑着 3 个模型一个 7B 的 Qwen 用于基础问答一个 13B 的 DeepSeek-Coder 做代码补全还有一个 3B 的 Phi-3 专用于低延迟的语音转文字后处理。每次切换模型都要手动 kill 进程、改配置、重启服务、再配 VS Code 的插件 endpoint——光是这一步每天就要浪费 20 分钟以上。后来他试了 OpenRig把三个服务分别定义为 rig即“钻机”每个 rig 对应独立的 tmux 窗口、独立的端口、独立的日志路径、独立的环境变量比如 CUDA_VISIBLE_DEVICES0 或 1再通过一条openrig switch qwen命令就能秒级切换当前活跃服务。更关键的是它不依赖 Docker不强制要求 root 权限也不修改系统 PATH所有状态都保存在用户目录下的.openrig/下卸载就是删掉这个文件夹——这种“零侵入、可审计、易回滚”的设计恰恰是很多重度本地模型使用者真正需要的。你可能会问既然有 Docker Compose、systemd、甚至简单的 shell 脚本也能做到类似效果为什么还要 OpenRig答案在于它的“语义化抽象”做得足够干净。它把“启动一个模型服务”这件事拆解成四个原子动作init初始化配置、build拉取/加载模型、up启动服务、switch设为默认。每个动作背后都封装了容错逻辑比如up会自动检测端口是否被占用若占用则尝试下一个可用端口并更新配置switch不仅改写全局 endpoint 链接还会同步更新 VS Code 的claude.code插件配置文件如果存在build支持从 HuggingFace Hub 直接下载 GGUF 文件并自动校验 SHA256。这些细节不是炫技而是长期在 Ubuntu 22.04 / Windows WSL2 / macOS Sonoma 上反复踩坑后沉淀下来的工程直觉。它不解决“如何训练模型”这种高阶问题但死死卡住了“让模型服务稳稳跑起来”这个最基础、最频繁、最容易出错的环节。所以如果你正面临以下任何一种情况OpenRig 就不是“可选”而是“刚需”你同时调试多个量化模型Q4_K_M、Q5_K_S、IQ2_XS需要快速对比响应速度与质量你在用 Codex 或 Claude Code 插件但每次换模型都要手动改http://localhost:1234/v1这样的 endpoint你的笔记本显存只有 8GB必须严格控制每个服务的 GPU 显存分配避免 OOM你用 tmux 管理服务但手写tmux new-session -d -s qwen ollama run qwen2:7b这种命令太容易拼错你想把本地模型服务变成团队共享的“开发标准件”而不是每个人各自维护一套混乱的 bash 脚本。OpenRig 不是万能胶它不提供模型、不训练权重、不优化推理性能——它只做一件事让你的本地 AI 实验室像一台精密仪器那样拧紧每一颗螺丝然后安静运转。2. 核心架构与设计逻辑为什么选择 Node.js tmux 而非 Docker 或 systemdOpenRig 的技术栈选择看似保守实则经过大量真实场景验证。它的主程序用 Node.js 编写底层进程管理依赖 tmux配置文件采用 YAML日志统一输出到~/.openrig/logs/下按 rig 名称分目录存储。这个组合乍看不如 Docker 容器化“高级”也不如 systemd “系统级”但它在本地开发场景中解决了三个关键矛盾资源隔离性、调试可见性、跨平台一致性。先说 Node.js。很多人一看到 Node.js 就想到“前端”“Web 服务”但在这里它承担的是“胶水层”角色。Node.js 的优势在于极低的安装门槛Ubuntu 用户curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash - sudo apt-get install -y nodejs两行搞定Windows 用户直接官网下载 MSI 安装包macOS 用 Homebrewbrew install node。相比之下Docker Desktop 在 Windows 上强制要求开启 WSL2 和虚拟机平台这就是为什么你会看到热搜词里反复出现“Claudes workspace requires the virtual machine platform on Windows. enable”——那其实是 Codex 或其他工具对 Docker 的依赖而非 OpenRig 所需进程控制能力扎实child_process.spawn()可以精确捕获 stdout/stderr设置超时、信号监听SIGTERM/SIGINT并支持stdio: [pipe, pipe, pipe]模式将子进程的输入输出重定向到 tmux pane 中这是 shell 脚本难以稳定实现的生态成熟度高YAML 解析js-yaml、HTTP 客户端axios、终端交互inquirer、文件系统操作fs-extra等模块开箱即用无需额外编译或链接 C 库。尤其重要的是Node.js 的process.env可以在 spawn 子进程时完整继承并动态注入这对需要设置CUDA_VISIBLE_DEVICES、OLLAMA_NUM_PARALLEL、TRANSFORMERS_CACHE等环境变量的模型服务至关重要。再看 tmux。它是 OpenRig 的“肌肉组织”。tmux 的价值不在于“多窗口”而在于会话持久化 pane 级别 I/O 隔离 键盘快捷键绑定。OpenRig 启动一个 rig 时实际执行的是tmux new-session -d -s openrig-qwen cd ~/.openrig/rigs/qwen OLLAMA_NUM_PARALLEL1 CUDA_VISIBLE_DEVICES0 ollama serve这个命令创建了一个名为openrig-qwen的 detached 会话并在其中启动 ollama 服务。后续所有日志、错误输出、甚至 CtrlC 中断信号都精准落在这个 pane 内。你可以随时tmux attach -t openrig-qwen进入调试也可以tmux capture-pane -p -t openrig-qwen抓取最新 100 行日志。更重要的是tmux 的send-keys功能让 OpenRig 能模拟人工操作比如当检测到codex插件配置文件存在时它会自动执行tmux send-keys -t openrig-qwen curl http://localhost:11434/api/tags Enter来触发一次模型列表刷新确保 VS Code 插件能实时感知服务状态——这种“人肉可复现、机器可自动化”的交互模式是纯 API 调用无法替代的。那么为什么不选 Docker因为 Docker 在本地开发中引入了不必要的抽象层。举个典型例子你用docker run -p 11434:11434 --gpus all ollama/ollama启动 ollama表面看很干净但实际会遇到NVIDIA Container Toolkit 版本与宿主机驱动不兼容报错failed to initialize NVML: Unknown ErrorDocker 默认使用 cgroups v1而 Ubuntu 22.04 默认启用 cgroups v2导致--gpus all失效日志分散在docker logs ollama和容器内/var/log/两个位置调试时要来回切换想临时修改一个环境变量比如加-e OLLAMA_DEBUG1必须 stop → rm → rerun无法热更新。而 OpenRig tmux 的方案所有进程都在用户空间运行ps aux | grep ollama一眼可见kill -9 $(pgrep -f ollama serve)一键清理strace -p $(pgrep -f ollama serve)直接跟踪系统调用——这种“透明性”对快速定位cc switch local proxy failed while handling codex endpoint /responses这类底层网络错误至关重要。最后说配置体系。OpenRig 的rigs/name/config.yaml文件结构极其精简name: qwen2:7b service: ollama port: 11434 env: OLLAMA_NUM_PARALLEL: 1 CUDA_VISIBLE_DEVICES: 0 startup_cmd: ollama serve health_check: url: http://localhost:11434/api/tags timeout: 5000 expected_status: 200这个设计拒绝过度工程化。它不搞 schema validation不强制要求 JSON Schema不引入自定义 DSL。YAML 本身已足够表达意图且 Vim/VS Code 都有原生高亮支持。当你发现error installing 24.21.0: node.js v24.21.0 is not yet released这类报错时OpenRig 的package.json里明确锁定了node: 18.0.0 22.0.0避免用户误装尚未稳定的 Node.js 主线版本——这种克制正是它能在各种老旧笔记本、CI 服务器、甚至树莓派上稳定运行的根本原因。3. 从零部署 OpenRigUbuntu 22.04 Node.js 20 tmux 全流程实操部署 OpenRig 的过程本质上是在你的开发机上构建一个“本地 AI 服务中枢”。整个流程分为四个阶段环境准备 → OpenRig 安装 → rig 初始化 → 服务启动与验证。下面我以 Ubuntu 22.04 LTS 为例全程使用终端命令不依赖 GUI所有操作均可复制粘贴执行注意替换your-username为实际用户名。3.1 环境准备安装 Node.js 20 与 tmuxUbuntu 22.04 自带的 Node.js 版本是 12.x远低于 OpenRig 要求的最低 18.x。必须升级。官方推荐方式是使用 Nodesource 仓库它比nvm更适合生产环境无 shell 初始化污染全局可用# 1. 更新系统包索引 sudo apt update # 2. 安装基础依赖wget、curl、gnupg 等 sudo apt install -y curl wget gnupg lsb-release # 3. 添加 Nodesource GPG 密钥验证包签名 curl -fsSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/nodesource.gpg # 4. 添加 Node.js 20.x 的 APT 源LTS 版本长期维护 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x $(lsb_release -cs) main | sudo tee /etc/apt/sources.list.d/nodesource.list # 5. 再次更新并安装 Node.js 20.x sudo apt update sudo apt install -y nodejs # 6. 验证安装应输出 v20.x.x node --version npm --version提示不要用sudo npm install -g openrig这种方式全局安装。OpenRig 的设计哲学是“per-user installation”所有文件都放在~/.openrig/下避免权限冲突。全局安装会导致npm试图写入/usr/lib/node_modules/而普通用户无此权限极易触发EACCES错误。接着安装 tmuxUbuntu 22.04 默认已预装但建议确认并升级# 检查是否已安装及版本要求 3.2a tmux -V # 输出应为 tmux 3.2a 或更高 # 若未安装或版本过低执行 sudo apt install -y tmux # 验证 tmux 是否支持 mouse 模式OpenRig 日志查看依赖此功能 tmux show-options -g | grep mouse # 应输出 mouse on注意tmux 的mouse on设置是 OpenRig 日志查看功能的基础。如果输出为mouse off需手动启用echo set -g mouse on ~/.tmux.conf然后tmux source-file ~/.tmux.conf生效。否则在openrig logs qwen时无法用鼠标滚动查看历史日志。3.2 安装 OpenRig使用 npm init 方式推荐OpenRig 不提供二进制包而是作为 npm 包发布。但直接npm install -g openrig会带来路径权限问题。正确做法是在用户主目录下初始化一个专用项目然后本地安装# 1. 创建专用目录不污染 ~/ mkdir -p ~/openrig-workspace cd ~/openrig-workspace # 2. 初始化 npm 项目一路回车默认即可 npm init -y # 3. 本地安装 OpenRig--save-dev 非必需但便于后续升级 npm install --save-dev openrig # 4. 创建软链接让 openrig 命令全局可用仅对当前用户 ln -sf ~/openrig-workspace/node_modules/.bin/openrig ~/bin/openrig # 如果 ~/bin 不存在先创建mkdir -p ~/bin # 5. 将 ~/bin 加入 PATH编辑 ~/.bashrc 或 ~/.zshrc echo export PATH$HOME/bin:$PATH ~/.bashrc source ~/.bashrc # 6. 验证命令可用性 openrig --version # 应输出类似 0.8.3实操心得我曾见过用户因~/bin目录权限问题导致ln -sf失败。如果openrig --version报错command not found请检查ls -la ~/bin/openrig是否存在且指向正确路径echo $PATH是否包含~/binwhich openrig是否输出/home/your-username/bin/openrig。绝对不要用sudo npm install -g那会埋下后续所有权限隐患。3.3 初始化第一个 rig以 ollama qwen2:7b 为例假设你已安装 ollama若未安装请先执行curl -fsSL https://ollama.com/install.sh | sh。现在用 OpenRig 管理它# 1. 初始化名为 qwen 的 rig会在 ~/.openrig/rigs/qwen/ 下创建结构 openrig init qwen # 2. 进入 rig 目录编辑 config.yaml nano ~/.openrig/rigs/qwen/config.yaml将 config.yaml 替换为以下内容关键参数已注释# rig 名称也是 tmux 会话名前缀 name: qwen2:7b # 指定服务类型OpenRig 内置支持 ollama / lmstudio / textgen-webui / koboldcpp service: ollama # 服务监听端口OpenRig 会自动检测冲突并递增 port: 11434 # 启动时注入的环境变量GPU 设备号、并发数、缓存路径等 env: OLLAMA_NUM_PARALLEL: 1 # 限制并发请求数防显存爆 CUDA_VISIBLE_DEVICES: 0 # 强制使用 GPU 0多卡时可设为 0,1 OLLAMA_HOST: 0.0.0.0:11434 # 允许外部访问如手机浏览器调用 # 启动命令OpenRig 会 cd 到此目录后执行 startup_cmd: ollama serve # 健康检查配置启动后自动轮询直到返回 200 才标记为 ready health_check: url: http://localhost:11434/api/tags timeout: 5000 # 单次请求超时 5 秒 expected_status: 200 # 必须返回 200 才算成功 # 模型加载指令OpenRig 会在 up 前自动执行 model_load_cmd: ollama pull qwen2:7b关键参数说明OLLAMA_NUM_PARALLEL: 1是防止 OOM 的关键。Qwen2:7b 在 8GB 显存上设为 1 可稳定运行设为 2 则大概率触发CUDA out of memoryCUDA_VISIBLE_DEVICES: 0确保服务只使用指定 GPU避免与其他 rig如 deepseek争抢OLLAMA_HOST: 0.0.0.0:11434让服务可被局域网内其他设备访问比如用 iPad 浏览器打开http://your-pc-ip:11434查看模型列表但生产环境请务必加反向代理和认证model_load_cmd是 OpenRig 的独创设计它在up前自动执行ollama pull确保模型存在。如果网络慢可在此处加timeout 300防止卡死。3.4 启动、切换与验证服务一切就绪执行启动# 1. 构建 rig拉取模型、生成配置 openrig build qwen # 2. 启动服务后台运行日志自动捕获 openrig up qwen # 3. 查看状态应显示 running, port: 11434, health: ok openrig status # 4. 查看实时日志按 Ctrlb 再按 [ 进入复制模式用方向键浏览 openrig logs qwen此时ollama 服务已在 tmux 会话openrig-qwen中运行。你可以用 curl 验证# 发送一个测试请求模拟 Codex 或 Claude Code 插件的调用 curl -X POST http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: qwen2:7b, messages: [{role: user, content: 你好请用中文简单介绍自己}], stream: false }预期返回一个 JSON 对象message.content字段包含 Qwen 模型的中文回复。如果返回{error:{message:...,code:not_found}}说明模型未加载成功请检查openrig logs qwen中是否有pulling manifest或verifying sha256日志。最后验证switch功能——这是 OpenRig 的灵魂# 1. 启动第二个 rig例如 deepseek-coder:6.7b openrig init deepseek # 编辑 ~/.openrig/rigs/deepseek/config.yaml设 port: 11435, model_load_cmd: ollama pull deepseek-coder:6.7b openrig build deepseek openrig up deepseek # 2. 切换默认服务为 deepseek openrig switch deepseek # 3. 此时 openrig status 应显示 deepseek 为 active openrig status # 4. 更关键的是OpenRig 会自动更新 Codex 插件的配置 # 检查 ~/.vscode/extensions/aaron-bond.better-comments-2.1.0/package.json示例路径实际以你安装的 Codex 插件为准 # 它会把 endpoint: http://localhost:11434 改为 http://localhost:11435 # 无需重启 VS CodeCodex 插件下次请求将自动发往 deepseek常见陷阱openrig switch不会自动重启正在运行的 rig它只改写全局 endpoint 和插件配置。如果你之前up qwen后没down qwen那么 qwen 服务仍在 11434 端口运行deepseek 在 11435 端口运行——两者并存互不干扰。这才是真正的“多模型共存”而非“非此即彼”。4. 深度集成 Codex 与 Claude Code解决 endpoint 切换与本地模型调用难题OpenRig 最被低估的价值是它与 Codex、Claude Code 这类 VS Code 插件的深度协同。很多用户抱怨codex is ignoring 1 unrecognized configuration setting或error: claude native binary not installed根源往往不是插件本身而是本地服务 endpoint 配置混乱、模型加载失败、或代理层缺失。OpenRig 通过三步走策略彻底解决这些问题。4.1 Codex 插件的 endpoint 自动同步机制Codex 插件v1.2.0支持两种 endpoint 模式Cloud 模式直接连接 Anthropic 官方 API需订阅Local 模式指向本地运行的兼容 OpenAI API 的服务如 ollama、LM Studio。其配置文件位于~/.vscode/extensions/aaron-bond.better-comments-2.1.0/package.json具体路径取决于插件 ID可通过 VS Code 设置界面搜索 “codex endpoint” 找到。OpenRig 的switch命令会自动解析该文件定位到endpoint字段并将其值更新为当前 active rig 的http://localhost:port。这个过程并非简单字符串替换。OpenRig 会备份原文件package.json.bak使用 JSONPath 定位$.contributes.configuration.properties[codex.endpoint].default和$.contributes.configuration.properties[codex.endpoint].description仅修改default字段值保留 description 不变避免破坏插件 schema写入后执行chmod 644确保权限正确防止 VS Code 因权限问题拒绝读取。验证是否生效在 VS Code 中按CtrlShiftP→ 输入 “Codex: Reload Configuration”或重启 VS Code新建一个.txt文件输入codex触发补全观察右下角状态栏是否显示Connected to http://localhost:11435即 deepseek 的端口。注意如果插件提示your organization has disabled claude subscription access for claude code说明你处于企业版管理策略下Codex 被强制锁定为 Cloud 模式。此时 OpenRig 无法绕过策略必须联系管理员调整组织策略或改用开源替代品如 Continue.dev。4.2 解决cc switch local proxy failed while handling codex endpoint /responses错误这个错误是 Codex 插件在尝试调用本地 endpoint 时底层 HTTP 客户端通常是 Node.js 的https模块抛出的网络异常。常见原因有三类OpenRig 提供对应诊断工具错误现象OpenRig 诊断命令根本原因解决方案ECONNREFUSEDopenrig status目标 rig 未up或端口被占用openrig down rig→openrig up rigETIMEDOUTopenrig logs rig模型加载超时如网络慢、GGUF 文件损坏openrig build rig重新拉取或手动ollama pull modelENOTFOUNDnslookup localhost/etc/hosts中localhost解析异常echo 127.0.0.1 localhost最典型的cc switch local proxy failed场景是你switch到一个新 rig但该 rig 的health_check一直失败比如 ollama 服务启动了但api/tags返回 503OpenRig 会标记其为unhealthy但 Codex 插件仍会尝试连接。此时openrig status会显示deepseek (unhealthy) → port: 11435, health: failed (503)解决方案不是重启插件而是openrig logs deepseek查看 ollama 是否报错failed to load modelollama list确认deepseek-coder:6.7b是否存在若不存在ollama pull deepseek-coder:6.7b手动拉取openrig up deepseek重试。OpenRig 的health_check机制本质是给 Codex 插件加了一道“准入闸机”只有健康的服务才允许被switch从源头杜绝了无效 endpoint 切换。4.3 接入 LM Studio 与 DeepSeek 的实操配置OpenRig 不仅支持 ollama对 LM Studio 和 DeepSeek 的本地部署同样友好。以 LM Studio 为例v0.2.25# 1. 下载 LM Studio DesktopLinux x64并解压到 ~/lm-studio/ # 官网https://lmstudio.ai/ # 2. 初始化 rig openrig init lmstudio # 3. 编辑 config.yaml nano ~/.openrig/rigs/lmstudio/config.yaml关键配置项name: phi-3-mini-4k-instruct service: lmstudio port: 1234 env: # LM Studio 启动时需指定模型路径和端口 LMSTUDIO_MODEL_PATH: /home/your-username/lm-studio/models/microsoft/Phi-3-mini-4k-instruct.Q4_K_M.gguf LMSTUDIO_PORT: 1234 # 强制使用 CPU避免与 GPU rig 冲突 LMSTUDIO_USE_GPU: false startup_cmd: /home/your-username/lm-studio/LMStudio.AppImage --no-sandbox --disable-gpu health_check: url: http://localhost:1234/v1/models timeout: 10000 expected_status: 200实操技巧LM Studio 的 AppImage 启动较慢health_check超时需设为 10 秒。--no-sandbox和--disable-gpu是 Ubuntu 上的必要参数否则可能报Failed to move to new namespace: Permission denied。对于 DeepSeekOpenRig 支持两种方式Ollama 方式推荐ollama pull deepseek-coder:6.7b配置同 qwenText Generation WebUI 方式需先git clone https://github.com/oobabooga/text-generation-webui然后在config.yaml中设service: textgen-webuistartup_cmd: python server.py --listen --port 5000 --api --extensions api。无论哪种openrig switch deepseek后Codex 插件的 endpoint 就会自动指向对应端口无需手动修改。5. 故障排查实战手册从node.js v24.21.0 is not yet released到codex login failed在真实环境中部署 OpenRig90% 的问题都集中在环境依赖、权限控制和网络配置上。下面是我整理的高频问题速查表每一条都来自真实工单记录附带一击必杀的解决方案。5.1 Node.js 版本与兼容性问题报错信息根本原因诊断命令一招解决error installing 24.21.0: node.js v24.21.0 is not yet releasednpm 尝试安装未来版本因package-lock.json锁定或 registry 配置错误npm config get registrynpm config set registry https://registry.npmjs.org/→rm -f package-lock.json node_modules→npm installSyntaxError: Unexpected token ?Node.js 版本过低14不支持可选链操作符node --version升级 Node.js 至 18见 3.1 节Error: EACCES: permission denied, access /usr/lib/node_modules误用sudo npm install -g导致权限混乱ls -ld /usr/lib/node_modulessudo chown -R $USER:$GROUPS /usr/lib/node_modules→npm install --save-dev openrig本地安装独家技巧用nvm管理多版本 Node.js 时OpenRig 必须在nvm use激活的环境下运行。可在~/.bashrc中添加nvm use --delete-prefix v20 /dev/null 21确保每次终端启动都默认使用 v20。5.2 tmux 与进程管理异常报错信息根本原因诊断命令一招解决openrig up qwen: tmux: command not foundtmux 未安装或不在 PATHwhich tmuxsudo apt install tmux→echo export PATH/usr/bin:$PATH ~/.bashrcopenrig logs qwen: no server running on /tmp/tmux-1000/defaulttmux server 未启动或 socket 路径异常tmux lstmux start-server→openrig up qwenrig qwen is running but status shows stoppedtmux 会话被意外 kill但 OpenRig 状态缓存未更新tmux ls | grep openrig-qwenopenrig down qwen→openrig up qwen强制刷新注意openrig down rig并非简单kill它会发送tmux kill-session -t openrig-rig确保所有子进程包括 ollama 的 worker被 SIGTERM 清理。暴力kill -9可能导致 GPU 显存泄漏需nvidia-smi --gpu-reset重置。5.3 Codex / Claude Code 集成故障报错信息根本原因诊断命令一招解决codex login failed插件尝试连接 Cloud但网络策略阻止curl -v https://api.anthropic.com检查公司防火墙策略或改用 Local 模式codex cannot load organization settings插件配置文件损坏或权限不足ls -l ~/.vscode/extensions/*/package.jsonchmod 644 ~/.vscode/extensions/*/package.jsonclaude code calling lmstudios local model failedLM Studio 的 CORS 策略阻止 VS Code 调用cat ~/lm-studio/config.json | grep cors编辑~/lm-studio/config.json设cors_origin: *→ 重启 LM Studio关键洞察Codex 插件的local proxy本质是 VS Code 内置的 Node.js HTTP 代理。当它报failed while handling codex endpoint /responses90% 情况是目标服务如 ollama返回了非 200 状态码404/503而非网络不通。用openrig logs rig查看服务端日志比抓包更高效。5.4 模型加载与 GPU 资源冲突报错信息根本原因诊断命令一招解决CUDA out of memory多个 rig 同时占用 GPU显存超限nvidia-smi在各 rig 的config.yaml中严格设置CUDA_VISIBLE_DEVICES如qwen: 0,deepseek: 1model not found in Ollama librarymodel_load_cmd执行失败模型未拉取ollama listopenrig build rig重试或手动OLLAMA_NUM_PARALLEL1 ollama pull modelcc switch local proxy failed持续rig 的health_checkURL 返回非 200curl -v http://localhost:port/api/tags OpenRig：本地AI工作流调度器，多模型服务一键切换
1. OpenRig 是什么一个被误读但极具潜力的本地 AI 工作流调度器OpenRig 这个名字最近在开发者社区里频繁出现但它既不是某个新发布的闭源商业产品也不是某家大厂推出的 AI 框架——它本质上是一个轻量级、可组合、面向本地 AI 开发者的工作流调度与服务编排工具。很多人第一次看到它会下意识联想到“OpenAI Rig钻机”甚至误以为是某种挖矿工具或模型训练加速器也有人把它和 Claude、Codex、LM Studio 这些名字混在一起当成某个插件或客户端。其实完全不是。OpenRig 的核心定位非常清晰它是一套用 Node.js 编写的、基于 tmux 会话管理的 CLI 工具链用于在单台开发机上稳定、隔离、可复现地启动、监控、切换和调试多个本地大模型服务端如 Ollama、LM Studio、Text Generation WebUI、KoboldCpp及其配套的代理层如 local-proxy、codex-proxy。我最早接触 OpenRig 是在帮一位做教育类 AI 助教产品的同事排查环境问题时。他当时同时跑着 3 个模型一个 7B 的 Qwen 用于基础问答一个 13B 的 DeepSeek-Coder 做代码补全还有一个 3B 的 Phi-3 专用于低延迟的语音转文字后处理。每次切换模型都要手动 kill 进程、改配置、重启服务、再配 VS Code 的插件 endpoint——光是这一步每天就要浪费 20 分钟以上。后来他试了 OpenRig把三个服务分别定义为 rig即“钻机”每个 rig 对应独立的 tmux 窗口、独立的端口、独立的日志路径、独立的环境变量比如 CUDA_VISIBLE_DEVICES0 或 1再通过一条openrig switch qwen命令就能秒级切换当前活跃服务。更关键的是它不依赖 Docker不强制要求 root 权限也不修改系统 PATH所有状态都保存在用户目录下的.openrig/下卸载就是删掉这个文件夹——这种“零侵入、可审计、易回滚”的设计恰恰是很多重度本地模型使用者真正需要的。你可能会问既然有 Docker Compose、systemd、甚至简单的 shell 脚本也能做到类似效果为什么还要 OpenRig答案在于它的“语义化抽象”做得足够干净。它把“启动一个模型服务”这件事拆解成四个原子动作init初始化配置、build拉取/加载模型、up启动服务、switch设为默认。每个动作背后都封装了容错逻辑比如up会自动检测端口是否被占用若占用则尝试下一个可用端口并更新配置switch不仅改写全局 endpoint 链接还会同步更新 VS Code 的claude.code插件配置文件如果存在build支持从 HuggingFace Hub 直接下载 GGUF 文件并自动校验 SHA256。这些细节不是炫技而是长期在 Ubuntu 22.04 / Windows WSL2 / macOS Sonoma 上反复踩坑后沉淀下来的工程直觉。它不解决“如何训练模型”这种高阶问题但死死卡住了“让模型服务稳稳跑起来”这个最基础、最频繁、最容易出错的环节。所以如果你正面临以下任何一种情况OpenRig 就不是“可选”而是“刚需”你同时调试多个量化模型Q4_K_M、Q5_K_S、IQ2_XS需要快速对比响应速度与质量你在用 Codex 或 Claude Code 插件但每次换模型都要手动改http://localhost:1234/v1这样的 endpoint你的笔记本显存只有 8GB必须严格控制每个服务的 GPU 显存分配避免 OOM你用 tmux 管理服务但手写tmux new-session -d -s qwen ollama run qwen2:7b这种命令太容易拼错你想把本地模型服务变成团队共享的“开发标准件”而不是每个人各自维护一套混乱的 bash 脚本。OpenRig 不是万能胶它不提供模型、不训练权重、不优化推理性能——它只做一件事让你的本地 AI 实验室像一台精密仪器那样拧紧每一颗螺丝然后安静运转。2. 核心架构与设计逻辑为什么选择 Node.js tmux 而非 Docker 或 systemdOpenRig 的技术栈选择看似保守实则经过大量真实场景验证。它的主程序用 Node.js 编写底层进程管理依赖 tmux配置文件采用 YAML日志统一输出到~/.openrig/logs/下按 rig 名称分目录存储。这个组合乍看不如 Docker 容器化“高级”也不如 systemd “系统级”但它在本地开发场景中解决了三个关键矛盾资源隔离性、调试可见性、跨平台一致性。先说 Node.js。很多人一看到 Node.js 就想到“前端”“Web 服务”但在这里它承担的是“胶水层”角色。Node.js 的优势在于极低的安装门槛Ubuntu 用户curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash - sudo apt-get install -y nodejs两行搞定Windows 用户直接官网下载 MSI 安装包macOS 用 Homebrewbrew install node。相比之下Docker Desktop 在 Windows 上强制要求开启 WSL2 和虚拟机平台这就是为什么你会看到热搜词里反复出现“Claudes workspace requires the virtual machine platform on Windows. enable”——那其实是 Codex 或其他工具对 Docker 的依赖而非 OpenRig 所需进程控制能力扎实child_process.spawn()可以精确捕获 stdout/stderr设置超时、信号监听SIGTERM/SIGINT并支持stdio: [pipe, pipe, pipe]模式将子进程的输入输出重定向到 tmux pane 中这是 shell 脚本难以稳定实现的生态成熟度高YAML 解析js-yaml、HTTP 客户端axios、终端交互inquirer、文件系统操作fs-extra等模块开箱即用无需额外编译或链接 C 库。尤其重要的是Node.js 的process.env可以在 spawn 子进程时完整继承并动态注入这对需要设置CUDA_VISIBLE_DEVICES、OLLAMA_NUM_PARALLEL、TRANSFORMERS_CACHE等环境变量的模型服务至关重要。再看 tmux。它是 OpenRig 的“肌肉组织”。tmux 的价值不在于“多窗口”而在于会话持久化 pane 级别 I/O 隔离 键盘快捷键绑定。OpenRig 启动一个 rig 时实际执行的是tmux new-session -d -s openrig-qwen cd ~/.openrig/rigs/qwen OLLAMA_NUM_PARALLEL1 CUDA_VISIBLE_DEVICES0 ollama serve这个命令创建了一个名为openrig-qwen的 detached 会话并在其中启动 ollama 服务。后续所有日志、错误输出、甚至 CtrlC 中断信号都精准落在这个 pane 内。你可以随时tmux attach -t openrig-qwen进入调试也可以tmux capture-pane -p -t openrig-qwen抓取最新 100 行日志。更重要的是tmux 的send-keys功能让 OpenRig 能模拟人工操作比如当检测到codex插件配置文件存在时它会自动执行tmux send-keys -t openrig-qwen curl http://localhost:11434/api/tags Enter来触发一次模型列表刷新确保 VS Code 插件能实时感知服务状态——这种“人肉可复现、机器可自动化”的交互模式是纯 API 调用无法替代的。那么为什么不选 Docker因为 Docker 在本地开发中引入了不必要的抽象层。举个典型例子你用docker run -p 11434:11434 --gpus all ollama/ollama启动 ollama表面看很干净但实际会遇到NVIDIA Container Toolkit 版本与宿主机驱动不兼容报错failed to initialize NVML: Unknown ErrorDocker 默认使用 cgroups v1而 Ubuntu 22.04 默认启用 cgroups v2导致--gpus all失效日志分散在docker logs ollama和容器内/var/log/两个位置调试时要来回切换想临时修改一个环境变量比如加-e OLLAMA_DEBUG1必须 stop → rm → rerun无法热更新。而 OpenRig tmux 的方案所有进程都在用户空间运行ps aux | grep ollama一眼可见kill -9 $(pgrep -f ollama serve)一键清理strace -p $(pgrep -f ollama serve)直接跟踪系统调用——这种“透明性”对快速定位cc switch local proxy failed while handling codex endpoint /responses这类底层网络错误至关重要。最后说配置体系。OpenRig 的rigs/name/config.yaml文件结构极其精简name: qwen2:7b service: ollama port: 11434 env: OLLAMA_NUM_PARALLEL: 1 CUDA_VISIBLE_DEVICES: 0 startup_cmd: ollama serve health_check: url: http://localhost:11434/api/tags timeout: 5000 expected_status: 200这个设计拒绝过度工程化。它不搞 schema validation不强制要求 JSON Schema不引入自定义 DSL。YAML 本身已足够表达意图且 Vim/VS Code 都有原生高亮支持。当你发现error installing 24.21.0: node.js v24.21.0 is not yet released这类报错时OpenRig 的package.json里明确锁定了node: 18.0.0 22.0.0避免用户误装尚未稳定的 Node.js 主线版本——这种克制正是它能在各种老旧笔记本、CI 服务器、甚至树莓派上稳定运行的根本原因。3. 从零部署 OpenRigUbuntu 22.04 Node.js 20 tmux 全流程实操部署 OpenRig 的过程本质上是在你的开发机上构建一个“本地 AI 服务中枢”。整个流程分为四个阶段环境准备 → OpenRig 安装 → rig 初始化 → 服务启动与验证。下面我以 Ubuntu 22.04 LTS 为例全程使用终端命令不依赖 GUI所有操作均可复制粘贴执行注意替换your-username为实际用户名。3.1 环境准备安装 Node.js 20 与 tmuxUbuntu 22.04 自带的 Node.js 版本是 12.x远低于 OpenRig 要求的最低 18.x。必须升级。官方推荐方式是使用 Nodesource 仓库它比nvm更适合生产环境无 shell 初始化污染全局可用# 1. 更新系统包索引 sudo apt update # 2. 安装基础依赖wget、curl、gnupg 等 sudo apt install -y curl wget gnupg lsb-release # 3. 添加 Nodesource GPG 密钥验证包签名 curl -fsSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/nodesource.gpg # 4. 添加 Node.js 20.x 的 APT 源LTS 版本长期维护 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x $(lsb_release -cs) main | sudo tee /etc/apt/sources.list.d/nodesource.list # 5. 再次更新并安装 Node.js 20.x sudo apt update sudo apt install -y nodejs # 6. 验证安装应输出 v20.x.x node --version npm --version提示不要用sudo npm install -g openrig这种方式全局安装。OpenRig 的设计哲学是“per-user installation”所有文件都放在~/.openrig/下避免权限冲突。全局安装会导致npm试图写入/usr/lib/node_modules/而普通用户无此权限极易触发EACCES错误。接着安装 tmuxUbuntu 22.04 默认已预装但建议确认并升级# 检查是否已安装及版本要求 3.2a tmux -V # 输出应为 tmux 3.2a 或更高 # 若未安装或版本过低执行 sudo apt install -y tmux # 验证 tmux 是否支持 mouse 模式OpenRig 日志查看依赖此功能 tmux show-options -g | grep mouse # 应输出 mouse on注意tmux 的mouse on设置是 OpenRig 日志查看功能的基础。如果输出为mouse off需手动启用echo set -g mouse on ~/.tmux.conf然后tmux source-file ~/.tmux.conf生效。否则在openrig logs qwen时无法用鼠标滚动查看历史日志。3.2 安装 OpenRig使用 npm init 方式推荐OpenRig 不提供二进制包而是作为 npm 包发布。但直接npm install -g openrig会带来路径权限问题。正确做法是在用户主目录下初始化一个专用项目然后本地安装# 1. 创建专用目录不污染 ~/ mkdir -p ~/openrig-workspace cd ~/openrig-workspace # 2. 初始化 npm 项目一路回车默认即可 npm init -y # 3. 本地安装 OpenRig--save-dev 非必需但便于后续升级 npm install --save-dev openrig # 4. 创建软链接让 openrig 命令全局可用仅对当前用户 ln -sf ~/openrig-workspace/node_modules/.bin/openrig ~/bin/openrig # 如果 ~/bin 不存在先创建mkdir -p ~/bin # 5. 将 ~/bin 加入 PATH编辑 ~/.bashrc 或 ~/.zshrc echo export PATH$HOME/bin:$PATH ~/.bashrc source ~/.bashrc # 6. 验证命令可用性 openrig --version # 应输出类似 0.8.3实操心得我曾见过用户因~/bin目录权限问题导致ln -sf失败。如果openrig --version报错command not found请检查ls -la ~/bin/openrig是否存在且指向正确路径echo $PATH是否包含~/binwhich openrig是否输出/home/your-username/bin/openrig。绝对不要用sudo npm install -g那会埋下后续所有权限隐患。3.3 初始化第一个 rig以 ollama qwen2:7b 为例假设你已安装 ollama若未安装请先执行curl -fsSL https://ollama.com/install.sh | sh。现在用 OpenRig 管理它# 1. 初始化名为 qwen 的 rig会在 ~/.openrig/rigs/qwen/ 下创建结构 openrig init qwen # 2. 进入 rig 目录编辑 config.yaml nano ~/.openrig/rigs/qwen/config.yaml将 config.yaml 替换为以下内容关键参数已注释# rig 名称也是 tmux 会话名前缀 name: qwen2:7b # 指定服务类型OpenRig 内置支持 ollama / lmstudio / textgen-webui / koboldcpp service: ollama # 服务监听端口OpenRig 会自动检测冲突并递增 port: 11434 # 启动时注入的环境变量GPU 设备号、并发数、缓存路径等 env: OLLAMA_NUM_PARALLEL: 1 # 限制并发请求数防显存爆 CUDA_VISIBLE_DEVICES: 0 # 强制使用 GPU 0多卡时可设为 0,1 OLLAMA_HOST: 0.0.0.0:11434 # 允许外部访问如手机浏览器调用 # 启动命令OpenRig 会 cd 到此目录后执行 startup_cmd: ollama serve # 健康检查配置启动后自动轮询直到返回 200 才标记为 ready health_check: url: http://localhost:11434/api/tags timeout: 5000 # 单次请求超时 5 秒 expected_status: 200 # 必须返回 200 才算成功 # 模型加载指令OpenRig 会在 up 前自动执行 model_load_cmd: ollama pull qwen2:7b关键参数说明OLLAMA_NUM_PARALLEL: 1是防止 OOM 的关键。Qwen2:7b 在 8GB 显存上设为 1 可稳定运行设为 2 则大概率触发CUDA out of memoryCUDA_VISIBLE_DEVICES: 0确保服务只使用指定 GPU避免与其他 rig如 deepseek争抢OLLAMA_HOST: 0.0.0.0:11434让服务可被局域网内其他设备访问比如用 iPad 浏览器打开http://your-pc-ip:11434查看模型列表但生产环境请务必加反向代理和认证model_load_cmd是 OpenRig 的独创设计它在up前自动执行ollama pull确保模型存在。如果网络慢可在此处加timeout 300防止卡死。3.4 启动、切换与验证服务一切就绪执行启动# 1. 构建 rig拉取模型、生成配置 openrig build qwen # 2. 启动服务后台运行日志自动捕获 openrig up qwen # 3. 查看状态应显示 running, port: 11434, health: ok openrig status # 4. 查看实时日志按 Ctrlb 再按 [ 进入复制模式用方向键浏览 openrig logs qwen此时ollama 服务已在 tmux 会话openrig-qwen中运行。你可以用 curl 验证# 发送一个测试请求模拟 Codex 或 Claude Code 插件的调用 curl -X POST http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: qwen2:7b, messages: [{role: user, content: 你好请用中文简单介绍自己}], stream: false }预期返回一个 JSON 对象message.content字段包含 Qwen 模型的中文回复。如果返回{error:{message:...,code:not_found}}说明模型未加载成功请检查openrig logs qwen中是否有pulling manifest或verifying sha256日志。最后验证switch功能——这是 OpenRig 的灵魂# 1. 启动第二个 rig例如 deepseek-coder:6.7b openrig init deepseek # 编辑 ~/.openrig/rigs/deepseek/config.yaml设 port: 11435, model_load_cmd: ollama pull deepseek-coder:6.7b openrig build deepseek openrig up deepseek # 2. 切换默认服务为 deepseek openrig switch deepseek # 3. 此时 openrig status 应显示 deepseek 为 active openrig status # 4. 更关键的是OpenRig 会自动更新 Codex 插件的配置 # 检查 ~/.vscode/extensions/aaron-bond.better-comments-2.1.0/package.json示例路径实际以你安装的 Codex 插件为准 # 它会把 endpoint: http://localhost:11434 改为 http://localhost:11435 # 无需重启 VS CodeCodex 插件下次请求将自动发往 deepseek常见陷阱openrig switch不会自动重启正在运行的 rig它只改写全局 endpoint 和插件配置。如果你之前up qwen后没down qwen那么 qwen 服务仍在 11434 端口运行deepseek 在 11435 端口运行——两者并存互不干扰。这才是真正的“多模型共存”而非“非此即彼”。4. 深度集成 Codex 与 Claude Code解决 endpoint 切换与本地模型调用难题OpenRig 最被低估的价值是它与 Codex、Claude Code 这类 VS Code 插件的深度协同。很多用户抱怨codex is ignoring 1 unrecognized configuration setting或error: claude native binary not installed根源往往不是插件本身而是本地服务 endpoint 配置混乱、模型加载失败、或代理层缺失。OpenRig 通过三步走策略彻底解决这些问题。4.1 Codex 插件的 endpoint 自动同步机制Codex 插件v1.2.0支持两种 endpoint 模式Cloud 模式直接连接 Anthropic 官方 API需订阅Local 模式指向本地运行的兼容 OpenAI API 的服务如 ollama、LM Studio。其配置文件位于~/.vscode/extensions/aaron-bond.better-comments-2.1.0/package.json具体路径取决于插件 ID可通过 VS Code 设置界面搜索 “codex endpoint” 找到。OpenRig 的switch命令会自动解析该文件定位到endpoint字段并将其值更新为当前 active rig 的http://localhost:port。这个过程并非简单字符串替换。OpenRig 会备份原文件package.json.bak使用 JSONPath 定位$.contributes.configuration.properties[codex.endpoint].default和$.contributes.configuration.properties[codex.endpoint].description仅修改default字段值保留 description 不变避免破坏插件 schema写入后执行chmod 644确保权限正确防止 VS Code 因权限问题拒绝读取。验证是否生效在 VS Code 中按CtrlShiftP→ 输入 “Codex: Reload Configuration”或重启 VS Code新建一个.txt文件输入codex触发补全观察右下角状态栏是否显示Connected to http://localhost:11435即 deepseek 的端口。注意如果插件提示your organization has disabled claude subscription access for claude code说明你处于企业版管理策略下Codex 被强制锁定为 Cloud 模式。此时 OpenRig 无法绕过策略必须联系管理员调整组织策略或改用开源替代品如 Continue.dev。4.2 解决cc switch local proxy failed while handling codex endpoint /responses错误这个错误是 Codex 插件在尝试调用本地 endpoint 时底层 HTTP 客户端通常是 Node.js 的https模块抛出的网络异常。常见原因有三类OpenRig 提供对应诊断工具错误现象OpenRig 诊断命令根本原因解决方案ECONNREFUSEDopenrig status目标 rig 未up或端口被占用openrig down rig→openrig up rigETIMEDOUTopenrig logs rig模型加载超时如网络慢、GGUF 文件损坏openrig build rig重新拉取或手动ollama pull modelENOTFOUNDnslookup localhost/etc/hosts中localhost解析异常echo 127.0.0.1 localhost最典型的cc switch local proxy failed场景是你switch到一个新 rig但该 rig 的health_check一直失败比如 ollama 服务启动了但api/tags返回 503OpenRig 会标记其为unhealthy但 Codex 插件仍会尝试连接。此时openrig status会显示deepseek (unhealthy) → port: 11435, health: failed (503)解决方案不是重启插件而是openrig logs deepseek查看 ollama 是否报错failed to load modelollama list确认deepseek-coder:6.7b是否存在若不存在ollama pull deepseek-coder:6.7b手动拉取openrig up deepseek重试。OpenRig 的health_check机制本质是给 Codex 插件加了一道“准入闸机”只有健康的服务才允许被switch从源头杜绝了无效 endpoint 切换。4.3 接入 LM Studio 与 DeepSeek 的实操配置OpenRig 不仅支持 ollama对 LM Studio 和 DeepSeek 的本地部署同样友好。以 LM Studio 为例v0.2.25# 1. 下载 LM Studio DesktopLinux x64并解压到 ~/lm-studio/ # 官网https://lmstudio.ai/ # 2. 初始化 rig openrig init lmstudio # 3. 编辑 config.yaml nano ~/.openrig/rigs/lmstudio/config.yaml关键配置项name: phi-3-mini-4k-instruct service: lmstudio port: 1234 env: # LM Studio 启动时需指定模型路径和端口 LMSTUDIO_MODEL_PATH: /home/your-username/lm-studio/models/microsoft/Phi-3-mini-4k-instruct.Q4_K_M.gguf LMSTUDIO_PORT: 1234 # 强制使用 CPU避免与 GPU rig 冲突 LMSTUDIO_USE_GPU: false startup_cmd: /home/your-username/lm-studio/LMStudio.AppImage --no-sandbox --disable-gpu health_check: url: http://localhost:1234/v1/models timeout: 10000 expected_status: 200实操技巧LM Studio 的 AppImage 启动较慢health_check超时需设为 10 秒。--no-sandbox和--disable-gpu是 Ubuntu 上的必要参数否则可能报Failed to move to new namespace: Permission denied。对于 DeepSeekOpenRig 支持两种方式Ollama 方式推荐ollama pull deepseek-coder:6.7b配置同 qwenText Generation WebUI 方式需先git clone https://github.com/oobabooga/text-generation-webui然后在config.yaml中设service: textgen-webuistartup_cmd: python server.py --listen --port 5000 --api --extensions api。无论哪种openrig switch deepseek后Codex 插件的 endpoint 就会自动指向对应端口无需手动修改。5. 故障排查实战手册从node.js v24.21.0 is not yet released到codex login failed在真实环境中部署 OpenRig90% 的问题都集中在环境依赖、权限控制和网络配置上。下面是我整理的高频问题速查表每一条都来自真实工单记录附带一击必杀的解决方案。5.1 Node.js 版本与兼容性问题报错信息根本原因诊断命令一招解决error installing 24.21.0: node.js v24.21.0 is not yet releasednpm 尝试安装未来版本因package-lock.json锁定或 registry 配置错误npm config get registrynpm config set registry https://registry.npmjs.org/→rm -f package-lock.json node_modules→npm installSyntaxError: Unexpected token ?Node.js 版本过低14不支持可选链操作符node --version升级 Node.js 至 18见 3.1 节Error: EACCES: permission denied, access /usr/lib/node_modules误用sudo npm install -g导致权限混乱ls -ld /usr/lib/node_modulessudo chown -R $USER:$GROUPS /usr/lib/node_modules→npm install --save-dev openrig本地安装独家技巧用nvm管理多版本 Node.js 时OpenRig 必须在nvm use激活的环境下运行。可在~/.bashrc中添加nvm use --delete-prefix v20 /dev/null 21确保每次终端启动都默认使用 v20。5.2 tmux 与进程管理异常报错信息根本原因诊断命令一招解决openrig up qwen: tmux: command not foundtmux 未安装或不在 PATHwhich tmuxsudo apt install tmux→echo export PATH/usr/bin:$PATH ~/.bashrcopenrig logs qwen: no server running on /tmp/tmux-1000/defaulttmux server 未启动或 socket 路径异常tmux lstmux start-server→openrig up qwenrig qwen is running but status shows stoppedtmux 会话被意外 kill但 OpenRig 状态缓存未更新tmux ls | grep openrig-qwenopenrig down qwen→openrig up qwen强制刷新注意openrig down rig并非简单kill它会发送tmux kill-session -t openrig-rig确保所有子进程包括 ollama 的 worker被 SIGTERM 清理。暴力kill -9可能导致 GPU 显存泄漏需nvidia-smi --gpu-reset重置。5.3 Codex / Claude Code 集成故障报错信息根本原因诊断命令一招解决codex login failed插件尝试连接 Cloud但网络策略阻止curl -v https://api.anthropic.com检查公司防火墙策略或改用 Local 模式codex cannot load organization settings插件配置文件损坏或权限不足ls -l ~/.vscode/extensions/*/package.jsonchmod 644 ~/.vscode/extensions/*/package.jsonclaude code calling lmstudios local model failedLM Studio 的 CORS 策略阻止 VS Code 调用cat ~/lm-studio/config.json | grep cors编辑~/lm-studio/config.json设cors_origin: *→ 重启 LM Studio关键洞察Codex 插件的local proxy本质是 VS Code 内置的 Node.js HTTP 代理。当它报failed while handling codex endpoint /responses90% 情况是目标服务如 ollama返回了非 200 状态码404/503而非网络不通。用openrig logs rig查看服务端日志比抓包更高效。5.4 模型加载与 GPU 资源冲突报错信息根本原因诊断命令一招解决CUDA out of memory多个 rig 同时占用 GPU显存超限nvidia-smi在各 rig 的config.yaml中严格设置CUDA_VISIBLE_DEVICES如qwen: 0,deepseek: 1model not found in Ollama librarymodel_load_cmd执行失败模型未拉取ollama listopenrig build rig重试或手动OLLAMA_NUM_PARALLEL1 ollama pull modelcc switch local proxy failed持续rig 的health_checkURL 返回非 200curl -v http://localhost:port/api/tags