Same cause, and for Claude and GPT it fails silently: on the local SDK path their 1M variants don’t error like Grok’s 500K, they run at the standard window (300K for Claude Opus 5.5, 272K for GPT-5.6 Sol) and get auto-compacted there. In today’s Cursor.models.list(), 17 of the 19 models whose default variant sets context default to 1M (500K for Grok 4.7), so the default selection hits this.
Repro (@cursor/sdk 1.0.35; the code is unchanged in 1.0.36), Node 24, Linux:
import { Agent, Cursor } from "@cursor/sdk";
const apiKey = process.env.CURSOR_API_KEY;
const models = await Cursor.models.list({ apiKey });
for (const [id, context] of [["claude-opus-5-5", "1m"], ["claude-opus-5-5", "300k"], ["gpt-5.6-sol", "1m"], ["grok-4.7", "500k"]]) {
const base = models.find((m) => m.id === id).variants.find((v) => v.isDefault).params;
const model = { id, params: base.map((p) => (p.id === "context" ? { ...p, value: context } : p)) };
const agent = await Agent.create({ apiKey, model, local: { cwd: process.cwd() } });
const result = await (await agent.send("Reply with the single word pong.", { model })).wait();
console.log(id, context, result.status, result.requestId);
agent.close();
}
| Selection |
Request ID |
Result |
Context limit in the conversation checkpoint |
| claude-opus-5-5, context=1m |
c973fce7-a2af-424c-9fa4-647cb9447cda |
finished |
300,000 |
| claude-opus-5-5, context=300k |
8a3b073a-a76a-479c-8ee0-25afd6be055d |
finished |
300,000 |
| gpt-5.6-sol, context=1m |
bd322cb2-2307-43e3-b1eb-0f83f5481f06 |
finished |
272,000 |
| grok-4.7, context=500k |
af7df776-9da4-4b54-8328-4159e16c7037 |
error: Invalid parameters for registry model |
– |
CLI 2026.10.01-e373342, --model 'claude-opus-5-5[context=1m,effort=medium,fast=false]' |
a19c4dd8-fde0-46b7-a004-b826fa07c0bf |
finished |
1,000,000 |
Privacy mode was on for these requests.
It isn’t only the number: in a reading test of about 470K tokens, SDK runs with context=1m were compacted and lost the raw text of the earlier files, while the same test through the CLI reached 852K of 1M with nothing dropped.
Where it comes from: the local runtime builds agent.v1.RequestedModel as {modelId:t.model.id,parameters:(t.model.params??[]).map(…)} (dist/cjs/867.js in 1.0.36, 689.js in 1.0.35) and never sets max_mode. ModelSelection has no field for it, passing maxMode, max_mode or max as a param changes nothing, and models.list() variants don’t say which ones need Max Mode. Setting max_mode: true on that one object in-process was enough in our tests: the Opus run got 1,000,000 and Grok 4.7 ran at 500K. We now run a preload that adds maxMode there whenever the context param is <N>m.
What would fix it, in order of preference:
- The local runtime sets
max_mode from the selected variant, as the CLI has done since Selecting Opus5 1m context through CLI args isn't possible.
- Or
ModelSelection gets a maxMode field and models.list() marks the variants that need it.
- Until then,
models.list() doesn’t default to variants the local runtime can’t run.
It also affects tools built on the SDK: T3 Code’s Cursor provider offers 1M by default, but every thread runs at the standard window and Grok 4.7 fails at its default ([Bug]: Cursor 1M and 500K context tiers are ignored or rejected because the SDK request never sets Max Mode · Issue #15788 · pingdotgg/t3code · GitHub).