Custom "anthropic" provider does not enforce provider.max_prompt_tokens — sessions grow past the model context window until a hard 400

Start at the custom anthropic provider session-create/resume path and trace how max_prompt_tokens and infinite_sessions thresholds are handled before requests are sent. Compare that path with the Copilot backend path where compaction works, then reproduce the growing transcript and confirm that prompts stay within the configured budget and failed sessions can recover.

Summary

When a custom provider of type: "anthropic" is configured with max_prompt_tokens, the SDK does not appear to enforce that budget. A long-running session keeps accumulating transcript until the request exceeds the model's context window and the provider rejects it with HTTP 400 -- after which the session is permanently unusable.

Configuration

The provider is created on every session create/resume with an explicit prompt budget:

{
  "type": "anthropic",
  "base_url": "...",
  "model_id": "claude-sonnet-5",
  "max_output_tokens": 32768,
  "max_prompt_tokens": 967232
}

max_prompt_tokens is derived as context_window (1,000,000) - max_output_tokens (32,768) = 967,232.

Expected

The SDK compacts (or otherwise bounds the prompt) before crossing max_prompt_tokens = 967232.

Actual

The transcript grew unbounded to 1,001,142 tokens -- 33,910 past the configured budget, and past the model's 1,000,000 hard limit:

400 invalid_request_error
"prompt is too long: 1001142 tokens > 1000000 maximum"

The session had run ~18 successful turns over ~3 hours, with the serialized request growing steadily (~1.98 MB -> ~2.04 MB) before crossing the limit. Tool count was constant throughout, so the growth is accumulated conversation history rather than tool schemas.

Two additional observations

1. infinite_sessions thresholds also appear inert on this path. background_compaction_threshold / buffer_exhaustion_threshold are sent on every turn but appear to have no effect for the anthropic provider (they do take effect on the Copilot backend path). So neither the threshold-based compaction nor the max_prompt_tokens budget bounded the transcript.

2. The session actively degrades after the first failure. Once over the limit, continued turns keep appending to the transcript -- request size grew from ~2.044 MB to ~2.065 MB across ~30 consecutive failed turns. There is no back-off, trim, or compaction triggered by the 400, so the session can never self-recover; every subsequent turn fails immediately (~1.5s vs. the 38s first failure).

Impact

Every turn in an affected session fails permanently. The only recovery is to start a new session, and nothing in the surfaced error indicates that to the user. Because the failure is a deterministic 400, retry suppression correctly kicks in -- but that just means the session is durably wedged.

Environment

• SDK 1.0.7 / Copilot CLI 1.0.71
• Custom anthropic provider over an OpenAI-incompatible relay endpoint
• Model claude-sonnet-5 (1,000,000-token context window)

Ask

Should provider.max_prompt_tokens be enforced on the anthropic provider path (and/or should infinite_sessions compaction apply there)? If enforcement is intentionally backend-only today, it would help to document that clearly, since the field is accepted without warning and silently has no effect.