★ FEATURED ARTICLE 人工智能AI 应用AI Agent交互助手MCP Clients本地部署【免费下载链接】CodePilotA multi-model AI agent desktop client — connect any AI provider, extend with MCP skills, control from your phone. Built with Electron Next.js.项目地址https://gitcode.com/gh_mirrors/co0dep/CodePilot点击查看免费下载本文以仓库内 docs/research/glm-5-3-codeplan-adaptation-2026-08-14.md 为骨架结合 src/lib/provider-catalog.ts、src/lib/codex/effort.ts、src/lib/codex/runtime.ts、src/lib/codex/proxy/unified-adapter.ts 等源码系统讲解 CodePilot 是如何把智谱 GLM Coding Plan 的 GLM-5.3 模型阵容接入 Claude Code 与 Codex 两条请求链路并处理模型 ID 改写、推理档位兼容、1M 上下文与积分提示的。读完你可以掌握GLM Coding Plan 的官方能力合同、Claude[1m]与 Codex bare ID 的差异、effort 兼容映射的建模方式以及 CodePilot 在无真实凭据情况下的验证边界。一、核验背景与结论概览2026-08-14 的核验针对智谱 GLM Coding Plan 中国区 / 国际区、Claude Code、Codex 与 CodePilot 模型目录、请求链路四个层面。核心结论如下GLM-5.3 已在 Coding Plan 全量开放通用 API 仍标注即将上线。因此本轮适配只更新已有glm-cn/glm-global的 CodePlan 预设不虚构尚未开放的 PAYG API 入口。当前 CodePlan 主目录为GLM-5.3、GLM-5-Turbo、GLM-4.7。GLM-5.2 / 5.1 请求会由上游自动路由到 5.3但 CodePilot 目录直接展示官方当前名称不再把旧别名当作当前模型。GLM-5.3 是文本输入 / 文本输出模型官方标称 1M context、最大输出 131,072支持 function calling、streaming、caching、structured output 与 MCP。图片能力来自套餐附带的 GLM-4.6V Vision MCP不应把 GLM-5.3 本体标成 vision model。Claude 与 Codex 的模型 ID 不同Claude 配置使用glm-5.3[1m]Codex 原生 Responses 使用裸glm-5.3。CodePilot 只保留一个用户可见的 GLM-5.3 行在 transport capability 中做精确 ID 改写避免重复模型。GLM-5.3 实际推理档位为 Low / High / Max默认 Max。CodePlan 兼容层把minimal/light/low → low、medium/high → high、xhigh/max/ultra → max显式 effort 优先于 thinking toggle。官方 Codex 配置为原生 OpenAI ResponsesCNhttps://open.bigmodel.cn/api/v1Globalhttps://api.z.ai/api/v1。GLM-5.3 支持 reasoning summaries、parallel tool calls 与 freeform apply_patch不支持 verbosityinput modality 仅 text。GLM-5-Turbo 也在官方 Codex 目录context 204,800官方没有给它可选 effort allowlist所以 CodePilot 不展示推理档位但 Codex Runtime 仍走原生 Responses。积分倍率GLM-5.3 输入 / 缓存输入 / 输出倍率为 6.9 / 1.7 / 24非高峰按表列积分的 50% 消耗高峰为工作日 14:00–18:00UTC8。仓库旧的高峰 3 倍提示已删除。二、第一方事实源官方合同矩阵核验的每一项结论都锚定官方第一方文档中国区与国际区为同一产品合同。事实源矩阵如下事实中国区国际区GLM-5.3 能力、1M/128K、文本 modalityGLM-5.3 模型页智谱文档同一产品合同当前 CodePlan 模型、三档 effort 与兼容映射最新模型切换页Latest model当前目录、旧版本自动路由、积分与高峰规则Coding Plan 概览Coding Plan overviewCodex Responses endpoint、模型 ID 与 capabilityCodex 集成Codex integrationClaude 的[1m]ID 与 compact windowClaude Code 集成Claude Code integration这套事实源在仓库中的对应实现与注释均有交叉印证例如 src/lib/provider-catalog.ts 的注释明确指出GLM Coding Plan catalog 由中国区与国际区两个 preset 共用阵容相同、区域端点不同并于 2026-08-26 按官方最新模型页刷新证据矩阵记录在 docs/research/glm-5-3-flash-codeplan-adaptation-2026-08-26.md。三、1M 上下文的取值纪律1,000,000 而非 1,048,576官方标称1M context后产品侧需要落地为一个具体数值。核验结论明确2026-08-26 引用精度复核后产品按官方配置值使用1,000,000不再把 1M 擅自解释为 1,048,576。原因在于官方模型页与配置示例中使用的是十进制1,000,000仓库没有找到把 1M 精确写成1,048,576二进制 Mi的第一方依据。采用十进制可以在接近满窗时避免高估余量贴近官方 CLI 的真实行为。仓库落地见 src/lib/model-context.tsglm-5.3-flash与相关 GLM 条目都登记为1_000_000并注释强调不要按 Mi 重新解释十进制 1M同时glm-5-turbo按官方登记为 202,752 的窗口。[1m]后缀则通过最长 key 匹配解析保证 Claude 路径拿到的是带[1m]的完整 ID见 src/lib/model-context.ts 中context1m选项返回1_000_000的逻辑。四、双协议模型 ID 分流Claude[1m]与 Codex bare IDGLM-5.3 在同一 Coding Plan 下走两条不同的请求链路模型 ID 并不相同Claude / Anthropic 路由使用glm-5.3[1m]带[1m]后缀表示 1M 上下文契约Codex 原生 Responses 路由使用裸glm-5.3。如果给同一模型建两行用户会在 picker 里看到重复的 GLM-5.3。CodePilot 的做法是目录里只保留一个用户可见行transport 层面的 ID 改写声明在精确的 wire capability 中。以 CN preset 为例src/lib/provider-catalog.tswireCapabilities: { anthropicEffort: { modelIds: [glm-5.3[1m], glm-5.3-flash[1m]] }, codexResponses: { baseUrl: https://open.bigmodel.cn/api/v1, modelIds: [glm-5.3[1m], glm-5.3-flash[1m]], modelIdOverrides: { glm-5.3[1m]: glm-5.3, glm-5.3-flash[1m]: glm-5.3-flash, }, effortAliases: { minimal: low, medium: high, xhigh: max }, supportsReasoningSummary: true, }, },Global presetsrc/lib/provider-catalog.ts结构相同仅 baseUrl 换成https://api.z.ai/api/v1。这段能力声明正是聚合渠道不得继承的边界ID 改写只存在于 GLM 供应商自己的精确 wire capability 内其他第三方聚合 preset 不会误套。对应地src/lib/provider-resolver.ts 在解析 Codex 链路时会把完整/responses的CODEX_API_ENDPOINT去掉尾部/responses因为ai-sdk/openai会自行追加同时 Codex Runtime 使用 capability 给出的 Responses 模型 ID而不是复用 Anthropic upstreamsrc/lib/provider-resolver.ts。Claude 路径的环境变量两条 preset 还通过defaultEnvOverrides注入 Claude Code 子进程所需的环境src/lib/provider-catalog.tsdefaultEnvOverrides: { API_TIMEOUT_MS: 3000000, CLAUDE_CODE_AUTO_COMPACT_WINDOW: 1000000, ANTHROPIC_DEFAULT_HAIKU_MODEL: glm-5.3-flash[1m], ANTHROPIC_DEFAULT_SONNET_MODEL: glm-5.3[1m], ANTHROPIC_DEFAULT_OPUS_MODEL: glm-5.3[1m], },其中CLAUDE_CODE_AUTO_COMPACT_WINDOW1000000与官方 1M 配置一致三个ANTHROPIC_DEFAULT_*_MODEL分别把 haiku / sonnet / opus 槽位映射到 GLM-5.3-Flash 与 GLM-5.3。注意compact-window 环境变量进入 managed cleanup切换服务商时不会泄漏到其他 provider 的子进程环境。五、推理档位effort的建模三档 UI 六档兼容别名GLM-5.3 的实际推理档位为Low / High / Max默认 Maxthinking 恒为开启的 always-thinking 模型。CodePlan 兼容层在 wire 上做别名折叠用户/上游表达折叠结果minimal、light、lowlowmedium、highhighxhigh、max、ultramax两条纪律很关键显式 effort 优先于 thinking toggle——用户明确选择的档位不会被 thinking 开关覆盖兼容别名建模在 first-party Responses wire 上medium/xhigh不会被展示成额外的真实档位产品的通用菜单只暴露 Low / High / Max。目录侧的能力声明见 src/lib/provider-catalog.tsGLM-5.3 的capabilities为capabilities: { reasoning: true, toolUse: true, contextWindow: 1_000_000, supportsEffort: true, supportedEffortLevels: [low, high, max], defaultEffortLevel: max, effortNoteKey: messageInput.effort.note.glmCodePlan, thinkingMode: always, },GLM-5-Turbo 的差异在于官方没有给它可选 effort allowlist因此 CodePilot 不展示推理档位无supportsEffort但它在 Codex Runtime 仍建立原生 Responses contextsrc/lib/provider-resolver.ts 中 verified Responses transport 与 effort allowlist 分离。别名映射在适配层如何生效src/lib/codex/proxy/unified-adapter.ts 负责把 Codex 传来的reasoning.effort翻译成各 SDK 的 providerOptions。其关键行为可对照 src/lib/codex/proxy/unified-adapter.tsOpenAI Responses 通过providerOptions.openai.reasoningEffort表达SDK 层面reasoning.effort若未归类为 reasoning 模型会被丢弃因此需要 preset 上下文来覆盖GLM 显式使用xhigh → max而 DeepSeek 显式保留xhigh → high——删除了所有 first-party 都把 xhigh 折成 high的隐式 DeepSeek 特判每个供应商的别名由自己的 preset 声明GLM-5-Turbo 保留 reasoning summary但不发送供应商未声明的reasoning.effort。CodePilot Provider → Codex turn/start 的 effort 合同src/lib/codex/effort.ts 实现了两套解析路径resolveCodexEffortsrc/lib/codex/effort.tsCodex Account 自有模型走 per-modelmodel/listallowlist模型声明什么就原样发什么包括真实存在的xhigh/max未声明的档位直接省略而非折成邻近档位resolveCodexProviderEffortsrc/lib/codex/effort.tsCodePilot Provider如 GLM的模型不出现在 Codex Account 的model/list中因此以精确 catalog 为语义 allowlist对xhigh/max这类扩展枚举值还需要第二重证明——本机 app-server 的model/listvocabulary 或版本下限。版本判断复用严格、prerelease-aware 的codex --version解析器CODEX_PROVIDER_EXTENDED_EFFORT_MIN_VERSION 0.144.2src/lib/codex/effort.ts这是本仓库实际验证过同时接受xhigh与max两种 token 的保守下限。0.144.2-alpha.*与夹带在 user-agent 中的无关三元组不会误放行。旧 / 未知 binary继续可见失败fail-visible——抛出明确错误提示升级 Codex绝不静默夹成 High也不误导用户去刷新 Codex Account 模型。clampCodexEffortsrc/lib/codex/effort.ts只作为无 capability 信息时的保守回退。在 src/lib/codex/runtime.tsGLM-5.3 的显式 Max 与 Auto→catalog 默认 Max 都原样进入turn/start的effort字段turn/start同时携带model覆盖项。六、存量数据的 read-through 与 DB-wins 策略适配旧模型行列涉及历史数据库中的存量模型行。核验结论与实现原则src/lib/provider-resolver.tscatalog 管理的旧 DB 行在 read path 使用当前 catalog metadata确保 picker 与实际 wire 同时更新——例如旧指纹sonnet → GLM-4.7 / GLM-5-Turbo / GLM-5.2被 catalog 的legacyFingerprints捕获见 src/lib/provider-catalog.tsread-through 时对齐为当前GLM-5.3manual / user-edited 行继续 DB-wins用户手工改过的模型行不被 catalog 覆盖后续 Flash 适配进一步明确非破坏 merge升级稳定haiku槽并补当前缺失行但不删除或禁用已持久化的 GLM-5-Turbo / GLM-4.7 等历史行显式清理走用户操作或 preview-first 迁移见 docs/research/glm-5-3-flash-codeplan-adaptation-2026-08-26.md。七、积分提示与高峰规则GLM Coding Plan 采用积分制preset 的meta.notesCN 与 Global 一致含中英文见 src/lib/provider-catalog.ts内置了当前积分提示GLM-5.3输入 6.9、缓存输入 1.7、输出 24倍率GLM-5.3-Flash输入 2.3、缓存输入 0.56、输出 8支持原生图片输入非高峰时段按表列积分的 50% 消耗高峰时段为工作日 14:00–18:00UTC8。仓库只展示倍率不推算用户余额或承诺固定百分比旧的高峰 3 倍提示已随本轮核验删除。八、验证边界哪些已验、哪些未验核验文档严格区分已验证与未验证docs/research/glm-5-3-codeplan-adaptation-2026-08-14.md已验证catalog/schema、CN/Global endpoint、Claude[1m]与 Codex bare ID 分流、存量 catalog 行 read-through 持久化对齐、Low/High/Max Anthropic body、六档 Codex compatibility 映射、CodePilot catalog→Codex effort contract 的显式 Max / Auto→Max / Codex Account 无目录缓存时的0.144.2本机 binary gate / 旧 binary fail-visible以及 production Responses factory 的 URL / Bearer / model / reasoning body。Turbo 的 production outbound body 已证明使用原生 Responses、保留 summary 且不含 effort。未验证真实 CodePlan 凭据的 Claude Code 完整 turn、Codex Runtime 完整 turn、账号套餐 entitlement 与实际积分。没有真实凭据前只记Tests pass不记Smoke passed——这是仓库对事实边界的明确纪律synthetic 定向验证通过不代表真实套餐可用。九、延伸阅读后续阵容更新与 GLM-5.3-Flash 的接入结论docs/research/glm-5-3-flash-codeplan-adaptation-2026-08-26.md模型目录与双协议 capability 的源码实现src/lib/provider-catalog.tsProvider 解析与 DB read-through 策略src/lib/provider-resolver.tsCodex effort 合同与版本门控src/lib/codex/effort.ts、src/lib/codex/runtime.tsResponses 适配与供应商级别名声明src/lib/codex/proxy/unified-adapter.ts1M 上下文取值纪律src/lib/model-context.ts赞分享人工智能AI 应用AI Agent交互助手MCP Clients本地部署【免费下载链接】CodePilotA multi-model AI agent desktop client — connect any AI provider, extend with MCP skills, control from your phone. Built with Electron Next.js.项目地址https://gitcode.com/gh_mirrors/co0dep/CodePilot点击查看免费下载相关推荐如何快速上手VPP零基础入门到实战部署完整教程如何快速上手VPP零基础入门到实战部署完整教程 VPPVector Packet Processing是一款高性能的网络数据平面软件它采用向量处理技术实网络通信高性能计算端侧AI新突破智谱GLM-Edge模型本地部署与场景落地全解析端侧AI新突破智谱GLM Edge模型本地部署与场景落地全解析 随着人工智能技术向终端设备渗透端侧大模型部署已成为行业关注焦点。智谱AI最新发布的GLM E人工智能大模型LLM/VLM含推理VoltAgent 接入 Zhipu AI Coding Plan智谱编程模型的路由配置与源码实现解析VoltAgent 接入 Zhipu AI Coding Plan智谱编程模型的路由配置与源码实现解析 导读 本文以 VoltAgent 官方文档 zhipu人工智能AI AgentAgent 框架后端多智能体RAG工具调用Agent 记忆Agent 工作流AI 评测MCP 服务MCP Clients语音上一篇3D重建的未来趋势基于DUSt3R的端到端解决方案深度分析下一篇CANN/asc-devkit Move数据搬入函数创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
