Over the past few months, I have averaged roughly 100+ million AI tokens per week. More recently, usage has accelerated to 300 million per week. The number is quite large, but tokens show activity, not output. Does that usage allow me to produce more meaningful results, though? In addition, how does it increase costs elsewhere, such as in attention, reviews, and coordination? My rough subjective estimate is that it improves my personal capacity by approximately 25%, but moves the bottleneck away from implementation and toward identifying priorities, supervising parallel sessions, and reviewing their outputs.
How my usage reached 300M tokens a week
The tokens include input, cached input, and output tokens. Approximately 95% of the tokens are cached, and less than 1% are output tokens. Essentially, I have settled on having multiple parallel sessions that are moved forward bit by bit over the course of a few days or weeks. Most of what I do is related to software, such as developing new features, reviewing code, and researching topics. The models I use keep changing, but I usually use the latest Opus model (currently Opus 5) and the latest GPT model (currently Sol), with a large context window and increased reasoning effort. I have found that using both models on the same task to reevaluate suggestions as I approach the “end” usually highlights additional things for me to address and generates additional token usage. A single model rarely gives me a great result on its own.
The trend in token use is also quite interesting. I saw that stats appeared in November, at around 60 million tokens a month. The last 28 days show 1.2 billion tokens (Fig 1). The increase probably reflects a combination of changing work habits, additional scheduled tasks, improved agent tooling, and broader token accounting. The dip in the middle is when I was on holidays.
I use a few tools daily to interact with LLMs. I have a desktop application that is similar in spirit to OpenClaw and supports cron. It has several scheduled prompts that I have set up to check the status of PRs and summarise messages and emails. I also use VS Code, its chat interface, and its “agents view” to work on code. In addition, I use a CLI to spawn several long-running sessions that can interact with a variety of MCP servers, research directories, and work with Azure DevOps and GitHub. VS Code is slightly more cumbersome to set up for tasks that the CLI can handle successfully, but it has other benefits, as I can easily modify the code in parallel.
What changed in my actual work and output
An important observation is that I now spend more of my time managing various parallel sessions and iterating on them. I also need to review an increased number of PRs. To make sure that I still enjoy my work, I need to push the boundaries by exploring more difficult and deeper topics. For example, I might start a parallel analysis of an approach to reduce latency by an order of magnitude, which leads me down a variety of rabbit holes and into on-the-fly performance testing (yes, I consider it fun). One example was a recent long session in which I was trying to improve and test the reproducibility of containers, during which I switched between the models over the course of two weeks. The session consumed more than 15,000 AI credits (not tokens) as reported by the tooling, equivalent to well over 100M tokens by my estimate.
Conversely, to reduce daily toil, I have had to develop shortcuts. For example, I ask an LLM to review PRs before I examine them, helping me focus attention on core changes. This reduces the amount of context I need to load, given that PRs have recently increased in size and reading 1,000 lines is not fun. A related issue with PR reviews is that detailed manual review is becoming harder to coordinate because LLM-assisted reviews can shorten the approval window. This creates a risk that multiple reviewers perform overlapping work while important concerns still receive insufficient attention.
To reduce other forms of ordinary daily toil, I keep plain-text to-do lists that are managed by agents. These act like queues of backlog items that I can pick up piecemeal in the morning and start moving forward. I have not yet started managing my backlog on the project board because requiring the agent to make API calls through an LLM adds unnecessary overhead.
By the way, some LLM-generated work is becoming an issue. The code is beautifully formatted and the comments are well-formed, but the implementation itself can be a bit over the top. Directing agents (with different models) to review it may find various aspects that need improvement, although you would expect those to be found at the time of implementation. In addition, this issue is compounded by automated reviews that may suggest approving the generated work. I suspect this happens because the same model family is reviewing it, or because of lax review instructions. The code then risks being merged. Just recently, my automation pipeline sent me a notification that a PR looked great and suggested approving it. I double-checked and found some issues. Needless to say, the automated steps needed improvement. I sometimes use projects like microsoft/PromptKit to inject some predefined skills instead of relying on long sentences to provide all code-generation and review guidelines, but I also switch models to surface different aspects and broaden the review.
Another related issue is that LLM review suggestions on PRs are sometimes ignored and treated as noise (because sometimes they are), and more importantly, they are not human comments, which makes them easier to dismiss. In the end, a habit emerges in which an LLM shows you some good-looking code, which is then pushed, and even if an automated agent adds comments, they could be dismissed as noise. Your peers may then use the same model families to verify the work, potentially concluding that everything is fine. It could then be approved, leaving less time to review it in the traditional way. I believe some combination of team acknowledgement, discussion, and shared practices is necessary to avoid these issues because I have not seen tooling that reliably prevents them from slipping through the cracks. Tooling must improve, and people must understand and continually review the generated results.
OK, so the routine has changed, but what about the output? Is it worth it? I would say that it is, because you can ship more. My data shows that I added more PRs, solved more issues, created more docs, and did more analysis, but the numbers are not dramatic. They have all increased a bit over time, but only by a few additional items each week, e.g. a few more PRs. I can handle more parallel work.
I can also track larger pieces of work more actively and complete them within a week or two while continuing to work on other things in parallel. Larger pieces require more time and possibly delegation, which can now be handled by an agent. As mentioned earlier, a few more experiments are completed each week, fuelling conversations about where to go next.
My subjective estimate is that working capacity is 25% larger, particularly when parallelising and doing analysis. However, the measurable increase in PRs and docs remains relatively small, although PRs cannot be used to infer the full value. From the business perspective, it does not look like a huge improvement despite the increase in activity. There are still weekly, biweekly, and monthly calls, and the number of things committed to and announced has not changed much. For example, we might mention four things on a slide instead of two, but if everyone’s output increases similarly, it could become the new normal.
Is it worth it from the company’s perspective? That is difficult to determine because increased token usage does not correlate well with the results. That token expense could also fluctuate if a new model suddenly starts requiring more back-and-forth interaction, if prices change, or if a random bug causes the tools to go rogue. There is also a grey area around generating output that looks great but could contain hard-to-see issues at this increased pace of work: technical debt. This can create more issues and consume everyone’s time, but it is difficult to determine the monetary risk involved.
Where the bottleneck moved
Where are the new bottlenecks? In my view, it has become more important than ever to define the direction, features, and opportunities for market capture and to communicate them explicitly to employees. This requires more effort from people setting product direction. The reason is simply that we can now achieve a “wider” impact per hour or per day.
In my opinion, the risk of failing to expand the frontier is that employees will continue doing what they did before, only slightly faster. They may also create low-level routine work simply because they can. For example, you might run out of large tasks and then ask an LLM to generate a to-do list for improving text, refactoring small pieces of code, or performing similar work. This may look valuable at first glance, but it is an opportunity cost. I think it might be better to bet on larger features and constantly evaluate the competition to avoid falling behind. The cost of failure should be lower now because it is cheaper to evaluate proofs of concept, as engineers can keep those running in the background next to their usual work.
What about tokenmaxxing? Could I not simply burn more tokens to complete even bigger pieces of work? This is an interesting topic, as I have read about people reaching extremely high usage numbers by running tasks in loops 24/7. However, this comes back to the issue I mentioned earlier: there needs to be a valid opportunity to justify doing something big, and that usually requires management to be aligned. Otherwise, you risk stepping on somebody else’s toes, or burning tokens on what looks big but might actually be small potatoes and a pile of technical debt.
Another issue is the sheer volume of generated output that needs to be reviewed. If the review is skipped, the result becomes another proof of concept or demo. It might be valuable, but it could also waste everyone’s time and attention. For example, I might sometimes generate tens of thousands of lines of code. I then need to spend hours internalising the code, however useful it may be, and subsequently split it into chunks so that I can focus on it more effectively. As an exercise, it is definitely useful to test ideas, but spraying generated content around with little oversight is a nightmare unless somebody is paying for its later maintenance.
A possible alternative to the individual bottlenecks could be end-to-end, LLM-based automation embedded into processes and tools. From where I stand, it is not very clear how much horizontal automation is being added to solve teams’ business problems. As with the business processes mentioned earlier, much of what we do is already on some kind of track, and it is difficult to change it; think enterprise processes that stand between you and end users.
There are automated PR reviews and attempts to assign agents to tickets. Then there are analysis tools that scan codebases and content, although these already existed. Some promising automation exists on the incident-analysis side and can resolve well-known or documented issues because it is flexible enough to check and evaluate loosely related details. At least for now, generative AI appears to be a tool for augmenting individual workflows, rather than something you can easily leave to run end-to-end and earn money without supervision or evaluation.
All in all, the tooling is changing constantly, just like the models. There is plenty of room for new opportunities, and I think we will eventually end up with better IDEs and interfaces for interacting with these systems. In the meantime, I will continue counting my tokens and recording my work in local Markdown session documents so that I can reason about the value these newer tools provide. It will also be interesting to see how other fields evolve and how these tools augment their workers.