Rate limits hard-kill in-flight agent runs, and the model has no budget visibility to avoid it

Summary

Rate limiting terminates in-flight multi-agent workflow runs, destroying all work that hasn't yet been returned. Because the model has no visibility into remaining allowance or projected burn, it cannot scale its own plan to fit the budget — so a single command can consume an entire weekly allocation and deliver nothing.

These are three connected problems. The third one makes recursive/iterative workflows systematically lossy.

Evidence

Max plan. A multi-agent workflow run (wf_52f23fbf-1ea, 4 agents) was killed mid-flight. Final record in each agent-*.jsonl:

{
  "message": { "model": "<synthetic>", "content": [{ "type": "text",
      "text": "You've hit your session limit · resets 2am (America/New_York)" }] },
  "error": "rate_limit",
  "isApiErrorMessage": true,
  "quotaLimits": {
    "status": "rejected",
    "rateLimitType": "five_hour",
    "overageStatus": "rejected",
    "overageDisabledReason": "out_of_credits"
  }
}

All four agents died at the same instant, deep into real work:

agent  lines=162  real_assistant_turns=73  1.1MB  err=rate_limit  limit=five_hour
agent  lines=140  real_assistant_turns=61  0.7MB  err=rate_limit  limit=five_hour
agent  lines=185  real_assistant_turns=79  0.8MB  err=rate_limit  limit=five_hour
agent  lines=128  real_assistant_turns=55  0.7MB  err=rate_limit  limit=five_hour

3.3 MB of transcript, 268 assistant turns, and the run's journal.jsonl contains zero result entries — every agent was killed before it wrote its conclusions. Recoverable prose from the wreckage: roughly 1 KB. The tokens were spent; the value was not produced.

Two further runs the same weekend failed identically. An earlier 24-agent run did complete all its agents (24/24 results in journal.jsonl) but was clamped before synthesis rendered, so it presented to the user as a total loss — ~380 KB of finished analysis sat undiscovered on disk for four days.

Problem 1 — an initiated run should not be killed by throttling

Once a run is admitted, it should be allowed to drain, or be suspended and resumed, rather than hard-terminated. The current behavior charges full price for the compute and delivers nothing, because in an agentic run essentially all value materializes in the final return. A kill at 95% yields zero.

Minimum viable fix: on limit exhaustion, force in-flight agents to flush whatever they have to the journal before terminating. Even a partial, explicitly-marked-incomplete result is enormously more useful than a synthetic "you hit your limit" string recorded as the agent's output.

Problem 2 — the model cannot see the budget, so it cannot manage it

The model has no access to:

• current session (5-hour) allowance remaining
• weekly allowance remaining
• burn rate of the run it is about to initiate

This is the root cause. A model that could see "you have 180k tokens left this session" would plan a 6-agent sweep instead of a 24-agent one, or decline to fan out at all and say so. Instead it plans as if resources were unbounded, and the user discovers the cost only in the post-mortem.

Requested:

1. Expose remaining session and weekly allowance to the model as context, refreshed per turn.
2. Show the user a projected cost before a fan-out commits, with a confirm step past a threshold.
3. Let the model degrade gracefully — narrow scope, drop verification rounds, lower per-agent effort — instead of planning big and dying.

The existing +500k-style budget directive is a hard ceiling, but the user has to know to use it and has to guess the right number with no visibility into what remains.

Problem 3 — this degrades recursive workflows specifically and systematically

This is the part that compounds. Iterative and recursive patterns — loop-until-dry, refine-until-aligned, propose/verify/amend — accumulate value across rounds and commit it at the end of each round. A rate limit that fires at an arbitrary moment will, with high probability, land inside the last round in progress. That round is lost.

So the smaller the allowance relative to the work, the larger the fraction of rounds that get truncated. At tight enough limits, a recursive process can lose its final round every single time it runs — meaning it never converges, and the user pays repeatedly for work that is discarded at the moment it was about to pay off. Recursion is exactly the pattern these tools are being promoted for, and it is the pattern the limiter damages most.

Asks, in priority order

1. Never hard-kill an admitted run; flush or suspend instead.
2. Give the model its own budget telemetry so it can right-size work up front.
3. Preflight cost estimate with confirmation for large fan-outs.
4. Surface recovery: when a run is clamped, tell the user their agent results are in journal.jsonl rather than letting it read as a total loss.

Environment

• Claude Code, desktop app (Windows)
• Max plan
• Multi-agent workflow runs, 4–24 agents