【免费下载链接】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点击查看免费下载导读本文基于 opencodex 开发日志 devlog/_fin/260722_antigravity_effort_routing/010_models.md 展开讲解 opencodex 如何把 AntigravityGoogle Cloud Code Assist简称 CCA后端以wire 模型 ID 后缀编码的推理强度low/medium/high折叠为单一条目的选择器模型并在服务端完成 effort → wire 模型 ID 的路由解析。读完本文你将掌握ANTIGRAVITY_MODEL_EFFORTS与ANTIGRAVITY_EFFORT_WIRE_MAP的数据结构设计、resolveAntigravityEffortWireModel的五级优先级解析规则、何时向 CCA 信封发送thinkingConfig以避免自相矛盾的请求以及旧后缀配置如何通过兼容别名无损存活。背景为什么需要 effort 路由CCA 后端不通过独立的thinkingConfig字段表达推理强度——至少对 Gemini 家族而言它把思考等级直接编码在 wire 模型 ID 中如gemini-3.6-flash-low、gemini-3.6-flash-medium、gemini-3.6-flash-high。在本次改造之前opencodex 把这些后缀 ID 逐个暴露为选择器条目既噪杂又容易误导用户。改造目标明确锁定把 effort 变体折叠为单一选择器条目如gemini-3.6-flash、gemini-3.1-pro由用户在条目的 effort 选择器里选档服务端完成 effort → wire 模型 ID 的路由claude-opus-4-6-thinking通过thinkingConfig.thinkingLevel获得 effort 控制Anthropic API 支持 low/medium/high/maxCLIProxyAPI 证明了 CCA wire 接受 Claude 的 thinkingConfig已保存配置中的后缀 ID 作为兼容别名继续解析与路由Claude Sonnet 与 gpt-oss 保持单模型、无 effort 控制非目标。000_plan.md中记录的问题描述还给出了一个关键背景直接 Gemini AI 路径AI Studio早已把gemini-3.6-flash折叠为单条目并通过generationConfig.thinkingConfig.thinkingLevel传档但该路径在cloud-code-assist模式下被显式禁用google.ts 中原先的directFlashThinking门控。因此 CCA 路径必须另走一条以 wire ID 后缀为主、thinkingConfig为辅的混合方案。数据模型effort 阶梯与 wire 映射ANTIGRAVITY_MODEL_EFFORTS每个折叠模型的可用 effort 阶梯新增导出的ANTIGRAVITY_MODEL_EFFORTS: Recordstring, string[]声明每个 picker 可见基础模型的 effort 档位。按010_models.md的设计初始形态为export const ANTIGRAVITY_MODEL_EFFORTS: Recordstring, string[] { gemini-3.6-flash: [low, medium, high], gemini-3.1-pro: [low, high], claude-opus-4-6-thinking: [low, medium, high, max], };其中 Claude 条目是设计迭代的产物初期方案仅覆盖 Gemini外部验证CLIProxyAPI 与 Anthropic 官方文档确认 CCA wire 对 Claude 同样接受thinkingConfig后claude-opus-4-6-thinking被补充进阶梯后续实现又按/^claude-/前缀推广到claude-sonnet-4-6见 001_research.md 的 commit03eecc4a记录。需要说明的是当前仓库已演进在 antigravity-models.ts 中阶梯已更新为gemini-3.8-flash、gemini-3.7-flash均为 low/medium/high、gemini-3.1-prolow/high以及两个 Claude 模型low/medium/high/max。代码注释特别指出minimal档被 Google 文档标记为当前代错误档CCA 只暴露三档因此阶梯中不包含minimal。ANTIGRAVITY_EFFORT_WIRE_MAPeffort → wire ID对 Gemini 基础模型新增ANTIGRAVITY_EFFORT_WIRE_MAP给出每个 effort 对应的 wire ID。010_models.md时代的对应关系以 3.6 为例const ANTIGRAVITY_EFFORT_WIRE_MAP { gemini-3.6-flash: { low: gemini-3.6-flash-low, medium: gemini-3.6-flash-medium, high: gemini-3.6-flash-high, }, gemini-3.1-pro: { low: gemini-3.1-pro-low, high: gemini-pro-agent, // CCA wire 上的 Gemini 3.1 Pro (High) }, };当前仓库版本与此同构只是 3.6 已换代为 3.8gemini-3.8-flash三个后缀 wire与 3.1-pro。注意gemini-3.1-pro的 high 档 wire 是gemini-pro-agent——它不带任何后缀因此对 pro 而言thinkingLevel是唯一能命名 effort 的通道这与 flash 族的后缀即档位形态不同直接决定了后面 resolver 的差异分支。基础 ID 的上下文窗口显式条目由于折叠后的基础 ID 是 picker 可见的gemini-3.6-flash、gemini-3.1-pro不能再依赖别名派生获得上下文窗口因此在ANTIGRAVITY_MODEL_CONTEXT_WINDOWS中为它们添加显式条目flash 与 pro 均为1_048_5761M token。当前实现位于 antigravity-models.ts折叠基础 ID 显式列出wire ID 与别名通过推导合并。选择器列表折叠前后对比改造前 picker 可见列表来自010_models.md的 Before 列表gemini-3.6-flash-low gemini-3.6-flash-medium gemini-3.6-flash-high gemini-3.1-pro-low gemini-pro-agent claude-sonnet-4-6 claude-opus-4-6-thinking gpt-oss-120b-medium gemini-3.1-pro-high (visible alias → gemini-pro-agent) gemini-3.1-pro-preview (visible alias → gemini-pro-agent)改造后After 列表gemini-3.6-flash (efforts: low, medium, high) gemini-3.1-pro (efforts: low, high) claude-sonnet-4-6 claude-opus-4-6-thinking (efforts: low, medium, high, max) gpt-oss-120b-medium当前实现对应 ANTIGRAVITY_MODELSgemini-3.8-flash当前代、gemini-3.7-flash上一代仍在服务、gemini-3.1-pro、gemini-3.1-flash-image、两个 Claude 与gpt-oss-120b-medium。resolveAntigravityEffortWireModel五级优先级解析核心新函数为resolveAntigravityEffortWireModel(modelId, effort?, baseUrl?)返回{ wireModelId, thinkingLevel? }。调用方用wireModelId填充 CCA 信封的model字段当返回thinkingLevel时写入generationConfig.thinkingConfig { thinkingLevel }。010_models.md给出三条显式优先级当前实现扩展为更细的五条antigravity-models.ts 的注释与代码一致后缀 wire ID 或兼容别名如gemini-3.6-flash-low、gemini-3.5-flash-high经resolveAntigravityWireModelId(modelId)解析。后缀本身就是 effort——原样返回解析后的 wire ID必须禁止发送thinkingConfig否则会构造出model: gemini-3.6-flash-lowthinkingLevel: high的自相矛盾请求。有 effort 映射的基础模型如gemini-3.6-flasheffort 已提供且在阶梯内 → 返回gemini-3.6-flash-{effort}effort 未提供 → 返回默认档的 wire IDflash 为mediumpro 为higheffort 提供但不在映射内如 flash 上要求max→ 钳制到最高支持档并返回对应 wire ID。Claude 模型claude-opus-4-6-thinking等返回模型自身 ID 并附带thinkingLevel——Claude 没有后缀变体thinkingConfig是唯一 effort 通道。单 wire ID 的 Gemini 模型当前实现为gemini-3.7-flash经ANTIGRAVITY_THINKING_LEVEL_MODELS声明档位骑在thinkingLevel上而非后缀 wire缺省档为 medium。其余所有 ID如claude-sonnet-4-6、gpt-oss-120b-medium、未知 ID返回resolveAntigravityWireModelId(modelId)——非别名 ID 即恒等返回。thinkingConfig 发送决策矩阵场景是否发送 thinkingConfig后缀/兼容 ID规则 1否——后缀已编码 effort映射基础模型 显式 effort规则 2是——thinkingLevel: effort双保险CLIProxyAPI 模式映射基础模型 无 effort规则 2 默认档否——默认 wire ID 已编码默认档Claude 显式 effort规则 3模型在阶梯内是——thinkingLevel: effort其余所有 ID否当前实现还引入了一个值得注意的细节ANTIGRAVITY_SUFFIX_TIER_MODELSgemini-3.8-flash在集合内标记每个档位都已由后缀命名的模型此类模型即便命中规则 2 也不发送thinkingLevel——因为-lowwire 配HIGH在 CCA 会返回 200 而非报错响应里到底跑了哪一档无法得知双重声明反而制造不可观测性。gemini-3.1-pro被刻意排除在集合外因为其 high 档是gemini-pro-agent不带后缀。退役代次的重定向规则 0当前实现比010_models.md多出一层规则 0Google 几乎在新一代 Flash 上线时立即从 CCA 撤下上一代RETIRED_FLASH_TIERS把 3.6及原本指向 3.6 的 3.5/3-flash 别名映射到 3.7 的-tieredwire 目标同时携带该 ID 曾经编码的档位。这一设计是为了避免把用户明确选择的高档静默降级成无档 3.7 调用——平面别名做不到这一点因为规则 1 会把任何别名当作后缀即 effort而拒绝发thinkingConfig。兼容别名inbound-only永不进选择器所有后缀 ID 移入ANTIGRAVITY_COMPATIBILITY_MODEL_ALIASES仅用于入站解析、不出现在 picker 中。010_models.md给出的完整别名表gemini-3.6-flash-low → gemini-3.6-flash-low // identity已是 wire gemini-3.6-flash-medium → gemini-3.6-flash-medium // identity已是 wire gemini-3.6-flash-high → gemini-3.6-flash-high // identity已是 wire gemini-3.1-pro-low → gemini-3.1-pro-low // identity已是 wire gemini-pro-agent → gemini-pro-agent // identity已是 wire gemini-3.1-pro-high → gemini-pro-agent // 原有 visible alias gemini-3.1-pro-preview → gemini-pro-agent // 原有 visible alias gemini-3.5-flash-extra-low → gemini-3.6-flash-low // 原有 gemini-3.5-flash-low → gemini-3.6-flash-medium // 原有 gemini-3.5-flash-mid → gemini-3.6-flash-medium // 原有 gemini-3.5-flash-high → gemini-3.6-flash-high // 原有 gemini-3-flash-agent → gemini-3.6-flash-high // 原有当前仓库 antigravity-models.ts 保留了wire 后缀 ID 恒等别名的约定并在此基础上把退役 Flash 代次整体映射到gemini-3.7-flash-tiered。这些别名与ANTIGRAVITY_VISIBLE_MODEL_ALIASES合并为导出常量ANTIGRAVITY_MODEL_ALIASES由resolveAntigravityWireModelId统一消费。上下文窗口同样沿别名链推导L312-L325。激活场景验证来自010_models.mdpicker 显示一次gemini-3.6-flash effort 选择器 [low, medium, high]已保存的gemini-3.6-flash-low配置仍能解析并正确路由已保存的gemini-3.1-pro-high仍解析到gemini-pro-agentocx models列出折叠后的条目。注册表接线与计价registrygoogle-antigravity 条目在 src/providers/registry/entries-core.ts 中google-antigravity条目接入ANTIGRAVITY_MODEL_EFFORTS作为modelReasoningEffortsdefaultModel指向折叠后的基础 ID当前为gemini-3.8-flash。000_plan.md明确说明无需modelReasoningEffortMap——恒等标签由mapReasoningEffort保留。按000_plan.md的跨切面不变量注册表是预设的单一事实来源registry.ts→derive.ts→ CLI/GUIGUI 的模型元数据来自注册表/目录因此本次改造无需改动 GUI picker 组件。modelReasoningEfforts字段并非 Antigravity 独有grok-4.5 使用{ grok-4.5: [low, medium, high] }作为既有范例见001_research.mdreasoning-effort.ts 的mapReasoningEffort与configuredReasoningEfforts()正是消费该字段、把 Codex 推理标签换算到各模型阶梯并完成钳制的入口。expected-prices折叠基础 ID 的计价条目010_models.md要求保留以 wire ID 为键的既有计价条目它们作为别名存活并为折叠基础 ID 新增条目。当前 expected-prices.ts 印证了这一模式gemini-3.8-flash、gemini-3.8-flash-low/medium/high均有条目gemini-3.1-pro与gemini-3.1-pro-low/high、gemini-pro-agent、gemini-3.1-pro-preview各自独立计价历史 3.6 代次条目标注collapsed base ID与derived: gemini-3.6-flash来源。tests/usage-cost.test.ts的 overlay 数量随之更新。从源码结构看canonicalAntigravityUsageModel 通过反向映射ANTIGRAVITY_USAGE_BASE_BY_ID把 effort wire ID 与兼容别名折叠回同一个 picker 基础模型保证一次调用 一行用量。退役 ID 在用量聚合中保留自身身份——路由可以把新 3.6 调用发往 3.7但历史用量行记录的是用户当时真正调用的模型重贴标签会移动历史消费。适配器侧CCA buildRequest 的 effort 解析WP2020_adapter.md定义了适配器改造。当前 google.ts 的 CCA 分支与此完全一致const mappedEffort mapReasoningEffort(provider, parsed.modelId, parsed.options.reasoning); const { wireModelId, thinkingLevel } resolveAntigravityEffortWireModel( parsed.modelId, mappedEffort, provider.baseUrl, ); antigravityModel wireModelId; // ... if (thinkingLevel || includeThoughts) { const gc (body.generationConfig ?? {}) as Recordstring, unknown; gc.thinkingConfig { ...(thinkingLevel ? { thinkingLevel } : {}), ...(includeThoughts ? { includeThoughts: true } : {}), }; // ... }解析发生在构建 CCA 信封之前mapReasoningEffort先把 Codex 推理标签按配置阶梯钳制resolveAntigravityEffortWireModel再把基础模型 已钳制 effort换算成 wire ID 与 thinkingLevel。antigravityModel由此成为 effort 解析后的 wire IDCCA 信封的model字段与request.generationConfig.thinkingConfig.thinkingLevel共同构成最终请求。后缀 ID 优先矛盾请求预防当已保存配置携带后缀 ID如gemini-3.6-flash-low且用户显式设置reasoning: high时mapReasoningEffort可能仍返回high后缀 ID 不在modelReasoningEfforts中不发生钳制resolveAntigravityEffortWireModel经规则 1 检测到后缀 ID返回{ wireModelId: gemini-3.6-flash-low, thinkingLevel: undefined }不发送thinkingConfig——后缀已编码 effort。这避免了model: gemini-3.6-flash-lowthinkingLevel: high的矛盾信封。钳制示例mapReasoningEffort在到达 resolver 前按配置阶梯钳制020_adapter.md给出的对照表模型请求档钳制后Wire IDgemini-3.6-flashmaxhigh阶梯最高档gemini-3.6-flash-highgemini-3.6-flashultramax→highultra→max 边界后钳制gemini-3.6-flash-highgemini-3.1-promediumlow[low,high] 中最近的不高于请求的档gemini-3.1-pro-lowgemini-3.1-promaxhighgemini-pro-agentclaude-opus-4-6-thinkingmaxmax在阶梯内自身 ID thinkingConfigclaude-opus-4-6-thinkingultramaxultra→max 边界自身 ID thinkingConfig默认档flash 为medium对齐当前defaultModel注册表默认pro 为high对齐gemini-3.1-pro-high → gemini-pro-agent作为主条目的既有可见别名。与 replay cache 的交互replay cache 以(antigravityModel, sessionId)为键。由于antigravityModel是解析后的 wire ID如gemini-3.6-flash-high不同 effort 级别自然获得隔离的缓存条目——同一会话内从medium切到high会得到全新 replay 条目因为不同思考强度产生不同的 thought 签名。这与001_research.md记录的在 google.ts 中先解析 wire ID 再进 replay 调用的顺序约束一致。验证方式010_models.md给出的最小验证命令bun run typecheck bun test tests/provider-registry-parity.test.tsWP2 扩展为聚焦测试集020_adapter.mdbun test tests/google-antigravity-wire.test.ts tests/reasoning-effort.test.ts tests/usage-cost.test.ts tests/google-models-listing.test.ts tests/google-antigravity-replay.test.ts tests/provider-registry-parity.test.ts测试面覆盖wire 解析/列表 fixturegoogle-antigravity-wire.test.ts、google-models-listing.test.ts、resolver 单元测试reasoning-effort.test.ts、计价 overlay 计数usage-cost.test.ts、注册表一致性provider-registry-parity.test.ts以及按 effort 级别隔离的 replay 缓存键google-antigravity-replay.test.ts。000_plan.md以bun run typecheck 聚焦bun test作为工作完成的验证器verifier。设计要点回顾单一事实来源ANTIGRAVITY_WIRE_MODELS保持完整 wire 列表用于解析ANTIGRAVITY_MODELS是折叠后的 picker 列表effort 阶梯与映射独立维护。wire 来源即 Antigravity:fetchAvailableModels后端与agyCLI 解析标签的同一来源。后缀与 thinkingConfig 不混用后缀 ID 绝不发送thinkingConfig避免矛盾请求与不可观测的档位漂移。兼容别名保证存量配置已保存后缀 ID 无需迁移即继续可用退役代次当前为 3.6→3.7通过层级映射在重定向时保留用户选择的档位。Claude 的 effort 通道不同Gemini 走 wire 后缀Claude 走thinkingConfig.thinkingLevel两者在同一个 resolver 返回类型{ wireModelId, thinkingLevel? }下统一。解析发生在信封构建之前适配器先mapReasoningEffort钳制、再resolveAntigravityEffortWireModel定 wire随后才有机会写thinkingConfig与 replay 缓存键。相关后续工作项见 WP3聚焦测试完整路线见 000_plan.md研究依据与外部验证CLIProxyAPI 模式、Anthropic 官方文档、agy CLI 目录见 001_research.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点击查看免费下载相关推荐opencodex 中 Google AntigravityCCA推理强度到线模型 ID 的路由解析实现指南opencodex 中 Google AntigravityCCA推理强度到线模型 ID 的路由解析实现指南 导读 本文讲解 opencodex 项目中 Gopencodex AntigravityCloud Code Assist推理档位路由全解模型 ID 编码、thinkingConfig 双通道与 effort 解析实现剖析opencodex AntigravityCloud Code Assist推理档位路由全解模型 ID 编码、thinkingConfig 双通道与 efopencodex 的 Antigravity Effort 路由实战把 Gemini/Claude 思考档位折叠为单一模型入口的服务端方案opencodex 的 Antigravity Effort 路由实战把 Gemini/Claude 思考档位折叠为单一模型入口的服务端方案 本篇以 devl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
opencodex 中 Antigravity 推理强度路由实现：effort 映射、wire 模型解析与思考配置
【免费下载链接】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点击查看免费下载导读本文基于 opencodex 开发日志 devlog/_fin/260722_antigravity_effort_routing/010_models.md 展开讲解 opencodex 如何把 AntigravityGoogle Cloud Code Assist简称 CCA后端以wire 模型 ID 后缀编码的推理强度low/medium/high折叠为单一条目的选择器模型并在服务端完成 effort → wire 模型 ID 的路由解析。读完本文你将掌握ANTIGRAVITY_MODEL_EFFORTS与ANTIGRAVITY_EFFORT_WIRE_MAP的数据结构设计、resolveAntigravityEffortWireModel的五级优先级解析规则、何时向 CCA 信封发送thinkingConfig以避免自相矛盾的请求以及旧后缀配置如何通过兼容别名无损存活。背景为什么需要 effort 路由CCA 后端不通过独立的thinkingConfig字段表达推理强度——至少对 Gemini 家族而言它把思考等级直接编码在 wire 模型 ID 中如gemini-3.6-flash-low、gemini-3.6-flash-medium、gemini-3.6-flash-high。在本次改造之前opencodex 把这些后缀 ID 逐个暴露为选择器条目既噪杂又容易误导用户。改造目标明确锁定把 effort 变体折叠为单一选择器条目如gemini-3.6-flash、gemini-3.1-pro由用户在条目的 effort 选择器里选档服务端完成 effort → wire 模型 ID 的路由claude-opus-4-6-thinking通过thinkingConfig.thinkingLevel获得 effort 控制Anthropic API 支持 low/medium/high/maxCLIProxyAPI 证明了 CCA wire 接受 Claude 的 thinkingConfig已保存配置中的后缀 ID 作为兼容别名继续解析与路由Claude Sonnet 与 gpt-oss 保持单模型、无 effort 控制非目标。000_plan.md中记录的问题描述还给出了一个关键背景直接 Gemini AI 路径AI Studio早已把gemini-3.6-flash折叠为单条目并通过generationConfig.thinkingConfig.thinkingLevel传档但该路径在cloud-code-assist模式下被显式禁用google.ts 中原先的directFlashThinking门控。因此 CCA 路径必须另走一条以 wire ID 后缀为主、thinkingConfig为辅的混合方案。数据模型effort 阶梯与 wire 映射ANTIGRAVITY_MODEL_EFFORTS每个折叠模型的可用 effort 阶梯新增导出的ANTIGRAVITY_MODEL_EFFORTS: Recordstring, string[]声明每个 picker 可见基础模型的 effort 档位。按010_models.md的设计初始形态为export const ANTIGRAVITY_MODEL_EFFORTS: Recordstring, string[] { gemini-3.6-flash: [low, medium, high], gemini-3.1-pro: [low, high], claude-opus-4-6-thinking: [low, medium, high, max], };其中 Claude 条目是设计迭代的产物初期方案仅覆盖 Gemini外部验证CLIProxyAPI 与 Anthropic 官方文档确认 CCA wire 对 Claude 同样接受thinkingConfig后claude-opus-4-6-thinking被补充进阶梯后续实现又按/^claude-/前缀推广到claude-sonnet-4-6见 001_research.md 的 commit03eecc4a记录。需要说明的是当前仓库已演进在 antigravity-models.ts 中阶梯已更新为gemini-3.8-flash、gemini-3.7-flash均为 low/medium/high、gemini-3.1-prolow/high以及两个 Claude 模型low/medium/high/max。代码注释特别指出minimal档被 Google 文档标记为当前代错误档CCA 只暴露三档因此阶梯中不包含minimal。ANTIGRAVITY_EFFORT_WIRE_MAPeffort → wire ID对 Gemini 基础模型新增ANTIGRAVITY_EFFORT_WIRE_MAP给出每个 effort 对应的 wire ID。010_models.md时代的对应关系以 3.6 为例const ANTIGRAVITY_EFFORT_WIRE_MAP { gemini-3.6-flash: { low: gemini-3.6-flash-low, medium: gemini-3.6-flash-medium, high: gemini-3.6-flash-high, }, gemini-3.1-pro: { low: gemini-3.1-pro-low, high: gemini-pro-agent, // CCA wire 上的 Gemini 3.1 Pro (High) }, };当前仓库版本与此同构只是 3.6 已换代为 3.8gemini-3.8-flash三个后缀 wire与 3.1-pro。注意gemini-3.1-pro的 high 档 wire 是gemini-pro-agent——它不带任何后缀因此对 pro 而言thinkingLevel是唯一能命名 effort 的通道这与 flash 族的后缀即档位形态不同直接决定了后面 resolver 的差异分支。基础 ID 的上下文窗口显式条目由于折叠后的基础 ID 是 picker 可见的gemini-3.6-flash、gemini-3.1-pro不能再依赖别名派生获得上下文窗口因此在ANTIGRAVITY_MODEL_CONTEXT_WINDOWS中为它们添加显式条目flash 与 pro 均为1_048_5761M token。当前实现位于 antigravity-models.ts折叠基础 ID 显式列出wire ID 与别名通过推导合并。选择器列表折叠前后对比改造前 picker 可见列表来自010_models.md的 Before 列表gemini-3.6-flash-low gemini-3.6-flash-medium gemini-3.6-flash-high gemini-3.1-pro-low gemini-pro-agent claude-sonnet-4-6 claude-opus-4-6-thinking gpt-oss-120b-medium gemini-3.1-pro-high (visible alias → gemini-pro-agent) gemini-3.1-pro-preview (visible alias → gemini-pro-agent)改造后After 列表gemini-3.6-flash (efforts: low, medium, high) gemini-3.1-pro (efforts: low, high) claude-sonnet-4-6 claude-opus-4-6-thinking (efforts: low, medium, high, max) gpt-oss-120b-medium当前实现对应 ANTIGRAVITY_MODELSgemini-3.8-flash当前代、gemini-3.7-flash上一代仍在服务、gemini-3.1-pro、gemini-3.1-flash-image、两个 Claude 与gpt-oss-120b-medium。resolveAntigravityEffortWireModel五级优先级解析核心新函数为resolveAntigravityEffortWireModel(modelId, effort?, baseUrl?)返回{ wireModelId, thinkingLevel? }。调用方用wireModelId填充 CCA 信封的model字段当返回thinkingLevel时写入generationConfig.thinkingConfig { thinkingLevel }。010_models.md给出三条显式优先级当前实现扩展为更细的五条antigravity-models.ts 的注释与代码一致后缀 wire ID 或兼容别名如gemini-3.6-flash-low、gemini-3.5-flash-high经resolveAntigravityWireModelId(modelId)解析。后缀本身就是 effort——原样返回解析后的 wire ID必须禁止发送thinkingConfig否则会构造出model: gemini-3.6-flash-lowthinkingLevel: high的自相矛盾请求。有 effort 映射的基础模型如gemini-3.6-flasheffort 已提供且在阶梯内 → 返回gemini-3.6-flash-{effort}effort 未提供 → 返回默认档的 wire IDflash 为mediumpro 为higheffort 提供但不在映射内如 flash 上要求max→ 钳制到最高支持档并返回对应 wire ID。Claude 模型claude-opus-4-6-thinking等返回模型自身 ID 并附带thinkingLevel——Claude 没有后缀变体thinkingConfig是唯一 effort 通道。单 wire ID 的 Gemini 模型当前实现为gemini-3.7-flash经ANTIGRAVITY_THINKING_LEVEL_MODELS声明档位骑在thinkingLevel上而非后缀 wire缺省档为 medium。其余所有 ID如claude-sonnet-4-6、gpt-oss-120b-medium、未知 ID返回resolveAntigravityWireModelId(modelId)——非别名 ID 即恒等返回。thinkingConfig 发送决策矩阵场景是否发送 thinkingConfig后缀/兼容 ID规则 1否——后缀已编码 effort映射基础模型 显式 effort规则 2是——thinkingLevel: effort双保险CLIProxyAPI 模式映射基础模型 无 effort规则 2 默认档否——默认 wire ID 已编码默认档Claude 显式 effort规则 3模型在阶梯内是——thinkingLevel: effort其余所有 ID否当前实现还引入了一个值得注意的细节ANTIGRAVITY_SUFFIX_TIER_MODELSgemini-3.8-flash在集合内标记每个档位都已由后缀命名的模型此类模型即便命中规则 2 也不发送thinkingLevel——因为-lowwire 配HIGH在 CCA 会返回 200 而非报错响应里到底跑了哪一档无法得知双重声明反而制造不可观测性。gemini-3.1-pro被刻意排除在集合外因为其 high 档是gemini-pro-agent不带后缀。退役代次的重定向规则 0当前实现比010_models.md多出一层规则 0Google 几乎在新一代 Flash 上线时立即从 CCA 撤下上一代RETIRED_FLASH_TIERS把 3.6及原本指向 3.6 的 3.5/3-flash 别名映射到 3.7 的-tieredwire 目标同时携带该 ID 曾经编码的档位。这一设计是为了避免把用户明确选择的高档静默降级成无档 3.7 调用——平面别名做不到这一点因为规则 1 会把任何别名当作后缀即 effort而拒绝发thinkingConfig。兼容别名inbound-only永不进选择器所有后缀 ID 移入ANTIGRAVITY_COMPATIBILITY_MODEL_ALIASES仅用于入站解析、不出现在 picker 中。010_models.md给出的完整别名表gemini-3.6-flash-low → gemini-3.6-flash-low // identity已是 wire gemini-3.6-flash-medium → gemini-3.6-flash-medium // identity已是 wire gemini-3.6-flash-high → gemini-3.6-flash-high // identity已是 wire gemini-3.1-pro-low → gemini-3.1-pro-low // identity已是 wire gemini-pro-agent → gemini-pro-agent // identity已是 wire gemini-3.1-pro-high → gemini-pro-agent // 原有 visible alias gemini-3.1-pro-preview → gemini-pro-agent // 原有 visible alias gemini-3.5-flash-extra-low → gemini-3.6-flash-low // 原有 gemini-3.5-flash-low → gemini-3.6-flash-medium // 原有 gemini-3.5-flash-mid → gemini-3.6-flash-medium // 原有 gemini-3.5-flash-high → gemini-3.6-flash-high // 原有 gemini-3-flash-agent → gemini-3.6-flash-high // 原有当前仓库 antigravity-models.ts 保留了wire 后缀 ID 恒等别名的约定并在此基础上把退役 Flash 代次整体映射到gemini-3.7-flash-tiered。这些别名与ANTIGRAVITY_VISIBLE_MODEL_ALIASES合并为导出常量ANTIGRAVITY_MODEL_ALIASES由resolveAntigravityWireModelId统一消费。上下文窗口同样沿别名链推导L312-L325。激活场景验证来自010_models.mdpicker 显示一次gemini-3.6-flash effort 选择器 [low, medium, high]已保存的gemini-3.6-flash-low配置仍能解析并正确路由已保存的gemini-3.1-pro-high仍解析到gemini-pro-agentocx models列出折叠后的条目。注册表接线与计价registrygoogle-antigravity 条目在 src/providers/registry/entries-core.ts 中google-antigravity条目接入ANTIGRAVITY_MODEL_EFFORTS作为modelReasoningEffortsdefaultModel指向折叠后的基础 ID当前为gemini-3.8-flash。000_plan.md明确说明无需modelReasoningEffortMap——恒等标签由mapReasoningEffort保留。按000_plan.md的跨切面不变量注册表是预设的单一事实来源registry.ts→derive.ts→ CLI/GUIGUI 的模型元数据来自注册表/目录因此本次改造无需改动 GUI picker 组件。modelReasoningEfforts字段并非 Antigravity 独有grok-4.5 使用{ grok-4.5: [low, medium, high] }作为既有范例见001_research.mdreasoning-effort.ts 的mapReasoningEffort与configuredReasoningEfforts()正是消费该字段、把 Codex 推理标签换算到各模型阶梯并完成钳制的入口。expected-prices折叠基础 ID 的计价条目010_models.md要求保留以 wire ID 为键的既有计价条目它们作为别名存活并为折叠基础 ID 新增条目。当前 expected-prices.ts 印证了这一模式gemini-3.8-flash、gemini-3.8-flash-low/medium/high均有条目gemini-3.1-pro与gemini-3.1-pro-low/high、gemini-pro-agent、gemini-3.1-pro-preview各自独立计价历史 3.6 代次条目标注collapsed base ID与derived: gemini-3.6-flash来源。tests/usage-cost.test.ts的 overlay 数量随之更新。从源码结构看canonicalAntigravityUsageModel 通过反向映射ANTIGRAVITY_USAGE_BASE_BY_ID把 effort wire ID 与兼容别名折叠回同一个 picker 基础模型保证一次调用 一行用量。退役 ID 在用量聚合中保留自身身份——路由可以把新 3.6 调用发往 3.7但历史用量行记录的是用户当时真正调用的模型重贴标签会移动历史消费。适配器侧CCA buildRequest 的 effort 解析WP2020_adapter.md定义了适配器改造。当前 google.ts 的 CCA 分支与此完全一致const mappedEffort mapReasoningEffort(provider, parsed.modelId, parsed.options.reasoning); const { wireModelId, thinkingLevel } resolveAntigravityEffortWireModel( parsed.modelId, mappedEffort, provider.baseUrl, ); antigravityModel wireModelId; // ... if (thinkingLevel || includeThoughts) { const gc (body.generationConfig ?? {}) as Recordstring, unknown; gc.thinkingConfig { ...(thinkingLevel ? { thinkingLevel } : {}), ...(includeThoughts ? { includeThoughts: true } : {}), }; // ... }解析发生在构建 CCA 信封之前mapReasoningEffort先把 Codex 推理标签按配置阶梯钳制resolveAntigravityEffortWireModel再把基础模型 已钳制 effort换算成 wire ID 与 thinkingLevel。antigravityModel由此成为 effort 解析后的 wire IDCCA 信封的model字段与request.generationConfig.thinkingConfig.thinkingLevel共同构成最终请求。后缀 ID 优先矛盾请求预防当已保存配置携带后缀 ID如gemini-3.6-flash-low且用户显式设置reasoning: high时mapReasoningEffort可能仍返回high后缀 ID 不在modelReasoningEfforts中不发生钳制resolveAntigravityEffortWireModel经规则 1 检测到后缀 ID返回{ wireModelId: gemini-3.6-flash-low, thinkingLevel: undefined }不发送thinkingConfig——后缀已编码 effort。这避免了model: gemini-3.6-flash-lowthinkingLevel: high的矛盾信封。钳制示例mapReasoningEffort在到达 resolver 前按配置阶梯钳制020_adapter.md给出的对照表模型请求档钳制后Wire IDgemini-3.6-flashmaxhigh阶梯最高档gemini-3.6-flash-highgemini-3.6-flashultramax→highultra→max 边界后钳制gemini-3.6-flash-highgemini-3.1-promediumlow[low,high] 中最近的不高于请求的档gemini-3.1-pro-lowgemini-3.1-promaxhighgemini-pro-agentclaude-opus-4-6-thinkingmaxmax在阶梯内自身 ID thinkingConfigclaude-opus-4-6-thinkingultramaxultra→max 边界自身 ID thinkingConfig默认档flash 为medium对齐当前defaultModel注册表默认pro 为high对齐gemini-3.1-pro-high → gemini-pro-agent作为主条目的既有可见别名。与 replay cache 的交互replay cache 以(antigravityModel, sessionId)为键。由于antigravityModel是解析后的 wire ID如gemini-3.6-flash-high不同 effort 级别自然获得隔离的缓存条目——同一会话内从medium切到high会得到全新 replay 条目因为不同思考强度产生不同的 thought 签名。这与001_research.md记录的在 google.ts 中先解析 wire ID 再进 replay 调用的顺序约束一致。验证方式010_models.md给出的最小验证命令bun run typecheck bun test tests/provider-registry-parity.test.tsWP2 扩展为聚焦测试集020_adapter.mdbun test tests/google-antigravity-wire.test.ts tests/reasoning-effort.test.ts tests/usage-cost.test.ts tests/google-models-listing.test.ts tests/google-antigravity-replay.test.ts tests/provider-registry-parity.test.ts测试面覆盖wire 解析/列表 fixturegoogle-antigravity-wire.test.ts、google-models-listing.test.ts、resolver 单元测试reasoning-effort.test.ts、计价 overlay 计数usage-cost.test.ts、注册表一致性provider-registry-parity.test.ts以及按 effort 级别隔离的 replay 缓存键google-antigravity-replay.test.ts。000_plan.md以bun run typecheck 聚焦bun test作为工作完成的验证器verifier。设计要点回顾单一事实来源ANTIGRAVITY_WIRE_MODELS保持完整 wire 列表用于解析ANTIGRAVITY_MODELS是折叠后的 picker 列表effort 阶梯与映射独立维护。wire 来源即 Antigravity:fetchAvailableModels后端与agyCLI 解析标签的同一来源。后缀与 thinkingConfig 不混用后缀 ID 绝不发送thinkingConfig避免矛盾请求与不可观测的档位漂移。兼容别名保证存量配置已保存后缀 ID 无需迁移即继续可用退役代次当前为 3.6→3.7通过层级映射在重定向时保留用户选择的档位。Claude 的 effort 通道不同Gemini 走 wire 后缀Claude 走thinkingConfig.thinkingLevel两者在同一个 resolver 返回类型{ wireModelId, thinkingLevel? }下统一。解析发生在信封构建之前适配器先mapReasoningEffort钳制、再resolveAntigravityEffortWireModel定 wire随后才有机会写thinkingConfig与 replay 缓存键。相关后续工作项见 WP3聚焦测试完整路线见 000_plan.md研究依据与外部验证CLIProxyAPI 模式、Anthropic 官方文档、agy CLI 目录见 001_research.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点击查看免费下载相关推荐opencodex 中 Google AntigravityCCA推理强度到线模型 ID 的路由解析实现指南opencodex 中 Google AntigravityCCA推理强度到线模型 ID 的路由解析实现指南 导读 本文讲解 opencodex 项目中 Gopencodex AntigravityCloud Code Assist推理档位路由全解模型 ID 编码、thinkingConfig 双通道与 effort 解析实现剖析opencodex AntigravityCloud Code Assist推理档位路由全解模型 ID 编码、thinkingConfig 双通道与 efopencodex 的 Antigravity Effort 路由实战把 Gemini/Claude 思考档位折叠为单一模型入口的服务端方案opencodex 的 Antigravity Effort 路由实战把 Gemini/Claude 思考档位折叠为单一模型入口的服务端方案 本篇以 devl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
