Skip to content

允许手动覆盖自定义端点模型的上下文上限声明值 #4863

Open

Description

@cindy-issue

提交人: Boss
客户端版本: 0.1.90


场景

通过自建 API 中转站接入模型时,接口返回的模型元数据中声明的上下文长度可能不准确——声明值小于模型真实能力(例如上游声明约 200K tokens,但模型实际支持 1M tokens)。

现状

在模型设置中把「上下文上限」填为超过上游声明值的数值时,界面会提示「已超过上游声明的长度,可能导致请求失败」,并且无法保存该设置。设置页同时展示「上游最大上下文」为声明值,用户没有途径覆盖它。

影响

当中转站声明的上下文长度与模型真实能力不符时,用户无法把 Cindy 的上下文上限设置成模型实际支持的大小,长会话会提前受限,只能等待上游修正元数据。

诉求

希望允许用户自由覆盖上游声明的上下文上限:输入超过声明值时允许保存,同时保留风险提示(可能影响请求成功),由用户自行判断和承担风险。

提交时的任务环境

仅代表提交时快照,不一定是故障环境。OS 来自提交客户端本机,不含 SSH 远端主机;Harness / 模型来自当前任务。与运行环境无关的反馈可忽略本段。
版本区域: CN
OS: win32 x64 (10.0.26200)
Harness: Claude Code
Model ID: glm-5.3-flash-hs
界面语言: zh-CN

Activity

  1. dash-s-cindy commented on Sep 22, 2026

    @dash-s-cindy

    判断

    允许把「上下文上限」填成超过上游声明值、保存后保留风险提示,这是 Cindy 已经成文并实现的产品行为:当前 main 的设置编辑器、持久化存储和三引擎运行时都按这个语义工作,并有直接测试锁定。0.1.90 报告的「无法保存」与 main 的已测行为不一致,需要先在发布包上区分差异来源(发布构建滞后、提交在途显示回闪、写入回滚或输入格式),而不是把它当作缺失能力重新设计。另外说明一点现有结构:「上游最大上下文」是只读事实行,「上下文上限」才是可写的用户 override,两者本就分开。

    行动

    1. 发布包复现(优先):在 Windows 0.1.90(及 0.1.91 Beta)上,用自定义供应商(OpenAI 兼容中转)的模型打开 设置 → 模型 → 高级,「上下文上限」输入 1000(编辑器单位是 K,1 K = 1,000 tokens)后失焦提交。记录:值是否回弹为声明值;是否出现「未保存,请重试。」(contextWriteFailed)或「请输入 X–100,000 K 的整数。」(contextInvalid);重开抽屉后输入框是否保持 1000;owner 目录下 model-context-limit-prefs.json 是否新增条目;新会话的上下文环 / 压缩阈值是否按 1M 生效。
    2. 按复现结果分支处理:
      • 若发布包把超窗值判为无效或拒绝保存 → 与 main 测试行为冲突,按发布差异处理,随下一版本带上 main 已有行为(超窗可保存 + 保留警告);
      • 若保存实际成功、但提交在途输入框闪回旧值导致用户以为没保存 → 推进 feat(desktop): 模型图片输入能力本地声明与运行期对账 #4856(ctxCommitting 收口)合并发布;该 PR 同时修复「上游最大上下文」把 200K 兜底值当上游窗口显示的问题,直接改善本场景的可理解性。
    3. 不做的事:不新增「不超过上游声明值」的校验或拦截——存储层与开发规则均明确显式 override 可以超过目录声明值;现有警告文案(「已超过上游声明的长度,可能导致请求失败。」)与 100M 量级护栏(防误输天文数字)保留。若核实后认为单位 / 范围提示不够清晰,文案微调作为待产品确认项另行处理,不并入本次修复。

    现状核对(基于 main 快照 5b579ee)

    • 编辑器(apps/desktop/src/renderer/components/settings/ModelAdvancedDrawer.tsx):「上下文上限」失焦提交,写入该模型行的全部可用引擎;校验只有防误设下限(默认 100K,小模型按自身窗口适配,已识别本地运行时 1K)与 100M 量级上限,超过上游声明窗口只触发 contextLimitOverWindow 警示,不阻断保存。测试 apps/desktop/src/renderer/components/settings/__tests__/ModelAdvancedDrawer.test.tsx 中:
      • allows an intentional override above the maximum and rejects invalid input:输入超过 contextWindowMax 的 1200K,警告可见,且 setLimit(1_200_000) 成功提交;
      • preserves an existing precise override, warns above the exact maximum:已保存的超窗 override 保持原值不被改写,「恢复默认」正常。
    • 持久化(apps/desktop/src/main/maker-host/model-context-limit-store.ts):写入只 clamp 到 [1K, 100M];头注明确「不 clamp 到模型窗口:路由把窗口配错(下发值小于模型实际能力)时,用户得能强行往上填把自己解开;UI 侧超过上游窗口会给警示」。
    • IPC 写入(apps/desktop/src/main/maker-ipc/providerHandlers.ts,MODEL_CONTEXT_LIMIT_SET):写入前做目录可用性校验;运行时刷新失败或账号代次过期会回滚本次写入,UI 显示「未保存,请重试。」——这是发布包上真实可能「保存失败」的路径。
    • 运行时生效:三引擎消费同一预算(docs/dev-rules/model-catalog-runtime.md「三引擎上下文预算(2026-09-09)」);fix(codex): honor custom provider context windows #3497 打通 Codex 自定义供应商显式窗口,fix(codex): 让模型上下文设置实际生效并自动恢复压缩失败 #4016 实测 Codex 1M 读回,fix(context): 修复小预算空回复与上下文圆环回退 #4233 实测三引擎预算切换。
    • 规则文档(docs/dev-rules/model-catalog-runtime.md):「显式设置可以超过原生目录默认最大值;它改变 CLI 预算,不改变供应商实际能接受的长度」「显式上下文 override 仍优先,可设置 1M」。

    与报告现象的候选解释(待复现区分,均未定论)

    相关记录

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions