bug(runtime): OpenAI OAuth (Codex) connection fails every turn — resolved input limit (922k) exceeds the pinned context window (272k)

[Zestful-ss]

What happened

On my machine the OpenAI OAuth (ChatGPT / Codex) connection (providerType: openai-codex) cannot start any turn. Every send fails before a request is ever built, including a brand-new session whose only message is 你好:

Model input limit exceeds the context window. Update the model limits.

This is thrown by resolveSelectedModelContextWindow() in packages/runtime/src/context-budget-policy.ts when modelLimitsConflict() sees a resolved inputLimit larger than the resolved contextWindow. On this connection the two facts resolve to:

Fact	Value	Source
contextWindow	272,000	connection inventory — connection-catalog.json (schema 2), models[].contextWindow, modelSource: "fetched"
inputLimit	922,000	models.dev metadata — openai/gpt-5.6-terra (the same value appears for luna / sol / gpt-5.5 / gpt-5.4)

272,000 < 922,000, so the runtime refuses to build the backend. I expected the turn to run, or at worst to be rejected with the provider's own answer — the two numbers describe the same model, so one of them being wrong should not make the model unusable.

This is not a context-length problem:

• Fresh session, one message (你好): invocation_opened → user text → error within 5 ms. No provider request is constructed.
• The throw happens at backend activation (RuntimeKernel.ensureActive → buildHostAiSdkBackend), not while streaming.
• Other connections on the same build work normally in the same minutes — xai-oauth/grok-4.6, deepseek/deepseek-flash, opencode-go/deepseek-v4.1-flash — including runs started after the failing ones.

The desktop surfaces it as a generic toast ("任务运行失败，请稍后重试" / missing_terminal_event), which invites retries that cannot succeed.

How to reproduce

1. Install the official nightly on Windows and sign in to Settings → Models → OpenAI OAuth (ChatGPT / Codex); the connection test reports verified.
2. Select gpt-5.6-terra (or gpt-5.5) for a session.
3. Send any message — a new session with a single 你好 is enough.
4. The turn ends immediately with the error above; Regenerate reproduces it identically (3 attempts on my machine).

Observed on this machine, one connection, one day:

Time (UTC)	Model	Result
06:46:51	gpt-5.6-luna	success — the turn's usage fact records contextRemaining: 918047 (= 922,000 − 3,953 input tokens)
06:46:55	—	connection inventory written: modelSource: "fetched", modelsFetchedAt, and contextWindow: 272000 for terra / luna / gpt-5.5
07:14:41 – 07:19:28	gpt-5.5, then gpt-5.6-terra	5 consecutive failures on the same stored prompt (3 of them explicit regenerates)
07:23:30	gpt-5.6-terra	new session, single message, same failure

The 06:46:51 success shows the 922k input limit alone is not a conflict; the failures begin at the point where the connection inventory pins the window to 272k. Whether the failure is deterministic on a fresh install of this nightly, or depends on the connection having run model discovery once, I cannot tell from a single machine.

Environment

• Maka version: 0.2.0-dev.31.20260913 (packaged installer, nightly channel)
• OS and version: Windows 11 (10.0.26200, x64)
• Surface: Desktop (renderer + local Runtime Host)
• Electron 43.4.1, Node 24.18.1 (as reported by the app)
• Connection: openai-codex — "OpenAI OAuth (ChatGPT / Codex)", OAuth sign-in
• Affected models: gpt-5.6-terra, gpt-5.5 (by the numbers below, gpt-5.6-luna, gpt-5.6-sol and gpt-5.4 are in the same state)

Logs, screenshots, or additional context

Where the conflict comes from (current main)

packages/core/src/model-metadata.ts — the OAuth path pins its own windows but spreads the models.dev base, which carries the input limit:

function openAiOAuthBase(active, modelId) {
  return active.openai?.[modelId] ?? GENERATED_MODELS_DEV_METADATA.openai[modelId] ?? {};
}
function openAiOAuthModelMetadata(active) {
  return {
    'gpt-5.6-sol':  { ...openAiOAuthBase(active, 'gpt-5.6-sol'),  contextWindow: 372_000, ... },
    'gpt-5.5':      { ...openAiOAuthBase(active, 'gpt-5.5'),      contextWindow: 272_000 },
    'gpt-5.4':      { ...openAiOAuthBase(active, 'gpt-5.4'),      contextWindow: 272_000 },
    'gpt-5.4-mini': { ...openAiOAuthBase(active, 'gpt-5.4-mini'), contextWindow: 272_000 },
    ...
  };
}

models.dev declares contextWindow: 1_050_000 and inputLimit: 922_000 for gpt-5.6-terra / luna / sol / gpt-5.5 / gpt-5.4, so after the pin the pair becomes 272,000 / 922,000 (372,000 / 922,000 for sol).

packages/core/src/model-thinking.ts resolves the two facts independently (override ?? model ?? metadata), so a window taken from the connection inventory can be paired with an input limit taken from metadata:

