OpenCodex Provider/Model 补丁索引：一文掌握 built-in provider、模型与配置变更的标准修改路径

【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本指南以devlog/_chase/_model/004_patch_index.md为骨架梳理 OpenCodex 在新增 provider、追加模型、扩展配置字段、打通 jawcode 元数据时的所有实际修改点与联动契约。读完你可以照着索引在 src/providers/registry.ts 等核心文件中定位正确的首个修改点并跑通最小验证命令集避免把代码写进错误的归属层。OpenCodex 是面向 OpenAI Codex 与 Claude Code 的通用 provider 代理负责把 Codex CLI/App/SDK 的请求路由到 Claude、Gemini、Grok、DeepSeek、Ollama 等任意上游。模型/provider 的增删改看似只是加一个名字实际上牵动 registry、derive、router、adapter、catalog、management API 与 jawcode 元数据生成多条链路。004_patch_index.md正是为这类变更准备的改动路由表先用一张表判断变更类型再按对应清单逐点落位。快速分类先判定变更类型再决定首个修改点任何 provider/model 相关改动第一步不是写代码而是对照下表完成分类确定首个所有者以及需要一起确认的地方。变更类型首个所有者需要一起检查的位置新增 built-in providersrc/providers/registry.tsderive、auth、router、adapter、catalog、management API、tests/docs给已有 provider 添加模型registry 或 live metadata parseradapter override、catalog tests、picker 可见性OAuth/login 变更src/oauth/registry 的authKind/oauthId、store 并发、management APIAPI-key pool / 429 变更src/providers/key-failover.tsrelay retry 边界、tests、quota 展示wire request/stream 变更src/adapters/src/server/adapter-resolve.ts、bridge/parser testsCodex picker 元数据src/codex/catalog.tsregistry hints、生成 jawcode metadata、/api/modelsjawcode model metadata 同步jawcode generator sourcebun run generate:jawcode-metadata、catalog diffGUI provider presetregistry → derive 路径management APIGUI 只消费派生值这张表的潜台词是 OpenCodex 的分层原则registry 是唯一正本GUI 与 key-login 列表从不复制同一份数据。例如 provider preset 的变更必须落在registry → derive路径上管理 API 与 GUI 只消费派生结果而不是各自维护一套配置。这一规则在 devlog/_chase/_model/README.md 的操作规则一节有明确表述built-in provider 的正本是PROVIDER_REGISTRY。新增 built-in provider 的标准七步流程原文档给出了完整七步这里结合源码逐条展开在 registry 中登记稳定 id在 src/providers/registry.ts 的 provider entry 中写入 stable id、label、adapter、base URL 与 auth kind。PROVIDER_REGISTRY由PROVIDER_REGISTRY_CORE与PROVIDER_REGISTRY_EXTENDED两个分表合并而来registry.ts新 provider 应归入其中一张分表。entry 的字段契约定义在 src/providers/registry/types.ts 的ProviderRegistryEntryid、label、adapter、baseUrl、authKind是必填骨架其余如dashboardUrl、models、liveModels、modelContextWindows等按需填充。registry 加载时还会对每个 entry 执行fastWireDeclarationError校验声明非法会直接抛TypeErrorregistry.ts。确认现有 adapter 是否够用只有在出现全新 wire shape 时才扩展 src/adapters/ 与resolveAdapter()。从 001_provider_inventory.md 的统计看多数 provider 落在 openai-chat38 个、anthropic5 个、google3 个等既有 adapter family 上——这也是文档强调现有 adapter 够用就不新建 adapter/auth flow的原因。处理 key/OAuth 契约key provider 要核对dashboardUrl与deriveKeyLoginMap()契约OAuth provider 则需在 src/oauth/index.ts 注册 login/refresh controller并在 registry entry 中设置oauthId同时确认 src/oauth/store.ts 的按账号 credential store 与刷新序列化行为。ProviderAuthKind只有forward | oauth | key | local四种registry/types.ts先归类再动手。只有必要时才扩展 bare model prefix默认使用显式provider/model命名空间。文档明确基本默认是显式 provider/modelbare prefix 是例外而非常态——src/router.ts 中的MODEL_PROVIDER_PATTERNS目前仅覆盖claude-*、groqllama-/mixtral-/gemma-两类前缀router.ts扩表需谨慎。决定 fallback 模型与 capability 元数据的归属static fallback 模型、live discovery、context/modality/reasoning 元数据各归其主。从 002_catalog_contract.md 的契约看liveModels: true的 provider 以 live/models结果为模型 ID 的权威来源registry 只提供 fallback 与 capability hint。核对对外接口检查/api/providers、/api/models、selected/disabled models 以及 Codex catalog sync。管理 API 实现位于 src/server/management-api.tscatalog 的合并与缓存失效在 src/codex/catalog.ts。补测试、跑 typecheck、更新文档执行针对 provider/adapter/catalog 的 focused test 与bun run typecheck并同步用户文档。给已有 provider 添加模型六步轻量流程新增模型与新增 provider 是两类变更后者大多无需动 adapter 或 auth确认 upstream 模型 ID 与实际 wire protocol若 provider 是liveModels: true不要写 static allowlist只补 fallback/capability hint——live 结果是权威registry 的models仅作 fallback按需在对应 registry entry 上补充modelContextWindows、modelInputModalities、modelReasoningEfforts及参数排除列表如noVisionModels、noReasoningModels、noTemperatureModels、noTopPModels、noPenaltyModels字段定义见 registry/types.ts仅当该模型 wire 与 provider 默认不同时才修改resolveWireProtocolOverride()——它按硬 pin → 用户 per-model override → registry 混合 wire 默认 → provider 自身 adapter的优先级解析adapter-resolve.ts当前仓库中的典型例子是 OpenCode Go 的部分 MiniMax 模型区分 media-generation 模型与 vision-input chat 模型确认 catalog filter 是否放行/隔离——media 生成模型要从 coding model picker 中分离若需复用 jawcode 元数据先改生成 source 再重新生成 snapshot不要手改生成文件。新增配置字段的六步契约链文档强调新字段真的需要时才做并给出严格顺序先在 src/types.ts 的ProviderRegistryEntry或OcxProviderConfig契约上扩展类型在 src/config.ts 实现 validation/default/migration打通providerConfigSeed()与enrichProviderFromRegistry()的派生路径实现位于 src/providers/derive.ts修改 router/adapter/catalog 中的实际消费者更新 management API DTO 与 GUI editor补齐 round-trip config test 与 backward-compat test。顺序的意图是把类型 → 校验 → 派生 → 消费 → 对外呈现 → 回归串成一条单向链任何一环缺失都会让新字段在某个环节悄悄失效。与 jawcode 的边界谁拥有什么OpenCodex 的模型元数据部分来自 jawcodepackages/ai/src/models.json生成的 snapshot但两者的所有权必须严格区分问题jawcode 拥有OpenCodex 拥有JWC 自身调用 providerpackages/ai/src/providers/、descriptor、auth storage不适用把 Codex 请求代理到 provider参考实现registry、router、adapters、bridgeJWC bundled model metadatagenerator packages/ai/src/models.json消费生成的 metadata snapshotCodex App picker 暴露不适用src/codex/catalog.ts 与 sync/cacheOpenCodex OAuth 账号/密钥池不适用src/oauth/、src/providers/api-keys.ts接收 provider patch 时先按JWC native、OCX proxy、both、docs-only四类做初步分类。jawcode 有了某 provider 不代表 OCX registry 要自动加它OCX 能路由某 provider 也不代表要扩充 jawcode 的KnownProvider——transport、auth、retry、catalog 的所有权不因同名而共享。最小验证命令集文档给出的验证命令测试文件名需在改动前用rg --files tests | rg provider|router|catalog|oauth重新确认因为仓库测试文件会演进bun test --isolate tests/provider-registry-parity.test.ts tests/provider-live-models.test.ts bun test --isolate tests/router.test.ts tests/codex-catalog.test.ts bun run typecheck git diff --check按当前仓库实际结构provider 相关测试集中在 tests/providers/ 下如devin-live-models.test.ts、deepseek-inbound-wire.test.ts等catalog 契约的完成标准则要求/api/models与/v1/models共用同一 routed model source详见 002_catalog_contract.md。建议在改动前运行上述rg命令确认本次变更对应测试的准确文件名。源码印证从补丁索引到实现层registry 正本PROVIDER_REGISTRY合并entries-core与entries-extended加载期即校验 fastWire 声明合法性src/providers/registry.tsProviderAuthKind、ModelWireDefault、InboundWire、live discovery 等类型契约集中在 src/providers/registry/types.ts。adapter 解析resolveWireProtocolOverride()支持hard pin 优先、per-model override 次之、registry 默认兜底的多级覆盖且对 forward provider 禁止切换 wire避免丢凭证实现在 src/server/adapter-resolve.ts。路由优先级routeModel()依次尝试显式provider/model→ 激活 provider 的defaultModel→ 已知 bare-model prefix → 静态/配置models→defaultProvider→ 报错详见 003_auth_routing_flow.md对应实现 src/router.ts且带/的 upstream 模型 id 只有在 prefix 确为已配置 provider 时才作命名空间切分。jawcode 元数据生成输入默认是../jawcode/packages/ai/src/models.json可用JAWCODE_MODELS_JSON环境变量覆盖输出为src/generated/jawcode-model-metadata.ts该文件不允许手改只能通过bun run generate:jawcode-metadata再生成契约见 002_catalog_contract.md。当前仓库 src/generated/ 下的实际生成物为model-metadata.ts说明生成脚本与产物命名仍在演进改动前应以仓库现状为准。进一步阅读变更全貌chase/_model README阅读顺序与正本路径Provider 盘点与分层001_provider_inventory.mdCatalog 四输入合并契约002_catalog_contract.md认证与路由流程003_auth_routing_flow.md上游差距 backlog 与模型 id 差异005_upstream_delta_backlog.md、007_model_id_delta.md赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐Qwen-Agent 文档分块实战3 个参数让 RAG 知识库从上传到问答一次跑通Qwen Agent 文档分块实战3 个参数让 RAG 知识库从上传到问答一次跑通 把一份 PDF 丢给 AI它却答非所问多半是文档太长超出了模型窗口。Q人工智能大模型AI AgentAgent 框架工具调用RAGOpenCodex 并行工具调用接入实战provider 级 opt-in 配置、请求体标志与 Catalog 能力位全链路实现OpenCodex 并行工具调用接入实战provider 级 opt in 配置、请求体标志与 Catalog 能力位全链路实现 本篇技术指南以 OpenCoopencodex 模型目录增量分析jawcode 元数据桥接与 provider/model ID 差异对照opencodex 模型目录增量分析jawcode 元数据桥接与 provider/model ID 差异对照 本文以 opencodex 的 chase/_创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考