Claude Desktop 3P 模型槽位实验：本名 ID、日期后缀映射与 effort/缓存行为实测确认

Claude Desktop 3P 模型槽位实验本名 ID、日期后缀映射与 effort/缓存行为实测确认【免费下载链接】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 仓库中 Claude inbound 单元devlog/_fin/260711_claude_inbound的实测定稿整理。它记录了一次面向Claude Desktop 第三方3P配置的真实用户验证实验claude-opus-4-8本名 ID 与claude-opus-4-8-20260704日期后缀槽位如何经过 modelMap 映射到代理后的真实模型effort推理强度滑块与 prompt 缓存如何随 1 级模型名触达 wire以及下一版日期后缀槽位自动发放 层级默认模型的规格草案。读完本文你将掌握 opencodex 中 Desktop 3P 模型槽位的可用行为边界、已知缺陷与可落地的改进路径。实验背景Desktop 3P 的模型可见性链路opencodex 通过ANTHROPIC_BASE_URL环境重定向让 Claude Code / Claude Desktop 走自己的/v1/messages入站详见 000_plan.md 的 D1/D4/D5 决策。对 Claude Desktop 而言模型在系统内置 picker 中的可见性由 3P 配置驱动modelDiscoveryEnabled顶层级开关 inferenceModels静态列表官方 3P 架构字段name、labelOverride、supports1m、anthropicFamilyTier、isFamilyDefault/v1/models的 ModelInfo 全形态响应capabilities.effort、capabilities.thinking等能力声明见 131_research_desktop_effort_wire.md。关键结论来自 138_pro_answer.md 与 140_cycle2_build_check_record.md静态列表优先于 discovery合并不存在supports1m不是把裸行变成 1M而是额外生成一行带[1m]的变体用户选中该行后 wire 上才会出现anthropic-beta: context-1m-2025-08-07effort 选择器则由内建内核的id 识别决定——opus-4-8形态的别名能打开完整 low..max 阶梯。本单元141_desktop_slot_findings.md正是在此基础上的用户 Desktop 实测确认验证两代槽位方案本名 ID 与日期后缀在真实 Desktop 上的表现并据此敲定下一版规格。实测确认 1本名 ID 槽位claude-opus-4-8全链路打通用户用 Desktop 对claude-opus-4-8槽位做了实机验证结论如下验证点结果modelMap 映射claude-opus-4-8→ terra 成功effort 滑块正常打开medium/xhigh能一路到达 wireoutput_config.effort缓存行为缓存正常工作—— 本名 ID 被当作 1 级first-class模型处理cache_control正常生效这意味着只要模型 ID 是本名裸claude-opus-4-8形态Desktop 就把请求当作官方 Anthropic 模型处理effort 序列化与 prompt 缓存cache_control都按原生路径走。这与 136_cycle2_plan_context_effort.md 中opus 形态 id 的 effort 直列化已经可用的判断完全一致——effort 的残余问题只剩匹配不到 opus 的真实 Anthropic 非 opus id而这属于正常行为。实测确认 2日期后缀槽位claude-opus-4-8-20260704精确分离路由第二个槽位形态是带日期后缀的 ID路由claude-opus-4-8-20260704→ sol精确分离与上面 terra 走不同真实模型effort正常工作modelMap 匹配优先级精确匹配优先于日期剥离。也就是说claude-opus-4-8-20260704可以被单独注册、单独映射到不同模型而不会被剥掉日期后缀再匹配的逻辑抢先命中。这对多模型并存的意义在于日期后缀就是天然的槽位命名空间—— 同一个本名家族下可以挂任意多个不同后缀每个后缀对应一个真实模型互不冲突。实测确认 3labelOverride 显示与 name 去重语义labelOverride被 Desktop 尊重实测 picker 中显示为Opus 4.8 (GPT 5.6 Terra)即显示名 本名标签 括号内真实模型名。这让用户在界面上直接看到代理后的真实模型避免误选。同名不可重复注册两个name相同的条目会被 Desktop 视为同一项并一起被拾取按 name 判定同一性。因此不能靠重复 name 制造多个入口不同槽位必须使用不同 name这正是日期后缀方案存在的原因之一。实测确认 4Desktop 工具调用title/summary 侧呼与配额Desktop 每轮对话会发起2 次工具侧呼用于生成标题/摘要模型claude-sonnet-5开销约 1.3 万 token 摘要 36 token 标题configuredTier fast。这 2 次侧呼消耗的是纯正 sonnet 配额走官方模型名无法被本名槽位拦截。缓解手段是下一版规格中的可选项通过modelMap把claude-sonnet-5映射到低价模型——代价是放弃纯正 sonnet 的质量。已知限制用户实测确认1. 会话间槽位切换不可靠opus-4-8↔opus-4-8-20260704之间的切换如果跨会话就会失败。根因被归类为 Pro 版报告的__model_selector_state规范化缺陷Desktop 内核对模型选择状态做了后缀规范化导致会话重建后无法记住带日期后缀的选择。这是 Desktop 应用侧缺陷代理侧无法修复138_pro_answer.md 中同样的缺陷族1M 行选择不持久化。2. 上下文窗口是二进制的Desktop 3P 架构中没有数字字段可以表达任意上下文大小只有两档200k默认与 1M选中supports1m行无法取中间值如 400k/600k对比CLI 可以通过CLAUDE_CODE_MAX_CONTEXT_TOKENS设置任意值配合DISABLE_COMPACT1成对注入见 140_cycle2_build_check_record.md。下一版规格用户指示尚未实现槽位自动发放claude-opus-4-8-2026MMDD为每个路由模型自动生成一个带日期后缀的槽位命名claude-opus-4-8-2026MMDD日期生成2026 年范围内的无重复随机数由模型 route 哈希映射到有效日期并做冲突规避显示labelOverride Opus 4.8 (真实模型名)上下文contextWindow 1M时置supports1m落地方式ocx claude desktop自动写入槽位列表 modelMap。这样用户无需手工维护每个模型的别名条目重新运行ocx claude desktop即可刷新槽位集。层级默认模型opus / sonnet / haiku/fableClaude Code 的子代理subagent按opus / sonnet / haiku/fable别名调用模型因此需要在 GUI 中为每个层级指定默认槽位层级定位默认槽位opus主力 —— 复杂设计/调试现有 opus 代表项sonnet均衡 —— 实现/调查需新建haiku轻量 —— 探索/分类/摘要需新建fable显式选择需新建实现方式给每层代表项赋予anthropicFamilyTiertierisFamilyDefaulttrue。当前实现里所有条目都还是 opus 层级sonnet/haiku 层级条目需要新建。工具调用节省可选claude-sonnet-5→ 低价模型的modelMap切换开关用于在 Desktop 侧呼占用量大时降低成本。分支分离策略按用户指示Desktop 3P 功能与 Claude Code CLI 线在 git 分支上严格隔离claudedesktop分支Desktop 3P 功能开发/测试专用用户单独测试claudecode分支Claude CodeCLI交付线保持稳定Desktop 新工作不混入。这样 CLI 线的发布不受 Desktop 实验影响CLI 线的完整交付记录见 050_close.md。源码侧支撑点上述实验结论在仓库中有对应的实现与诊断设施Desktop 3P 配置生成src/claude/desktop-3p.ts —— 3 值模式static 默认 / hybrid / discovery、supports1m判定仅 authoritativecontextWindow 1M、parseDesktop3pModeArgs互斥参数解析入站模型解析与别名src/claude/inbound.ts、src/claude/alias.ts ——[1m]残留防御性剥离、别名解码消息路由与 effort 安全网src/server/claude-messages.ts —— 仅当supportedLadderFor(route) []时移除reasoningunknown 路由放行尊重 opt-in 用户意图入站调试捕获环src/claude/inbound-debug.ts —— 环形缓冲记录output_config.effort、anthropic-beta头、metadata.user_id存在性等 allowlist 标量配套GET /api/claude/inbound-debugsrc/server/management-api.ts与 GUI Debug 页展示——本次实验的output_config.effort到达确认正是靠它完成验证口径140_cycle2_build_check_record.md 记录bun x tsc --noEmit干净、bun test2213 pass / 0 fail9384 expect、gui build 成功以及 desktop-3p 模式 4 分箱、parser 5 分箱、supports1m 边界等激活证据。尚未确定项Desktop 打开别名的 effort UI 的精确条件仍是非公开的依赖构建版本。若切换静态列表后仍不显示备选方案有两条(a) 精确claude-opus-4-8裸本名别名实验用 profile 区分路由(b) 按 effort 拆静态条目...-low/-high/-max作为 fallback——两者都留待下一循环。Desktop 进程对CLAUDE_CODE_*环境变量的消费不保证诊断手段launchctl setenv后重启 Claude 应用因此 env 杠杆主要面向 CLI138_pro_answer.md 判据 4。一句话总结claude-opus-4-8本名槽位在 Desktop 上effort 全通 缓存正常日期后缀槽位提供精确分离路由能力但跨会话切换与上下文中间值是应用侧硬边界下一版通过日期后缀随机槽位自动发放与 opus/sonnet/haiku 层级默认模型把这两条能力固化成默认体验。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考