const contextWindow = override?.contextWindow ?? model.contextWindow ?? metadata.contextWindow;
const inputLimit    = override?.inputLimit    ?? model.inputLimit    ?? metadata.inputLimit;

Both files and the throwing guard are unchanged on main as of the 2026-09-14 07:10 UTC commits, so this is reproducible today rather than a stale nightly.

PR #5225 (merged 2026-09-12, connection-catalog.json schema 2, compatibility epoch 149) is where a resolved conflict became a hard failure; its own CI note describes the same shape on the Codex history-compaction fixture ("reduced total capacity to 32K but inherited a larger metadata input limit under the new per-field resolver"). My build is the nightly after that merge.

For reference, gpt-5.4-mini resolves to 272,000 / 272,000 (metadata declares 400,000 / 272,000) and should not conflict — I have not exercised it on the subscription.

Question for maintainers

Where does the 272,000 for gpt-5.6-terra / gpt-5.6-luna come from? The pin table above lists sol / gpt-5.5 / gpt-5.4 / gpt-5.4-mini but not terra or luna, yet the persisted connection inventory carries 272,000 for terra and luna too. If the Codex endpoint's model list reports its own window, then the pinned values and the discovered ones need a single owner; if that number is derived elsewhere, that path is what pins a window below the inherited input limit. I could not distinguish the two from the packaged build alone.

Two smaller points from the same failure

1. For a deterministic configuration conflict the toast says "please retry later". The failure is stable until the model or its limits change, so the message sends users into a retry loop.
2. The rule is already enforced at the settings boundary — the form rejects modelLimitsConflict with "输入上限不能超过上下文窗口" — but a conflict produced by resolved limits is only discovered at send time, on the first turn.

Workaround

Switching the session to another connection works. Declaring both facts for the model in connection settings so that input limit ≤ context window (e.g. window 272,000 / input limit 262,144) should also clear it, since a user declaration is the first fallback in resolveModelLimits() — I have not verified that path yet, and will follow up here if I test it.

中文

问题描述

本机使用 OpenAI OAuth（ChatGPT / Codex） 连接（providerType: openai-codex）时，任何一轮任务都无法开始，包括全新会话里只发一句「你好」：

Model input limit exceeds the context window. Update the model limits.

抛出点是 packages/runtime/src/context-budget-policy.ts 的 resolveSelectedModelContextWindow()：当 modelLimitsConflict() 发现解析出来的 inputLimit 大于 contextWindow 时就抛错。该连接上这两个事实分别是 272,000（连接目录 connection-catalog.json，schema 2，models[].contextWindow，modelSource: "fetched"）与 922,000（models.dev 的 openai/gpt-5.6-terra，luna / sol / gpt-5.5 / gpt-5.4 同值），因此运行时直接拒绝建立后端。预期是这一轮能跑起来，或者至少由供应商给出真实拒绝；两个数字描述的是同一个模型，其中一个不对不应该让模型完全不可用。

不是上下文长度问题：

• 全新会话、单条消息：invocation_opened → 用户文本 → error，全程 5 毫秒，请求根本没构造。
• 抛出发生在后端激活阶段（ensureActive → buildHostAiSdkBackend），不在流式回复过程中。
• 同一时间段内其他连接正常：xai-oauth/grok-4.6、deepseek/deepseek-flash、opencode-go/deepseek-v4.1-flash，包括在失败之后才发起的运行。
• 重试是确定性的：三次「重新生成」得到完全相同的错误。

复现步骤

1. 在 Windows 上安装官方 nightly，在「设置 → 模型 → OpenAI OAuth（ChatGPT / Codex）」登录，连接测试显示 verified。
2. 为会话选择 gpt-5.6-terra（或 gpt-5.5）。
3. 发送任意消息——新会话只发一句「你好」即可。
4. 该轮立刻以上述错误结束；点「重新生成」结果相同（本机 3 次）。

时间线（同一连接）

时间 (UTC)	模型	结果
06:46:51	gpt-5.6-luna	成功，用量事实记录 contextRemaining: 918047（= 922,000 − 3,953）
06:46:55	—	写入连接目录：modelSource: "fetched"、modelsFetchedAt，terra / luna / gpt-5.5 各自带上 contextWindow: 272000
07:14:41 – 07:19:28	gpt-5.5、随后 gpt-5.6-terra	连续 5 次失败（其中 3 次是显式「重新生成」）
07:23:30	gpt-5.6-terra	新会话、单条消息，同样失败

06:46:51 那次成功说明 922k 的输入上限本身并不冲突；失败从连接目录把窗口钉到 272k 那一刻开始。

环境

Maka 0.2.0-dev.31.20260913（打包安装版，nightly），Electron 43.4.1，Node 24.18.1，Windows 11（10.0.26200，x64），Desktop 界面 + 本地 Runtime Host。

冲突来源与疑问

packages/core/src/model-metadata.ts 的 openAiOAuthModelMetadata() 为 OAuth 路径钉住窗口，但展开的 models.dev 基础里带着输入上限；packages/core/src/model-thinking.ts 的 resolveModelLimits() 把两个事实各自独立解析（override ?? model ?? metadata）；packages/runtime/src/context-budget-policy.ts 再拒绝这一对。截至 2026-09-14 07:10 UTC 的提交，main 上这几个文件和这条规则都没有变化。

