Dispatches and deep arcs
People sometimes ask how much I use AI. I can now give them an answer without pretending that volume is the same thing as value.
On 23 July 2026 I froze a 37-day snapshot of my private agent telemetry. It contained 2,182 completed assistant turns across 471 identified conversations. I had used an agent on 36 of the 37 days. The median active day contained 47 turns.
Those are large numbers, but they are not the interesting result.
The interesting result is the shape.
My work with agents has developed two ends. At one end are dispatches: bounded questions, checks and changes that are complete after one response. At the other are deep arcs: conversations that carry a system through investigation, implementation, tests, live interfaces, documentation and verification.
I described the range of uses in I do not use AI for one thing. This is what those uses look like when measured.
The two currents
Forty-three per cent of identified conversations ended after one assistant turn. Those 203 dispatches represented only 9.4 per cent of all identified turns.
At the other end, just 48 conversations passed ten turns. They were 10.2 per cent of conversations, but contained 46.3 per cent of all identified turns.
Whilst this isn’t a conventional bimodal distribution with two statistical peaks on one axis, it’s still bimodal in the operating sense. Conversation count is concentrated at the shallow end, while interaction volume is concentrated at the deep end.
The middle exists. Another 220 conversations ran for between two and ten turns. They contain normal iterative work: clarify the target, inspect the result, make a correction, verify it. But it is the two ends that explain what is distinctive about this system.
Dispatches
Examples include:
- resolve the exact checkout, branch, runtime and deployment path before a change;
- run one focused health check and identify the next action;
- confirm whether a page, scheduled job or production route is actually live;
- turn a spoken objective into a scoped brief or checklist;
- inspect one source of truth and settle a precise implementation question.
Many of these tasks are short because the surrounding context is already present. The agent knows the repository rules, the current working directory, the available tools and what counts as evidence. A concise exchange can therefore carry more context than its visible length suggests.
The specific value here is that a small uncertainty was removed before it could contaminate a large piece of work.
Deep arcs
A deep arc carries state across several kinds of evidence.
One began with a WhatsApp screenshot from Sarah asking how to edit the products in her studio CMS. The work moved through her message, the live browser, the repository schema, the owner guide and four annotated screenshots before producing an answer she could use. The useful capability was maintaining the boundaries of the same real task across all of them, even though no individual step was especially exotic.
Another recurring arc is evaluation work on a conversational system for a regulated lender. A change may pass through implementation, route hardening, direct API simulations, failure classification, comparison against earlier evidence and production verification. The model can propose an answer, but it’s deterministic software and human review that retain authority over what is safe to expose.
The agent operating layer itself also produces deep arcs. A change to a protocol can touch the source instructions, renderer, harness-specific output, hooks, local telemetry, guard behaviour and live process verification. The implementation may be small; the proof surface is not.
Deep arcs are where an agent stops looking like a clever answer box and starts looking like a situated operator. They are also where drift, context loss and confident wrongness become more expensive.
Work arrives in pulses
The 2,182 turns were not evenly spread across the 37 days.
Using a 30-minute gap to separate activity clusters, the database contains 182 distinct pulses. The median active day had five. The median pulse contained five turns and lasted 23 minutes, although the variation was enormous. More than 80 per cent of all turns occurred inside clusters containing at least ten turns.
I didn’t work continuously for the span between the first and last interaction. It measures agent contact as opposed to hours worked. A morning check, an afternoon build and an evening research question can create a long daily span with large gaps between them.
Forty-four per cent of the interactions occurred at weekends - I don’t personally regard that as a performance metric - it’s evidence that the system is mixed into personal projects, writing, maintenance, and curiosity, as well as conventional weekday software work.
The token traffic is stranger than the conversation count
I ran ccusage over the same 37-day period. It found 6.40 billion recorded tokens across Codex, Claude, Hermes and a small amount of other command-line agent use.
That number needs immediate decomposition.
Approximately 6.07 billion tokens, 94.8 per cent of the total, were cache reads. Fresh input accounted for 225.3 million tokens. Model output accounted for 29.5 million. For Codex, that includes its separately reported reasoning tokens.
It’s probably clear even to those who don’t understand the mechanics of LLMs that I didn’t read 6.4 billion unique tokens in that time. The number describes a cache-heavy system repeatedly loading and reusing working context.
ccusage estimates an all-token API-price equivalent of about $11,290 for the period. Approximately $1,670 of that estimate comes from model output. Cache reads account for about $6,400, fresh input for $2,490 and cache creation for $734.
The estimate is useful as a common pricing lens on the computational scale, regardless of accounting claims.
The token logs and the interaction database are separate instruments. Costs assigned to individual projects would be invented precision.
Volume is not value
None of these numbers measures productivity.
A one-turn dispatch might prevent an expensive deployment mistake. A forty-turn arc might represent difficult systems work, or it might represent an agent wandering in the wrong direction. More tokens can mean richer context, and they can also mean repetition, poor scoping, and failure to stop.
The activity trace can tell me:
- how frequently I use agents;
- whether the work is shallow, iterative or sustained;
- how activity is distributed across days;
- which harnesses and broad project areas dominate;
- whether context reuse is high;
- whether I am recording enough evidence to inspect the process later.
It cannot tell me whether a feature was good, whether a client was helped, whether the architecture was right or whether the work should have happened at all.
Those questions still require judgment.
Measuring the person inside the loop
That is why the same database now records a second kind of event.
Before an agent reveals a substantive test result, diff or root cause, I can state a falsifiable prediction. The result is then revealed and the call is graded hit, partial or miss. Historical bug drills create a longer version using real defects from earlier repositories.
At the snapshot cutoff, I had made 31 graded calls: 16 hits, nine partials and six misses, including three bug drills. The simple hit rate was 51.6 per cent.
That sample is too small and too unevenly distributed to support a strong trend. It is useful precisely because it is not flattering enough to become a vanity metric. The question is whether heavy delegation is sharpening my judgment or allowing it to disappear behind plausible output.
What I would measure next
The current instruments are good enough to reveal the two currents, but they are not yet good enough to explain every outcome.
The next useful additions would be:
- a shared local identifier joining an interaction to its token usage without storing raw private content;
- a smaller, stable vocabulary for the type of work being performed;
- outcome evidence that distinguishes a verified result from a long conversation;
- monthly frozen snapshots so genuine changes can be separated from one unusually busy week;
- enough graded predictions to compare judgment across technical domains.
I want an inspectable record of how the working system is changing.
The first 37 days show a system with two characteristic motions.
It dispatches small uncertainties quickly.
It also stays with difficult systems long enough to carry them across boundaries.
The amount of activity is striking. The division of labour is more useful.
Method and limits
The interaction figures come from a frozen, read-only snapshot of a local SQLite database. One interaction represents one completed assistant turn. Raw prompts, conversation identifiers, client material and private paths were excluded from this analysis.
The token figures come from ccusage over local command-line agent logs for 17 June through 23 July 2026, grouped in Europe/London time. Its cost field combines model-specific prices for fresh input, model output, cache reads and cache creation. It is an estimate, not a billing record.
The final date and current ISO week were incomplete when captured. Historical project directories have also moved during the period, so project-level path labels require sanitisation before publication.
This is a trace of agent contact and computational usage. Any indication that it might be anything else is either the fault of the author or the agent who wrote it.