Four Billion Tokens Later: What a Month With an AI Assistant Looks Like in Numbers

🌐 Also available in: Deutsch · Français · Español

For a few months now, a large part of this blog and of the Ansible code behind it has been written together with an AI assistant: Claude, in its command-line version Claude Code. It writes code, runs commands on the servers, reads log files and drafts articles; I decide, check and say “no, not like that” fairly often. At some point I wanted to know what that actually adds up to. Not in feelings, in numbers.

There is a small community tool for that, ccusage. It reads the log files Claude Code keeps on my own computer and adds them up. One line in the terminal:

npx ccusage@latest daily --since 20260923

npx downloads the tool, runs it once and forgets it again. It reads only the local log files and sends none of their content anywhere; the only thing it fetches from the internet is the current price list. Here is what came out for the four weeks from 23 September to 21 October 2026.

🔢 The raw numbers

🧩 What is a token, anyway?

A language model does not read letters or whole words, it reads tokens: pieces of words. “Firewall” might be two tokens, “the” is one, a long German word like “Datenbankverbindung” can be four or five. As a rule of thumb, 100 tokens are about 75 English words. Everything is counted in tokens: what goes in, what comes out, and – this is the interesting part – what the model has to read again.

📚 98 % re-reading

The most surprising line in the table is the cache. Of almost four billion tokens, 3.9 billion were not new at all. They were the same conversation, read again.

This is how such an assistant works: it has no memory between two steps. Before every single answer – every command it runs, every file it reads – it gets the entire conversation so far handed over again: my questions, its answers, every log excerpt, every file. A long working session on a server easily grows to the size of a short book, and that book is read again for the next step. And the next. And the next.

Imagine an office worker who, before writing each sentence of a letter, reads the complete file from the first page. That is my assistant. For every token it writes, it re-reads about 450. The good news: re-reading is cheap. The provider keeps the conversation ready in a cache, so a re-read token costs only about a tenth of a new one. Which also explains why four billion tokens sound much more dramatic than they are.

✍️ What that means in everyday terms

• 80 novels. The 8.7 million tokens the assistant wrote are about 6.5 million words – roughly 80 novels of average length. Printed, that is a stack of paper about 2.6 metres high. Most of it, to be fair, is not literature but configuration files, shell commands and explanations of why the firewall did something unexpected.
• 23 years of reading. If a person wanted to read all four billion tokens at a normal pace, without sleep, without coffee, without weekends, they would need about 23 years. With eight hours a day, it would be a full working life.
• 475 times as much answer as question. My own fresh input was 18,342 tokens – a few pages of text over four weeks. Short instructions like “check the logs”, “yes, do it that way” or “why is that red?”. The rest comes from the assistant: everything it read on the servers, wrote and explained.
• Four days off. 25 of 29 days had some use. Even an AI assistant apparently gets a weekend now and then – or rather, its human does.

💸 The bill that never came

The tool also calculates a price: 1,407 US dollars for four weeks, about 56 dollars per active day, 118 on the busiest one. That sounds like a lot – and it is not what I paid.

The number is what this usage would cost at the list price of the API, the interface companies use to build the model into their own products. There, every single token is billed: new input, output, writing into the cache, reading from the cache, each at its own rate. ccusage simply multiplies my token counts with those rates.

I use a subscription instead, the Pro plan, which lists at around 20 US dollars a month. A subscription is a flat rate with usage limits: you can work until the limit for a time window is reached, and then you wait until it resets. So the 1,407 dollars are a “what if” – what the same amount of work would cost if every token were billed one by one. For a private project the flat rate is the obvious choice; for a company that builds the model into its product, the per-token price is the normal case.

Those limits are not theoretical, by the way. The most expensive single job of the month was translating the blog afterwards: all 111 existing posts into German, French and Spanish. That ran over several days and many sessions, because I kept running into the five-hour limit – the work stopped in the middle of an article, and a fresh session picked it up again once the window had reset. Translating is reading and writing at the same time, and lots of it; you can see it in the statistics, where 9 and 11 October are among the busier days. A human translator would have needed months for it. The assistant needed a few days and my patience with the reset timer.

⚡ And how many computers had to run for this?

This is the question I would most like to answer, and the one I cannot answer honestly with a number. The model does not run on my computer, but in data centres on specialised chips built for exactly this kind of calculation. How large the model is, how many chips answer one request, and how much energy one token costs – the provider does not publish that, and any precise number here would be invented.

What can be said: a model of this class does not run on a home PC at all. It needs more memory than a normal computer has, by a wide margin. And re-reading from the cache needs far less computing than calculating something new – which is exactly why it is so much cheaper. The 98 % re-reading therefore stands for much less work in the data centre than the raw token count suggests.

🏗️ What came out of it

Counting tokens is fun, but the real question is what they were good for. In about five months, this is what was created:

How long would that have taken the classic way, typed by hand? For infrastructure code, a common rough figure is 30 to 80 finished, tested lines per day – including research, trying things out on real servers and the troubleshooting that often takes longer than the writing. Add documentation and translations, and the estimate lands at two to three years of full-time work for one experienced person. That person would also have to know SELinux, Kubernetes, firewalls, databases, Nextcloud, WordPress and monitoring in depth at the same time – which is rare.

