I had a confident mental model of how I use AI coding tools: writing code. Boilerplate, scaffolding, the tedious parts.
I exported a year of session logs and categorized them. That model was wrong.
The actual distribution
- Comprehension: ~50%. What does this module do, how does data flow through it, why was this decision made, what edge cases does this handle.
- Writing new code: ~30%.
- Verification and review: ~10%.
- Miscellany: ~10%. Syntax lookups, format conversions, docs.
Half my usage was reading. I'd spent a year optimizing for the smaller half.
Why this matters operationally
Comprehension isn't just the largest category — it's the most expensive one per unit of value.
Answering "how does auth work here" means reading a lot of files. All of that lands in your context window. And usage is metered on context: every subsequent message in that session now carries the weight of everything the model read to answer that one question.
So the highest-frequency category also inflates the cost of everything that follows it.
The fix, once I knew where to aim
Route comprehension through subagents.
A subagent reads in its own context window and returns a summary. Your main thread receives the answer without the twenty files that produced it.
Use a subagent to investigate how token refresh works in the
auth module, and whether there are existing OAuth utilities
worth reusing. Report findings, don't modify anything.
Same answer. Fraction of the downstream cost.
Targeted at the category that turned out to be half my usage, this single change outperformed every other optimization I'd tried combined — including several I'd been quite pleased with.
Secondary findings
Miscellany was bigger than expected. Ten percent, mostly low-value. Syntax questions and concept lookups now go in throwaway sessions on a light model, closed immediately. They have no business occupying the main thread and inflating everything after them.
Verification was smaller than expected, which bothered me. It's the category I'd defend hardest under pressure, and it wasn't getting proportionate spend. I've deliberately increased it.
Monthly variance was enormous. Busy months ran roughly three times the quiet ones — driven by whether that month happened to contain a migration or a review backlog.
How to do this yourself
Most CLIs keep session history locally. Export it, group by intent, count.
The bucketing is crude and that's fine — you're looking for a rough distribution, not precision. An evening's work.
The reason to bother: you probably can't guess your own distribution. Every efficiency decision you make is aimed at whatever you currently believe it to be. If that belief is wrong, so is the aim, and you won't find out any other way.
The variance problem
That third finding explained something that had bugged me for a year: why my subscription tier always felt wrong.
I'd been choosing based on my busiest month, then paying that rate through months where I barely opened the thing. Utilization across the three months I audited came out around 40%.
Subscription pricing assumes roughly flat consumption. Work arrives in projects, and projects have shapes.
I now run a low baseline tier and cover spikes through Asale — a market where unused subscription capacity gets routed to people who need it, priced per million tokens. The per-request record it produces is incidentally what made the audit possible in the first place.
Disclosure that determines fit: requests relay through another user's client, so the payload is visible at that hop. No end-to-end encryption — stated on their front page, along with a note that sharing subscription capacity may conflict with upstream terms. Personal projects and open source, fine. NDA'd work, no.
If you've done this exercise, I'd be curious what your split looked like. I suspect the reading-heavy pattern is common and under-discussed.
Top comments (0)