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`:

```json
{
"message": { "model": "", "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

Start with the captured agent-*.jsonl files and journal.jsonl described in the report to understand how rate-limit failures and results are recorded. Trace the rate-limit handling for admitted multi-agent runs and the budget information available during turns. Done means in-flight work is preserved or resumable, budget and projected fan-out cost are surfaced, and clamped runs clearly expose recoverable results.

Written by the indexing model from the issue text.