I am not that person either. But I learned a lot on the way, and much faster than I would have otherwise. Every time something did not work, I got the explanation right then: why SELinux refuses a transition, what a hop-by-hop header is, why a database runs without protection although everything says “enforcing”. That is learning exactly at the moment the question comes up – a private tutor who always has time and never says “read chapter 7 first”. A textbook explains a lot I do not need at that moment, and the one page I do need is somewhere in the middle. Here, I read up on a topic in a targeted way, asked follow-up questions, and the deep dives on this blog are what is left over from it.

Lines of code are a rough measure, and the estimate is a feeling for the order of magnitude, not an invoice. More important is what the numbers do not show: the assistant did not decide anything on its own. Every change to a live server was discussed first, every result checked, and some of the best findings came from a simple “that looks strange, can you check again?”. The SELinux deep dive describes two of them. Somewhere around day 20 I also understood where that old IT joke comes from – that some of us talk more to their AI than to real people, their own partner included. In my defence: the AI has never once complained that I explain firewall rules over dinner. The AI takes over the diligence; the responsibility stays with the human. And this is a private project – which means it competes with everything else in life for time. That is exactly the point: precisely because that time is limited, the speed of working with an AI made the difference. A few free hours are not enough to type a firewall by hand. They are enough to discuss, check and roll out one.

🔍 What the statistics reveal

• Big topics make big days. The busiest day, 19 October, was the day the last parts of the Ansible tour and the SELinux article were written and tested – a lot of reading on the servers, a lot of text.
• Context is the real cost driver. Not what I type, and not even what the assistant writes, but how much it has to keep in mind. Long sessions with many log excerpts are expensive; short, focused tasks are cheap.
• It is not the model that writes the most. It reads. 450 tokens read for every token written – that is less “creative writing machine” and more “very fast colleague who reads the whole file every time”.

🧔 My personal view – a little pointed, and only mine

For me, the real value of all this is not the clever answers. It is time. Two to three years of work in about five months – that is the difference between a project I would have dreamed about and a project that runs. Hardening, monitoring, documentation in three languages, a blog in four: none of it would exist in this form without the assistant, simply because a human lifetime has a limited number of evenings.

So here is my personal view, as someone with 20 years of professional experience who has typed more than enough configuration files by hand: for my own private projects, writing infrastructure code line by line by hand no longer fits the times. To me it feels like the punch card of our era – honest, admirable, and for me personally a way to spend three years on something I can now do in a few months. That is not a judgement about anyone else: some of the most careful administrators I know write every rule themselves, and they have good reasons. I have simply moved my own care somewhere else – to the questions, the review, the tests and the decisions. That is where I find a human irreplaceable, and that is where my saved time goes.

Hand-written Ansible will survive, of course, and rightly so – next to vinyl records, mechanical keyboards and the person who compiles his kernel on principle. Maybe one day I will join them out of nostalgia. For my own projects, though, in the little spare time left next to family and job, it is no longer the method I choose.

And yet, there is a less cheerful side to this, and it would be dishonest to leave it out. Two to three years of work for one person in five months – turned around, that also means: a project that used to keep a small team busy for a long time now needs one person and an assistant. For me, with a private project and limited time, that is pure gain. For teams and professions that have lived on exactly this kind of careful manual work, it is a real question, and nobody has a good answer to it yet. The right path is faster. It is also emptier.

I think many of us are standing at this fork right now, whether we want to or not – administrators, developers, technical writers, translators. I have taken the right path, because for my situation it is clearly the better one – for other situations the answer can be quite different. But I look back over my shoulder now and then. The people who still stand at the signpost are not behind the times. They are weighing something that deserves to be weighed.

🎬 Conclusion

Four billion tokens sound like a science-fiction number. Translated into everyday terms, they are a colleague who never gets tired of re-reading the whole file, writes 80 novels of configuration in four weeks, and would have sent a bill of 1,400 dollars if there were no flat rate. What remains is code that runs, servers that are better protected than before, and a blog that now speaks four languages. And the realisation that the shortest sentence in all those billions – “yes, do it that way” – was still the most important one.

And one last personal note. Officially, I call this blog and the code on GitHub my volunteer work in 2026 – it simply sounds better at parties 😉 Honestly, though, it is above all the best continuing education I have ever had: I learn an incredible amount technically, more in a few months than in many a training course, because every question gets its answer exactly when it comes up, and my scarce spare time goes into understanding instead of searching. Efficient, effective, not a minute wasted. Written by a Xennial, born in 1979 and so exactly one year too early to officially count as a digital native, but just late enough to have grown up between the cassette recorder and the first modem – so the learning curve is steep, but the fun is too. The volunteer part comes along as a bonus: everything ends up as something anyone, anywhere in the world, can use for free if they face the same tasks: running WordPress or Nextcloud securely on their own servers. If it saves someone in another country a few evenings, the four billion tokens were well spent.

If you want to look at your own numbers: npx ccusage@latest daily in a terminal on the computer where Claude Code runs. It reads only local files and fetches nothing but the price list.