Audit · Example report
A full example report, redacted
This is the whole deliverable, not a preview of it. The transcript below is fictional and the figures are illustrative, but the structure, the level of detail and the tone are exactly what arrives in your inbox.
1. Summary
Across the twenty exchanges you sent, the dominant cost was not the work itself — it was the carried history. Sixteen of the twenty prompts re-sent the same 900-line file, and by the last exchange roughly three quarters of every request was re-reading context you’d already paid to send.
The single highest-leverage change is session hygiene: this was one long thread that should have been four short ones. Doing only that, and nothing else in this report, would have cut the session’s input spend by an estimated 55–65%.
2. Where the tokens went
| Category | Est. tokens | Share | Avoidable? |
|---|---|---|---|
| Re-sent file context | 412,000 | 61% | Mostly |
| Your prompt text | 9,400 | 1% | Partly |
| Claude's replies | 118,000 | 18% | Partly |
| Restated instructions | 74,000 | 11% | Yes |
| Genuinely new context | 58,600 | 9% | No |
The shape here is typical. New information is almost always the smallest slice; the bill is dominated by the same material travelling back and forth.
3. The three habits costing you the most
Habit one — pasting the whole file to change ten lines
Exchanges 3, 5, 6, 9, 11 and 14 each open with the full contents of DashboardPanel.tsx. The requested change was localised every time.
What to do instead: paste the function and its immediate imports, plus one sentence of surrounding structure. Where you genuinely need the file read once, do it once and refer back to it in the same thread rather than re-pasting.
Habit two — the thread that never ends
All twenty exchanges are one conversation spanning three unrelated tasks: a refactor, a test-writing session and a copy edit. Every message in the copy-edit phase still carried the refactor history.
What to do instead: start a new conversation when the task changes. It feels wasteful and it is the opposite — a fresh thread with a two-paragraph summary is far cheaper than a thread that remembers everything.
Habit three — restating the rules every time
Fourteen prompts repeat some version of “use TypeScript, no comments, match our existing style.” The model retained this from the first mention.
What to do instead: put standing rules in project or custom instructions once, then never restate them in-thread.
4. Rewrites
Original (exchange 9, ~4,100 tokens): the full file, followed by “As before, TypeScript only, no comments, match the existing style, and remember this is the dashboard panel we refactored earlier. Can you now add a loading state?”
Rewritten (~180 tokens): “Add a loading state to DashboardPanel — here is the render body only. Return just the changed block.”
Same output, 4% of the input. Eleven of your twenty prompts compress by a similar factor.
5. Before and after
| As sent | With the changes | |
|---|---|---|
| Input tokens | 672,000 | 218,000 |
| Output tokens | 118,000 | 104,000 |
| Sessions | 1 long thread | 4 scoped threads |
| Est. share of a weekly limit | ~38% | ~13% |
6. What not to change
Your prompts are specific and well scoped — that is why the outputs needed so little correction. Do not shorten the instructions themselves; shorten the context you attach to them.