fix(core): sync Volcengine Agent Plan catalog with the official plan

[Astro-Han]

Summary

The Volcengine Agent Plan gateway exposes no model-list endpoint its plan key can reach and has no models.dev snapshot, so its catalog in Maka is a hand-maintained mirror of the official plan page and its model release/retirement announcements. That mirror had drifted from what the plan actually serves:

• glm-5.3-flash (launched 2026-08-28, natively multimodal, 1024k context / 128k output) was missing entirely.
• minimax-m3 now serves the plan page's 1024k context window (transcribed as 1_024_000); we shipped 512k.
• glm-5.2 (service ended 2026-08-31, gateway auto-routes to glm-5.3), kimi-k2.6 (ended 2026-08-18) and minimax-m2.7 (2026-08-04 retirement batch) were retired upstream while their metadata still described them as active.

This PR mirrors the official facts as of 2026-09 (sourced note added above the table in model-metadata.ts; the page's table literal "1024k" is transcribed as 1_024_000): it offers glm-5.3-flash with its published limits and vision support, corrects minimax-m3's window, and marks the three retired ids deprecated so existing connections keep sending while the catalog records the retirement. glm-5.3's limits are normalized to the plan page's 1024k/128k like its siblings.

Behavior change: yes, catalog-level — a new selectable model on Agent Plan, a corrected context window (which feeds the context-budget policy), and retirement recorded for three ids. No migration impact: fallback lists are not an allowlist (#3330), so stored connections are unaffected.

Verification

• New tests in packages/core/src/__tests__/model-metadata.test.ts pin the three obligations above; each failed against main and passes with the change.
• npm run test:dist --workspace @maka/core → 771 pass, 0 fail.
• npm run test:dist --workspace @maka/runtime → 3162 pass, 0 fail (includes the Agent Plan connection-probe and context-budget suites).
• npm run test:dist --workspace @maka/runtime-host → 0 fail (includes the Agent Plan fallback-catalog replay).
• npm run format, npm run lint, @maka/core typecheck → clean.

Not run: full-repo npm test (not requested); desktop E2E (no UI flow change — the model picker renders Host-resolved catalog rows, and the settings storybook story for this provider uses fixed fixtures, so it does not exercise this data).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: pi (coding agent) — verified the official plan facts, implemented the catalog/metadata sync and its tests, drafted the commit and this PR.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above

[jackwener]

I reviewed exact head ca12d1a8aff948789f81e604569acf3da05b4064. No P0 or P1 — one P2 and one P3, neither blocking. Holding the approval only because this is still a draft; flip it to ready and it has mine.

What the change does inside this repo checks out. deprecated is metadata and nothing more: the send gate (llm-connections.ts:353-368) reads enabledModelIds and brokenModelIds and never lifecycle; canUseAsChatDefault (model-catalog.ts:485-491) rejects only a retired provider or a non-chat model; and Agent Plan's fallbackModels is a hand-written array that does not filter on lifecycle. So the description's "no migration impact" is accurate — the three retired ids stay selectable and sendable, and glm-5.3-flash becomes available without touching anyone's defaultModel or enabledModelIds. The three new tests are also genuinely falsifiable: restored against main one at a time, each fails for its own reason.

P2 — "1M" and 1_024_000 are not the same number, and the only record that said 1M is deleted here

packages/core/src/model-metadata.ts:292 changes glm-5.3 from 1_000_000 / 131_072 to 1_024_000 / 128_000, and the comment that stood above it went with it:

Agent Plan currently exposes GLM-5.3 in its ark-code-latest routing catalog. The underlying model's published limits are 1M context and 128K output.

That comment was the repository's own sourced claim, and it said 1M. The replacement says 1024k on the grounds that the plan page lists it that way "like its siblings," without saying why the earlier record was wrong. The same ambiguity runs through the description, which reports minimax-m3 as "now serves a 1M context window" while the code writes 1_024_000. These differ by 24,000 tokens.

The direction matters. context-budget-policy.ts:86 computes maxHistoryEstimatedTokens = contextWindow - reserveTokens with the reserve capped at 16,384, so an overstated window keeps more history and defers compaction — and if the gateway's real ceiling is lower, the request is refused at the provider instead of being compacted earlier. Understating it only wastes budget. Both edits here move in the unsafe direction (glm-5.3 +24,000; minimax-m3 +512,000).

I am not claiming the new numbers are wrong. I am saying the repository can no longer tell: this catalog is a hand-maintained mirror of a page, with no model-list endpoint and no models.dev snapshot, and deleting that comment removed the last citable figure. Please state which of 1,000,000 and 1,024,000 the plan page actually gives, use that literal consistently in the code and the description, and keep a sourced note next to it — a mirror with no provenance cannot be re-verified by the next person who has to update it.

P3 — the glm-5.3 change is the one edit with no assertion behind it

The new block at model-metadata.test.ts:174-201 covers glm-5.3-flash, minimax-m3 and the three lifecycle flags, and never reads glm-5.3. Restoring only that model's two old numbers and leaving every other production edit in place still leaves the new tests 3/3 green. A later merge or rebase can revert either value silently, and contextWindow feeds the history budget described above. Pin contextWindow === 1_024_000 and maxOutputTokens === 128_000 in the same mirror contract.

On what the tests can settle

Restored one at a time against main, the three new cases fail for the right reasons — the missing fallback id, 512000 against an expected 1024000, and active against an expected deprecated. So they are real pins rather than tautologies. But their expected ids, numbers and lifecycles are transcribed from the same external claims the implementation encodes, so passing proves Maka states those claims consistently, not that they are true. The launch dates, window sizes and retirement dates in the description remain unverified here and need upstream evidence; nothing in this review speaks to them.

label and test are green on this head.

简体中文

我审的是 ca12d1a8aff948789f81e604569acf3da05b4064。没有 P0/P1——一条 P2、一条 P3,都不阻塞。我暂不批准仅仅因为它还是 draft;转成 ready 我就批。

这次改动在仓库内部的行为是站得住的。deprecated 只是元数据:发送闸门(llm-connections.ts:353-368)只看 enabledModelIds 和 brokenModelIds,从不看 lifecycle;canUseAsChatDefault(model-catalog.ts:485-491)只否决「供应商已退役」和「不能用于对话」;Agent Plan 的 fallbackModels 是手写数组,不按 lifecycle 过滤。所以描述里「不影响已有连接」属实。三条新测试也确实可证伪:逐条还原到 main 上,各自因各自的原因失败。

P2:「1M」和 1_024_000 不是同一个数,而唯一写着 1M 的那条记录被这次删掉了。

model-metadata.ts:292 把 glm-5.3 从 1_000_000 / 131_072 改成 1_024_000 / 128_000,原本压在它上面的注释也一并删了:

Agent Plan currently exposes GLM-5.3 in its ark-code-latest routing catalog. The underlying model's published limits are 1M context and 128K output.

那条注释是仓库自己留下的、带出处的说法,它写的是 1M。替换后的理由是「plan page 就是这么列的,和兄弟型号一致」,但没有说明先前那条记录为什么是错的。同一处含混也出现在描述里:描述说 minimax-m3「现在是 1M 上下文」,代码写的是 1_024_000。两者差 24,000 个 token。

方向是要紧的。 context-budget-policy.ts:86 算的是 maxHistoryEstimatedTokens = contextWindow − reserveTokens,reserve 封顶 16,384。窗口估大 ⇒ 历史留得更多 ⇒ compact 推迟;如果网关真实上限更低,结果是请求在供应商那边被拒,而不是提前压缩。估小只是浪费额度。这次两处改动都朝不安全的方向走(glm-5.3 +24,000;minimax-m3 +512,000)。

我并不是断言新数字是错的。我是说仓库现在已经无法判断:这份目录是对着一个页面手工维护的镜像,既没有模型列表接口,也没有 models.dev 快照,而删掉那条注释等于删掉了最后一个可引用的数字。请确认 plan page 给的到底是 1,000,000 还是 1,024,000,在代码和描述里用同一个字面值,并在旁边留一条带出处的注释——一份没有出处的镜像,下一个要更新它的人没法复核。

P3:glm-5.3 是唯一一处没有断言兜底的改动。 model-metadata.test.ts:174-201 覆盖了 glm-5.3-flash、minimax-m3 和三个 lifecycle,唯独没读 glm-5.3。只把这个模型的两个旧数字还原、其余生产改动全部保留,三条新测试仍然 3/3 全绿。以后一次 merge 或 rebase 可以静默回退其中任一值,而 contextWindow 会进入上面说的历史预算。建议在同一份 mirror contract 里直接 pin contextWindow === 1_024_000 和 maxOutputTokens === 128_000。

关于这些测试能定什么。 逐条还原到 main 上,三条各自因正确的原因失败——缺少的 fallback id、512000 对 1024000、active 对 deprecated。所以它们是真的钉子,不是空转。但它们的期望 id、数字和 lifecycle 都是从实现所依据的同一批外部主张抄来的,所以通过只能证明 Maka 一致地记录了这些主张,不能证明它们为真。 描述里的上线日期、窗口大小和下线日期在这里都未经验证,需要上游证据;本次评审对它们不作任何背书。

这个 head 上 label 和 test 都是绿的。

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.

[Astro-Han]

Both accepted — 24ab7a8ac on this branch.

P2 (provenance / inconsistent literals) — verified, fixed at the table level. The plan page gives both spellings for the same figure: its table rows read "1024k"/"128k" (7 occurrences), while its prose rounds to "支持 1M 上下文窗口". The mirror now records this once above VOLCENGINE_AGENT_PLAN_MODEL_METADATA, with the source pages (plan overview 82379/2366394, release/retirement announcements 82379/2578669 and 2578673) and the transcription rule: table literal 1024k → 1_024_000. That convention is what every sibling 1M entry already used (glm-5.2, glm-latest, deepseek-v4-flash/pro, kimi-k3); the old glm-5.3 figure (1_000_000/131_072) was the lone outlier, matching models.dev's transcription of the same models (1000000/131072) rather than this page's table. For corroboration, the gateway-tested pi-provider-volcengine-agent-plan catalog also uses 1_024_000. Kept at 1_024_000 — reverting would re-introduce the outlier the mirror suffers from. The PR description's "1M" is reworded to the same literal.

P3 (unpinned glm-5.3) — verified, fixed. pins glm-5.3 to the plan page table literals added to the mirror contract (characterization pin: green against the current head, and it fails if either literal drifts back).

Core suite: 772 pass, 0 fail; format/lint clean.

Marking ready as suggested.

[jackwener]

Approving at exact head 24ab7a8ac62a536e5ae6c9479b09a5451f3448f7. No P0 or P1. Both comments from my earlier review are addressed.

The provenance is back, and better than what was there before. The new note names the plan page and the two release/retirement announcements by document id, says why there is no automatic source — no model-list endpoint the plan key can reach, no models.dev snapshot — and settles the ambiguity directly: the table lists 1024k/128k, those literals are what gets transcribed, and the prose "1M" is the same figure rounded. That is the part I could not resolve from the repository, and it removes the reason a reader would hesitate between 1,000,000 and 1,024,000. "Re-check the page before editing an entry here" is the right instruction to leave next to a hand-maintained mirror.

glm-5.3 now has an assertion. pins glm-5.3 to the plan page table literals fixes both numbers, so the one edit that could previously be reverted by a merge without failing anything is covered.

What this review still does not establish is unchanged and worth restating: the launch dates, window sizes and retirement dates are external facts. The tests pin that Maka transcribes them consistently, not that they are correct — the citation now makes them checkable by a person, which is the most a repository can do here.

label and test are green on this head.

简体中文

在 24ab7a8ac62a536e5ae6c9479b09a5451f3448f7 上批准。没有 P0/P1。上一条评审里的两条意见都已处理。

出处回来了,而且比原先更完整。 新加的注释点名了套餐页面和两份发布/退役公告的文档编号,说明了为什么没有自动来源(套餐密钥够不到模型列表接口,models.dev 也没有快照),并且直接把歧义解决掉了:表格列的是 1024k/128k,照抄的就是这两个字面值,正文里的「1M」是同一个数的四舍五入。 这正是我从仓库里无法判定的那部分,读者不必再在 1,000,000 和 1,024,000 之间犹豫。「编辑此处条目前先重新核对页面」——对一份手工维护的镜像来说,这是该留在旁边的话。

glm-5.3 现在有断言了。 pins glm-5.3 to the plan page table literals 把两个数字都钉住,原先那处唯一可以被合并静默回退而不触发失败的改动,现在被覆盖了。

有一点不变,值得再说一次:上线日期、窗口大小、退役日期都是外部事实。这些测试钉住的是 Maka 一致地转录了它们,不是它们正确——现在有了出处,人可以去核,这已经是仓库能做到的极限。

这个 head 上 label 和 test 都是绿的。

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.