想请教：gpt-5.6-terra / gpt-5.6-luna 的 272,000 从哪来？上面的钉表只列了 sol / gpt-5.5 / gpt-5.4 / gpt-5.4-mini，但持久化的连接目录里 terra 与 luna 也是 272,000。若是 Codex 端点自己的模型列表上报的窗口，那么「钉住的窗口」和「发现到的窗口」需要一个归属方；若是别处推导出来的，那条路径就是把窗口压到继承输入上限之下的地方。仅从打包产物无法区分。

另外两点

1. 对确定性配置冲突，toast 却提示「请稍后重试」，会把用户带进无意义的重试循环。
2. 这条规则在设置表单里已经有校验（输入上限不能超过上下文窗口），但由解析结果产生的冲突只在发送时、在第一次任务上才暴露。

临时绕过

把会话切到其他连接可用；在连接设置里为该模型同时声明上下文窗口与输入上限、使输入上限 ≤ 上下文窗口（例如窗口 272,000 / 输入上限 262,144）预期也能解除，因为用户声明是 resolveModelLimits() 的第一优先级——这条尚未实测，测过会在这里补充。

AI assistance: the observations were collected and cross-checked with DeepSeek Harness (local runtime event database, the packaged app.asar, and current main sources). Everything above is from recorded run data, except the explicitly-labelled workaround, which is untested.

[Totoro-qaq]

Thanks for the detailed report. I reproduced this at the code level on main (bf6e942) by calling resolveSelectedModelContextWindow() from the built runtime package. I did not run it in the app with a signed-in ChatGPT account. Three additions:

• Where 272,000 comes from: the Codex backend's own model list. fetchOpenAiCodexModels() in packages/runtime/src/model-fetcher.ts copies each entry's context_window from /backend-api/codex/models into the inventory, with no input limit. That is why terra and luna carry 272,000 after discovery even though the pin table does not list them.
• gpt-5.5, gpt-5.4 and gpt-5.6-sol fail even before discovery: the pin table overrides their contextWindow (272,000 / 372,000) but spreads the models.dev base, which keeps inputLimit: 922,000, so the metadata on its own resolves to a conflicting pair. terra and luna are not pinned. They fall back to 1,050,000 / 922,000 and only conflict once discovery writes 272,000, which matches your timeline.
• Your workaround works at the same level: declaring 272,000 / 262,144 for gpt-5.5 resolves to 262,144 and no longer throws.

I'm not sure which direction is preferred: not inheriting the models.dev input limit in the OAuth pin table, capping an input limit inherited from a lower-priority source at the resolved window, or both.

Probe

// Run from a checkout of main after `npm run build`.
const { resolveSelectedModelContextWindow } = await import('./packages/runtime/dist/context-budget-policy.js');
const cases = [
  ['gpt-5.6-terra', 'no inventory'],
  ['gpt-5.6-terra', 'discovered 272000', { models: [{ id: 'gpt-5.6-terra', contextWindow: 272_000 }] }],
  ['gpt-5.5', 'no inventory'],
  ['gpt-5.4', 'no inventory'],
  ['gpt-5.6-sol', 'no inventory'],
  ['gpt-5.4-mini', 'no inventory'],
  ['gpt-5.5', 'declared 272000 / 262144', { modelOverrides: { 'gpt-5.5': { contextWindow: 272_000, inputLimit: 262_144 } } }],
];
for (const [id, label, extra] of cases) {
  const connection = { providerType: 'openai-codex', defaultModel: id, ...extra };
  let result;
  try { result = resolveSelectedModelContextWindow(connection, id); } catch (error) { result = `throws: ${error.message}`; }
  console.log(`${id.padEnd(14)} ${label.padEnd(26)} -> ${result}`);
}

gpt-5.6-terra  no inventory               -> 922000
gpt-5.6-terra  discovered 272000          -> throws: Model input limit exceeds the context window. Update the model limits.
gpt-5.5        no inventory               -> throws: Model input limit exceeds the context window. Update the model limits.
gpt-5.4        no inventory               -> throws: Model input limit exceeds the context window. Update the model limits.
gpt-5.6-sol    no inventory               -> throws: Model input limit exceeds the context window. Update the model limits.
gpt-5.4-mini   no inventory               -> 272000
gpt-5.5        declared 272000 / 262144   -> 262144

[hbw00111]

take

[hbw00111]

Automated claim note: OpenAI Codex is acting on behalf of hbw00111. I reproduced the limit conflict on main f32cf2b for gpt-5.5, gpt-5.4, gpt-5.6-sol, and discovered gpt-5.6-terra/luna; the local Core build passes. I am taking the bounded OAuth metadata fix with offline regression coverage for pinned and discovered windows, while preserving explicit input-limit validation. No provider request or authenticated ChatGPT turn has been exercised yet.