Error: 400 This model's maximum context length is 1048576 tokens. However, you requested 1049647 tokens (985647 in the messages, 64000 in the completion).

Summary

Session becomes permanently unusable after a context 400 error. The client reserves max_tokens=64000 (model max output) without clamping it to the remaining context budget, and auto-compaction does not reduce the context. Any input that lands in the last ~63k tokens of the window fails with 400, and "continue" repeats the error indefinitely (the payload grows on every attempt).

Expected Behavior

When the input approaches the model limit, Command Code should:

1. Adjust the completion budget to whatever is left (max_tokens = context_limit - input_tokens) instead of sending the model's fixed maximum.
2. Actually trigger auto-compaction and reduce tokens (today tokensBefore only grows from one compaction to the next).
3. If it still does not fit, tell the user clearly with a way out (e.g. suggest /compact or /new) instead of resending the same invalid request.

Actual Behavior

Session: e92a0247-1119-410b-a3ce-58423682585b (model deepseek/deepseek-v4.1-flash, 1M context / 64k output).

Every message sent while the input is in the 984,576-1,048,576 token range fails with HTTP 400, because the client adds 64,000 completion tokens on top of the input and exceeds the 1,048,576 limit.

Occurrences in the same session (input + completion = total):

• 987,220 + 64,000 = 1,051,220
• 988,324 + 64,000 = 1,052,324
• 990,434 + 64,000 = 1,054,434
• 985,647 + 64,000 = 1,049,647 (this report)

There was room for the input (985,647 < 1,048,576); what overflowed was the reserved max_tokens. A clamp would have been enough.

Typing "continue" does not help: each attempt appends the error text to the history, so the payload GROWS (987,220 → 988,324 → 990,434 message tokens). The session enters a permanent 400 loop and becomes unusable.

Auto-compaction does not recover it either: there were 14 compactions in the session, and tokensBefore increased monotonically (872,840 → 875,797 → 876,858 → 888,530 → 899,853 → 904,965 → 910,711 → 911,827 → 912,855), with every summary being exactly 3,910 characters long. In other words, compaction keeps re-summarizing the same old prefix without freeing context — the last 4 compactions (00:37, 00:39, 01:12) happened immediately before new attempts that returned 400 again.

Aggravating factor: the session has 5 user messages with large images (548-712 KB each). When the session is resumed, the 548 KB message and its corresponding turn appear duplicated in the history (lines 966 and 980, timestamps 00:35 and 01:12), growing the payload even further.

Steps to reproduce the issue

Prerequisite: a model with 1M context and 64k output (deepseek/deepseek-v4.1-flash).

1. Open a cmd session with that model and fill the context until the input sits in the ~985k to 1,048,576 token range (in my case: a long session with a few large images).
2. Send any message.
   → Error: "This model's maximum context length is 1048576 tokens. However, you requested 1049647 tokens (985647 in the messages, 64000 in the completion)."
3. Type "continue".
   → Same error, now with a larger payload (988,324 message tokens).
4. Repeat step 3.
   → The error persists and grows on every attempt. The session never recovers.

Note: any input in the range between (context_limit - 64000) and context_limit fails deterministically, even though it is a valid input on its own.

Command Code Version

1.58.0

Operating System

Linux

Terminal/IDE

Unknown

Shell

bash

Session file (optional)

I am not attaching the full .jsonl: it is ~8.6 MB and contains 5 base64 images (548-712 KB each) plus paths from my project. I can export it with /export jsonl and send a redacted version, or just the relevant entries (the 4 error entries and the 14 compaction entries) if that is preferred.

Fix prompt (optional)

Fix context budget handling in Command Code.

Likely root cause: when building the request, the client sends max_tokens = the model's output limit (64000) unconditionally, without accounting for how much of the context the input already consumes. When input_tokens + max_tokens > context_limit, the API returns 400 and the session gets stuck.

What to do:

1. Clamp the completion budget to the remaining space: max_tokens = min(model.maxOutput, context_limit - input_tokens). This is why 985647 + 64000 = 1049647 overflows even though 985647 alone fits — it was short by only 1071 tokens.
2. Account for the completion budget in the compaction trigger, so it fires before the input reaches context_limit - maxOutput (today tokensBefore at compaction time reached ~912k and the next request still had ~990k).
3. Investigate why compaction does not reduce context: in session e92a0247, 14 compactions had monotonically increasing tokensBefore (872840 → 912855) and byte-identical summaries (3910 characters), suggesting the summary is generated over the same prefix without dropping what was already compacted.
4. Treat the context 400 as recoverable: do not append the error text back into the history (that makes the payload grow on every "continue") and offer a way out (forced auto-compaction, /compact, or /new) when a request is provably too large.

How to verify: reproduce with an input of ~985k tokens on a 1M/64k model and confirm the request is now sent with max_tokens ≈ 62900 (or that compaction runs) instead of failing with 400.

Likely files: the module that builds the request payload / does token accounting, and the auto-compaction trigger in command-code's dist/.

Additional context

Trace ID: 9de623ea38ece043b4c0122372ceaffd
Session ID: e92a0247-1119-410b-a3ce-58423682585b (Hashiras project)
Model: deepseek/deepseek-v4.1-flash (1M context, 64k output, vision) compactMode: "default"

Evidence of ineffective auto-compaction (tokensBefore per compaction, in order):
872840, 875797, 876858, 888530, 899853, 904965, 910711, 911827, 912855 — all with a 3910-character summary

Last events in the session:

• 00:35 user message with 2 images (548 KB) → work executed → 400 (1051220)
• 00:37 compaction (tokensBefore 910711) → user types "continue" → 400 (1052324)
• 00:39 two compactions → "continue" → 400 (1054434)
• 01:12 compaction (tokensBefore 904965), replay of the same image message → 400 (1049647)

I am also filing this through the 1.bug_report.yml template; the terminal was reported as "Unknown".

Locate the request-payload and token-accounting module and the auto-compaction trigger in command-code's dist/, as suggested by the report. Reproduce near the 1M/64k boundary, then verify that the completion budget is clamped or compaction runs, oversized requests do not loop through appended errors, and the session offers a recovery path.