[FEATURE] A way to offset/credit tokens spent fixing Claude's own introduced bugs

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

Summary
When Claude Code introduces a bug or makes a mistake mid-session, the tokens spent diagnosing and fixing that mistake are billed the same as any other work — there's currently no mechanism to distinguish "the user's task grew in scope" from "Claude broke something and now has to un-break it." Since Anthropic's revenue scales with token consumption, this creates a structural incentive misalignment: nothing in the pricing model actively rewards Claude for getting things right the first time, and a user has no way to flag "this round of work was pure rework caused by an error, not new value.

Proposed Solution

Some way — even a coarse one — to reclaim or credit tokens spent on a correction cycle that Claude itself caused. Possible shapes (not prescriptive, just starting points):

A "flag this exchange as a Claude-caused correction" affordance, reviewed either automatically or in aggregate, that credits token usage back.
Session-level reporting that separates "new work" token spend from "rework" token spend, so at minimum a user can see the split even if there's no credit attached.
Some existing internal telemetry (if any) that already distinguishes these categories being surfaced to users in some form.

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

Trust. A user working through a long, high-stakes session (real money, real infrastructure) is going to notice this asymmetry eventually, and "the tool that broke it gets paid the same either way" is a bad look even when unintentional. Making the incentive structure visibly aligned with getting it right the first time would be a meaningful trust signal, independent of whether any individual session actually has many mistakes to correct for.

Additional Context

Came up organically during a long working session (multi-hour, real production codebase, live database migrations, etc.) — not a complaint about a specific incident, more a "huh, this asymmetry exists" observation. The point isn't that Claude was making mistakes to run up a bill; it's that the system has no lever to correct for it even in principle, which is worth naming regardless of intent.