[Bug]: Cursor 1M and 500K context tiers are ignored or rejected because the SDK request never sets Max Mode

[nkoynov]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Cursor provider with an API key:

1. Pick Cursor → Grok 4.7 and keep the default Context: 500K. Send Reply with exactly: pong.
2. Pick Cursor → Claude Opus 5.5 and keep the default Context: 1M. Ask the agent to read about 450K tokens of files in full (for example six ~300 KB text files, one per read, no grep).

Expected behavior

Each thread gets the context window it shows, the same as Cursor's own CLI with the same selection (cursor-agent --model 'claude-opus-5-5[context=1m,effort=high,fast=true]', which reports "Claude Opus 5.5 1M High Fast" and a 1,000,000-token window).

Actual behavior

• Grok 4.7 at 500K: every turn fails with "Provider turn failed.". The SDK run error is AI Model Not Found Invalid parameters for registry model: "grok-4.7". The same thread at 256K works.
• Opus 5.5 (and GPT-5.6 Sol, and every other model whose default context is 1M) quietly runs on the standard window. Cursor's conversation checkpoint records a 300,000-token limit for Opus (272,000 for GPT-5.6 Sol), and the agent auto-compacts once the context passes it. With the same files, Cursor's CLI, Claude Code and OpenCode's Cursor plugin keep everything verbatim; the CLI reaches 852K of 1M.

Cause: Cursor serves the long-context tiers (1M, Grok's 500K) only in Max Mode, a flag on the request's RequestedModel. Cursor's CLI sets it when the chosen variant needs it, and so does the OpenCode Cursor plugin. @cursor/sdk never sets it: its local runtime builds the request as { modelId, parameters }, and its public ModelSelection ({ id, params }) has no field for it. Neither 1.0.31 (bundled) nor the latest 1.0.35 does, and adding maxMode, max_mode or max as a parameter changes nothing. Forcing maxMode on the SDK's request object in-process turns the same Opus run into a 1,000,000-token window, so the flag is all that's missing.

Cursor's own catalog makes the long tier the default variant for almost every model, so most Cursor threads in T3 are affected unless the user picks the short window.

Impact

Major degradation or frequent failure

Version or commit

nightly 0.0.46-nightly.20261004.2648; main @ efecd3c. @cursor/sdk 1.0.31 (also checked 1.0.35).

Environment

Linux (NixOS), T3 server headless; Cursor provider with CURSOR_API_KEY. Compared against Cursor CLI 2026.10.01-e373342.

Logs or stack traces

# SDK run, grok-4.7 with context=500k
{"status":"error","error":{"message":"AI Model Not Found Invalid parameters for registry model: \"grok-4.7\""},"model":{"id":"grok-4.7","params":[{"id":"context","value":"500k"},{"id":"reasoning_effort","value":"high"},{"id":"fast","value":"true"}]}}

# Cursor conversation checkpoint (tokens used, limit), claude-opus-5-5 with context=1m
@cursor/sdk run:  (391206, 300000) after compaction notices
Cursor CLI run:   (852564, 1000000)

Workaround

Use the short context tier (Opus 300K, Grok 256K), or run Cursor's CLI with the bracket model id for long-context work.

[nkoynov]

More detail on the cause, plus a fix direction verified against a real Cursor key.

What's missing: agent.v1.RequestedModel has a max_mode field (field 2) next to model_id and parameters. @cursor/sdk 1.0.31 and 1.0.35 build it from ModelSelection as { modelId, parameters } only. ModelSelection, ModelVariant and Cursor.models.list() expose nothing about max mode either, so T3 can't learn from the catalog which variants need it. Cursor's CLI decides it from its own catalog (variant.isMaxMode / supportsNonMaxMode) and sets the flag itself.

Which tiers need it: in the current SDK catalog, every model with a context parameter has a standard tier of 300K or less (200K, 256K, 272K, 300K) and a long tier above it (Grok 4.7's 500K, 1M for the rest). The long tier is the catalog's default variant for nearly every model.

A T3-side fix that touches no SDK files: the SDK loads @bufbuild/protobuf from disk as an external dependency and builds every message through proto3.util.initPartial. Hooking that one function for agent.v1.RequestedModel is enough:

const sdkRequire = NodeModule.createRequire(import.meta.url);
const protobuf = NodeModule.createRequire(sdkRequire.resolve("@cursor/sdk"))("@bufbuild/protobuf");
const initPartial = protobuf.proto3.util.initPartial;
protobuf.proto3.util.initPartial = function (source, target) {
  initPartial.call(this, source, target);
  if (target?.getType?.().typeName !== "agent.v1.RequestedModel" || target.maxMode) return;
  const tier = /^(\d+(?:\.\d+)?)([km])$/i.exec(target.parameters?.find((p) => p.id === "context")?.value ?? "");
  // Cursor serves each model's standard window (<= 300K) without Max Mode; larger tiers are Max Mode variants.
  if (tier && Number(tier[1]) * (tier[2].toLowerCase() === "m" ? 1e6 : 1e3) > 300_000) target.maxMode = true;
};

With this hook loaded and the SDK unchanged, results checked against Cursor's conversation checkpoint:

selection	before	with the hook
claude-opus-5-5, context=1m	300,000-token window	1,000,000-token window
claude-opus-5-5, context=300k	300,000	300,000 (no Max Mode)
grok-4.7, context=500k	run fails: "Invalid parameters for registry model"	answers normally

The cleaner fix is in the SDK: let ModelSelection carry maxMode, or set it from the selected variant the way the CLI does. Cursor's GitHub repo has issues disabled, so that report has to go through their forum.

Max Mode is billed per token on usage-based plans. The hook only sets it when the user picks a long-context tier, which matches what Cursor's CLI and IDE do for the same choice.

[tiagotheoliveira]

The problem is real, and annoying.

[lhagenmayer]

Independent reproduction on 2026-10-08 with the official macOS Nightly 0.0.46-nightly.20261008.2813 and its bundled @cursor/sdk 1.0.35. Neither the SDK nor the application bundle was modified.

Tested through T3's native Cursor provider in a separate projectless diagnostic thread, using a minimal reply-only prompt that explicitly prohibited tool use and file access. Provider, account, model, effort and Fast settings stayed the same; only the context tier changed.

Model	Context parameter	Reasoning effort	Fast	Native SDK result
grok-4.7	500k	xhigh	true	status: error, AI Model Not Found Invalid parameters for registry model: "grok-4.7"
grok-4.7	256k	xhigh	true	status: finished; the expected test marker was returned

T3 displayed only the generic “Provider turn failed.” for the 500K run. The error above came from the native SDK's run.completed result. Source inspection of the installed SDK also shows the send path constructing RequestedModel with modelId and parameters, without setting maxMode, consistent with the cause described here.

This confirms that the reported failure is still reproducible in this newer Nightly with SDK 1.0.35 on macOS. It does not validate the proposed hook in #15884: that change was not applied or tested. The 256K control verifies request acceptance and a completed response, not the full effective context limit or compaction behavior.

Only synthetic diagnostic prompts were used. No account identifiers, credentials, local paths, conversation identifiers, original conversation content or raw logs are included in this report.