RetrySight “Tokens used this month: 4.2M” is a number, not an answer. It tells you nothing about whether those tokens shipped working code or burned in a loop nobody noticed. RetrySight’s collectors classify agent activity into specific signal classes instead of one undifferentiated total — the same taxonomy that drives the Product dashboard and the fleet cost views.
The classes
- Edit loops — the agent revises the same file repeatedly without forward progress. Common when a fix keeps addressing the symptom, not the error.
- Compaction events — the context window resets and prior conversation gets re-ingested. Necessary for long sessions, but each compaction has a real token cost that a simple usage counter hides inside “normal” activity.
- Test failures — an automated test run fails and triggers another attempt. Useful signal on its own; expensive in aggregate when a flaky test or a misunderstood spec causes repeated cycles.
- Diff rejected / diff accepted — whether a proposed change survived review, either by a human or a linter/CI gate. Rejected diffs are the clearest signal of wasted generation.
- Subagent loops — delegated sub-tasks that spin without completing, common in multi-step or planner/executor agent architectures.
- Session boundaries — where one logical task ends and another begins, so retries get attributed to the work they actually belong to instead of one long undifferentiated stream.
None of these show up as a line item in a standard token-usage export. They only become visible once someone classifies why tokens were spent, not just how many.
Why the split matters
A fleet burning tokens on compaction because sessions run too long needs a different fix than a fleet burning tokens on rejected diffs because prompts are underspecified. Collapsing both into “tokens used” makes them indistinguishable — and makes the fix a guess instead of a diagnosis.
Retry rate (retry events ÷ completed tasks) becomes a more actionable metric than raw spend once it’s broken out by class, tool, and team. See The hidden cost of coding agent retries for the FinOps framing.
How it’s collected
RetrySight’s collectors tail local IDE agent logs on each developer machine — there is no SDK to add to your application code and no prompt interception required to get this signal. The same taxonomy applies whether you’re running Lite on one machine or a fleet on Cloud or Enterprise.
Go deeper
The full field reference lives in the docs: Retry taxonomy. To see it against your own sessions, download RetrySight Lite — retry classification runs the same way locally as it does across a fleet.