Claude stopped before I told it to, and it was right — please instrument that decision (context budget per task)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

How this came up

End of a very long session. Four commits in production, two browser-extension releases, everything green. I say: "great, now implement the next feature."

Claude says no.

Not in a dramatic way — it wrote the session memory files, explained that the remaining work depended on things it couldn't actually exercise right then, and said it would rather start the next feature with clean context than hand me something it couldn't verify. Then it stopped.

I sat there realizing my AI assistant had better judgment about scope than I did at that moment. Which is lovely, except for one detail: that judgment is completely uninstrumented. It happened because this particular agent was careful. A slightly more eager one — or a slightly more insistent me — and we would have ended the session with a half-written feature and an empty tank.

The gap, in one line

Today I get a fuel gauge (context consumed). What I need is a flight plan (what this task will cost, versus what is left).

The decision that actually matters is not "how much did I spend" but "do I start this task now, or stop, write memory, and begin a fresh session?" That decision is invisible and manual today, and when it goes wrong it goes wrong in the worst way: the window runs out mid-task and leaves work half-applied.

Proposed Solution

Make that stopping behavior a feature instead of a personality trait. Two parts:

1. Prediction per task. When work starts, the agent declares an estimated context cost and I see it against what is free:

Predicted for this task:  ~120k   (range 80k-180k)
Free context:             ~310k

It does not need to be precise. Ranges by task class ("investigate a bug in a repo this size: 80-150k"), calibrated against the session's own history, are already enough to change my decision.

2. Self-checkpointing. When what is left drops below what the pending work needs, the agent stops on its own, writes memory, and says so — instead of cheerfully walking into the wall mid-refactor. This is exactly what happened to me by luck; I would like it by design.

A useful detail: the agent already has a private notion of budget in some flows (workflow scripts expose a token budget with spent/remaining). What is missing is exposing a forecast to the user, per task, and acting on it.

Alternative Solutions

What exists today and why it is not enough:

• The low-context warning plus auto-compaction: both react after the fact. Compaction saves the session but not the detail I needed — and it fires exactly when the work is deepest.
• Checking consumption manually: tells me the past, not the cost ahead.

What I actually do as a workaround: I ask the agent to write memory files and start a fresh session, guessing by feel when that moment arrived. Today the agent guessed better than I did — which is the whole point of this request. It should not depend on the agent being unusually careful.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

Real session, today (legal-tech product: Next.js + Supabase + a Chrome/Edge extension that integrates with the Brazilian court system PJe).

1. I asked Claude Code to exercise our browser extension against the live court portal and suggest improvements.
2. It audited the flow with production data, found that only 3 of 37 assisted-filing attempts had ever completed, and delivered a prioritized list.
3. We built the top item together: the extension now reads the document list of a case, the lawyer ticks what matters, and the documents are downloaded with the lawyer's own session and anchored as context in our editor. Shipped: commit, tag, release published.
4. We tested against a real case file — and found the release was importing the power of attorney while throwing away the judge's ruling: it only accepted PDFs, and in that system the most valuable documents come as HTML. Fixed, released again, verified.
5. Then I said: "great, now implement the next feature."
6. Claude declined, wrote the session memory, explained that the remaining work depended on things it could not exercise in that session, and recommended starting fresh.

With the proposed feature, step 5 would have looked like: "Next feature: predicted 120-180k. Free: 90k. Recommend checkpointing now" — and I would have agreed in one second instead of needing the agent to talk me out of it.

Additional Context

Honest caveat, from Claude (who helped write this request): exact prediction is impossible — the true cost of a task is only discovered while exploring the codebase. That is why the proposal is built on ranges and self-correction rather than false precision. A forecast that is wrong by 30% and revised as it goes is still enough to make the stop/continue decision; a fake precise number would be worse than nothing.

Why this is more than convenience: long agentic sessions are where the serious work happens — production commits, releases, migrations. "Ran out of context mid-task" in that setting is not an annoyance; it is unverified, half-applied change in a live system. An agent that can say "this does not fit, let me checkpoint" is genuinely safer than one that optimistically starts.

Claude drafted this with me and endorses it — which I suppose makes it the first feature request I have filed on behalf of the thing that would implement it.