In seven days, Codex processed 65 billion tokens for me. That does not mean it produced 65 billion tokens’ worth of value, but it does say something about the way agents are changing both the duration and the intensity of work.
A few weeks ago, I installed Who Burned More, a small open-source tool that reads the local logs left behind by Codex, Claude Code, Gemini CLI and other coding agents, calculates the number of tokens used, and estimates their cost based on the public pricing of the different models. The project was created mainly as a leaderboard, allowing developers to compare their usage with that of others, but in my case it ended up showing me something I had not really been looking for. (whoburnedmore.com)
When I checked the data on August 12, 2026, Codex had processed around 65 billion tokens for me over the previous seven days, with an estimated equivalent cost of almost US$45,000.
Of course, I did not actually pay anything close to that amount. I use Codex through a subscription, and the figure shown by Who Burned More is an estimate of what the same volume of traffic would have cost if public model pricing had been applied. The calculation distinguishes between input, output, cache write and cache read, because each category is priced differently; OpenAI also notes that actual usage costs depend on the model being used and on the proportion of incoming tokens, cached tokens and generated output.
So the monetary figure is not a bill. It is still useful, however, because it gives some sense of the sheer amount of computation that has accumulated around my work.
Sixty-five billion tokens in a week means more than nine billion per day. As a very rough rule of thumb for English, OpenAI uses a ratio of about three quarters of a word per token; applied mechanically, that would translate into nearly 49 billion words. This comparison is purely illustrative, because Codex logs include code, system instructions, repeatedly loaded context, cached files, outputs and other information that cannot simply be converted into pages read or written. But it does help give some scale to a number that would otherwise remain completely abstract.
The comparison with other Who Burned More users is also interesting, as long as it is not mistaken for a scientific benchmark. Its public index currently contains around 2.03 trillion tokens from 216 developers, with a cumulative average of 9.39 billion per participant. My most recent week alone therefore amounts to almost seven times that average, although every user has a different history and we do not know how long they had been using these tools before appearing on the leaderboard.
That number does not prove that I produced seven times more value than another developer. It does not prove that I worked seven times better either.
What it does show is how much automated work was being continuously launched, monitored, corrected and restarted around a single person.
And that is exactly the point.
The moment when I should have stopped
Since I started using Codex and Claude Code regularly, I have realised that the most obvious change is not only what I am able to build, but also the point at which I stop working.
Before coding agents, there was a certain amount of natural friction involved in starting something new. If an idea for a change occurred to me at eleven at night, I knew I would have to reopen the project, reconstruct the context, write the code, run the tests and probably spend at least another hour on the problem. Most of the time, I would make a note of it and leave it until the next day.
Today, all I have to do is describe the change to Codex and press Enter. The heaviest part of the work appears to have been handed over to the machine, so I no longer feel as though I am starting a new work session. I tell myself I only need to let it run and see how it turns out.
The problem is that seeing how it turns out is still work.
Codex completes the change, but a test fails. I ask it to analyse the failure. It finds the problem, fixes it, and at that point I want to check another case as well. In the meantime, I notice a section of code that could be improved, so I start another run, perhaps while assigning a second task to another agent at the same time.
Each individual step feels too small to justify closing the computer. But when I finally look at the clock, another hour has passed.
The 65 billion tokens do not directly measure the amount of time I spent in front of the screen, because several agents can work in parallel and much of that processing happens without my intervention. What they do make visible, however, is the continuity of the process: to generate that level of activity, I kept opening tasks, checking results, correcting direction and launching the next step across days that no longer had particularly clear boundaries.
AI did not simply help me do the same work faster.
It made it possible for me to keep working even when I would no longer have had the energy to do the work directly myself.
Productivity fills all the available time
When we talk about the benefits of artificial intelligence, we tend to imagine a task of fixed size. It used to take four hours, now it takes two, so we have saved two hours.
In software development, however, those two hours rarely remain empty. They are used to add a feature, try an alternative, improve the interface, fix an issue that was still open, or start something that until the day before seemed too demanding.
AI does not necessarily produce free time. It produces additional capacity, and that capacity is almost always reinvested.
In 2025, METR published a controlled study in which sixteen experienced open-source developers worked on 246 real tasks inside repositories they knew well. Before the experiment, they predicted that AI would make them 24% faster and, even after completing the work, they still believed they had saved around 20% of their time. The measurements instead showed that, under the specific conditions of the study and with the tools available in early 2025, they took an average of 19% longer.
This does not prove that today’s tools slow developers down. Models have improved, the study involved mature codebases and the sample was limited. What it does show is how large the gap can be between the feeling of moving quickly and the amount of time actually being used.
In February 2026, METR tried to repeat the experiment with more recent tools, but ran into an even more interesting problem. Many developers did not want to participate if there was a chance they would have to complete some tasks without AI, while others were using multiple agents at the same time or switching to another task while an agent was running. At that point, it became difficult even to attribute time to a single task.
The old model assumed one person, one task and one stopwatch. Today I can assign one change to Codex, a second to Claude Code, and meanwhile review the result of a third run. I can spend five minutes preparing a request, let the agent work for half an hour, then spend another ten minutes reviewing the output.
How long did I work: fifteen minutes or forty-five?
And how do we measure the time during which I am apparently doing something else, but still checking the window, waiting for a notification, or keeping in mind the problem I will need to verify as soon as the agent finishes?
Telemetry can measure the activity of the machine. It is much harder to measure the mental space that machine continues to occupy.
Seeing how it turns out
What makes it difficult to stop working is not only the increase in productive capacity. There is also the curiosity generated by an outcome that feels close, but remains uncertain.
When I launch Codex, I do not know exactly what I am going to get. It might solve the problem, find an error I had not considered, modify the wrong part, or get close enough to the solution to make me think that one more small adjustment will be enough.
Whatever the result, there is almost always a reason to launch another run.
You could describe this feeling as a small dopamine hit, although it would be inaccurate to claim that anyone has directly measured a developer’s brain response while waiting for a Codex session to finish. We do know, however, that dopaminergic signals are involved in reward anticipation and also respond to the probability and uncertainty of an outcome. It is therefore plausible that the sequence of waiting, uncertain outcome, small satisfaction and another attempt contributes to making the cycle difficult to interrupt, but that remains an inference rather than a conclusion specifically demonstrated for coding agents.
From the point of view of lived experience, however, the mechanism is easy to recognise. If the result is excellent, I want to see how far I can take it. If it is almost correct, I want to finish it. If it is wrong, I want to understand why.
The button to continue is always only a few seconds away.
What are we actually measuring?
Who Burned More asks, in a deliberately playful tone, a question that describes this phase of AI-assisted development rather well: who burned more tokens?
It is an interesting metric and can be useful for understanding the consumption of different models, but it does not directly measure the quality of the work. Sixty-five billion tokens can represent an enormous amount of useful activity, but also contexts loaded repeatedly, failed attempts, agents sent in the wrong direction, changes later discarded, or code that someone will still have to understand and maintain.
The counter goes up in all of those cases.
It is the same problem we have already encountered with lines of code, commits and closed tickets. They are easy metrics to collect and difficult to connect to value, but precisely because they are visible, they end up becoming what we watch and compare.
To understand whether AI has actually made me more productive, I would need to measure not only the amount of code produced or the time required to reach the first solution, but also the time spent preparing instructions, supervising agents, reviewing the result, correcting mistakes and maintaining what has been built. I would also need to consider how much of that work has spilled into evenings, weekends or moments that I would previously not have devoted to development.
I would almost certainly discover that I produced far more software. Not necessarily that I saved time.
More productive, but not more free
I have no doubt that Codex and other coding agents have increased what I am capable of building. I can explore more solutions, work on parts of a project that would previously have required additional expertise, and move several activities forward at the same time when I would once have had to do them one after another.
The 65 billion tokens from the past week are evidence of that, but they are also a warning.
That amount of processing would not have existed without the ability to let agents keep working continuously, run several of them at once, and continue with another iteration even when my normal working day should already have ended. The technology has allowed me to produce more, but it has also reduced the perceived cost of continuing almost to zero.
The question, then, is not simply whether AI makes us more productive. It is who gets the time that it was supposed to save us.
If every hour freed up is immediately filled by another task, if every result pushes us to wait for the next one, and if the working day ends only when we no longer have the energy to check another run, AI will certainly have increased our output, but it will not have given us our time back.
Perhaps the benchmark that coding agents are missing should not measure only how much work they are able to complete.
It should also measure whether, while they keep working, we are still able to close the computer.