Built-in Agent fails on first message: 'The current request is too large for this model context window' (server run ignores AGENT_MODEL_CAPABILITY_OVERRIDES, v0.2.2 regression)

[lmcsh9527]

Bug description

The built-in Agent fails immediately on the first message with:

The current request is too large for this model context window. Remove large attachments or choose a model with a larger context window.

This happens even before any real conversation (system prompt + tool schemas alone blow the budget). It affects any custom model id that is not present in the bundled models.dev catalog — e.g. a gateway model like openai/deepseek-v4-flash-0731.

Root cause

Since v0.2.2, server-side execution is the only Agent run path (agentSettings.serverRun is hard-coded true and the browser-side model loop was removed). However, the server run executor does not apply the user-configured AGENT_MODEL_CAPABILITY_OVERRIDES:

• server/agent-runs/executor.ts → createExecutionPlan() calls resolveModelCapabilities({ backend, provider, modelId }) without the override records parameter.
• The browser-side path (src/agent/model-selection.ts → applyAgentModelStatus) does read AGENT_MODEL_CAPABILITY_OVERRIDES, so this is a regression introduced by the v0.2.2 server-side refactor.
• For a model not in the bundled models-dev.json, resolveModelCapabilities falls back to UNKNOWN_CONTEXT_TOKENS = 8192 (shared/model-capabilities.ts).
• OpenChatCut's own system prompt (~16.5 KB ≈ 4k+ tokens) plus the tool schema JSON (tens of thousands of tokens) already exceed the 8192-token compaction budget, so recentMessageStart() returns 0 and prepareContext() throws the error above — on the very first user message.

Repro

1. Configure any OpenAI-compatible provider with a model id that is absent from assets/model-capabilities/models-dev.json (e.g. deepseek-v4-flash-0731 via a gateway base URL).
2. Add a AGENT_MODEL_CAPABILITY_OVERRIDES entry (e.g. contextWindowTokens: 100000) — the UI even shows the override as active.
3. Open the built-in Agent in any project and send the first message.
4. The run fails instantly with the error above; the run record shows transportStatus: failed with that exact error in ~300 ms (local budget check, not a provider response).

Suggested fix

Pass the keystore-backed overrides into server-side capability resolution. The keystore already parses/normalizes AGENT_MODEL_CAPABILITY_OVERRIDES (server/keystore.ts), the executor just never reads it:

--- a/server/agent-runs/executor.ts
+++ b/server/agent-runs/executor.ts
@@
-import { resolveModelCapabilities } from '../../shared/model-capabilities';
+import {
+  MODEL_CAPABILITY_OVERRIDES_KEY,
+  parseModelCapabilityOverrides,
+  resolveModelCapabilities,
+} from '../../shared/model-capabilities';
+import { getKey } from '../keystore';
@@
   const capabilities = resolveModelCapabilities({
     backend,
     provider,
     modelId: input.model,
-  });
+  }, parseModelCapabilityOverrides(getKey(MODEL_CAPABILITY_OVERRIDES_KEY)));

Verified locally: with the fix, the same model resolves from 8192 (provider-fallback) to 100000/1000000 (settings-override) and the first message goes through.

Impact

Any user of a custom/self-hosted/gateway model whose id is not in the bundled catalog cannot use the built-in Agent at all since v0.2.2 (v0.2.3 still affected). The override UI and .env.local setting are silently ignored on the server path.

[0xsline]

Fixed on main (9f88aae).

• server/agent-runs/executor.ts now resolves capabilities through resolveServerRunCapabilities, which passes parseModelCapabilityOverrides(getKey(MODEL_CAPABILITY_OVERRIDES_KEY)) — the same records the browser model-selection path uses. The suggested diff was applied in that shape, plus a verifier.
• executor.verify.ts covers: override wins over the 8K fallback with source: 'settings-override'; unmatched model ids keep the estimated 8192 fallback; estimated input budget derives from the overridden window; local providers without an override still fall back.
• CI green on the branch (97 verify segments): https://github.com/0xsline/OpenChatCut/actions/runs/31861809492

Thanks for the precise root cause — the local budget check in prepareContext throwing before any provider call was the key detail.