Putting My AI on a Budget Without Touching the Checks: Extended Version

This is the extended version of Putting My AI on a Budget Without Touching the Checks. That article tells the story: what I changed, what the checks caught, and what I still have to measure. This page holds the method, the numbers by period, and the caveats, for readers who want to check my work.

The Frame

I pay a flat subscription. Every dollar figure on this page is what the same use would cost at pay-per-use list prices. None of it is money I spent or saved. The figures also can't show how much more work fits inside my weekly allowance, because my usage logs never read the plan's own usage meter.

These figures cover every session my main AI coding tool logged on my laptop. The data runs from October 1 to the evening of October 22: 19 days worked, 56,685 AI calls after duplicates were removed, and about 12.2 billion tokens. About 95% of those tokens were the AI re-reading what it had already read. Days follow my laptop's clock, so late-evening work can land on the next day.

Re-reading is billed at a small fraction of the price of new input. Storing each new part of the chat so it can be re-read later makes up about half of the estimated cost. That is why the token count is large and the dollar figures are small.

These numbers come from my own setup. They are not a forecast for your team.

A Call Is Not a Task

An AI call is one exchange with the model. One task can take many calls, as the AI reads files, uses tools, writes code, and checks the result.

So cost per call can fall because the mix of work changed, and cost per day worked can fall because I simply did less. Neither one counts finished, accepted work. I use both because they are the fairest measures I have, and I read them side by side.

What Changed, and When

• Early October: I added rules that load into every chat. By my estimates, that extra text costs about $55 a week at list price.
• Around October 6: a setting for shorter replies. The switch date is inferred, not recorded.
• October 12: dynamic model routing. The coordinating agent judges how hard each task is and picks a model. If it is unclear how hard a task is, it goes one tier up. If a cheaper model's answer is incomplete or uncertain, a stronger model repeats the task.
• October 14: a usage baseline. It only measures.
• October 16: the chat-length monitor, rebuilt, and the RAG search, switched on. The search was working from October 17.
• October 21: reports go to the coordinating agent instead of my main chat; an effort setting for mechanical steps; and the rulebook trim.
• October 22: the cutoff for these figures.
• October 23: one reading of the plan's meter, and the main article went live.
• October 31: the planned accuracy test for the search.

I had built a chat-length monitor once before. It disappeared during updates to my setup. That reminded me to check that my controls still work after changes.

The handoff notes live outside every code repository, so a note can't ride along with a code push by accident.

The Numbers by Period

I split the month at the change dates, not by calendar week. The first and last weeks were partial, and a week that spans a change is not a clean reading of either setup.

How I read the table:

• Cost per AI call fell about 23%, from about 10.8 cents (October 1–11) to about 8.3 cents (October 16–20).
• Things got worse before they got better. Routing moved work to cheaper models, but my chats were getting longer while I built it, so cost per call and cost per day both rose from October 12 to 15.
• The last row is two days. It is too short to read on its own.
• The history column covers main chats only. The cost columns cover every call. They measure different parts of the workflow.
• Before October 16, 12 of 30 chats peaked above 400,000 tokens. Since then, none of 101 has (through October 22), which shows the limit is being followed. It is not a result on its own: the monitor splits long chats, so per-chat figures drop by design.
• From September 30 to October 14, main chats were about a fifth of all input tokens. That reading started before the routing work did, so it is not a measure of the reporting mistake alone.

How the Estimates Were Built

These are my own estimates from my usage logs, at pay-per-use list prices, from each change's start to October 22.

• Build cost comes from the records of the chats that built each change, with a range where a chat mixed jobs. By my own estimates, building all of it took about 275–700 million tokens, the baseline included: $132–334 at list price.
• Shorter replies: the average reply fell from about 641 tokens to about 300. This is the least certain estimate: the switch date is inferred, and my mix of work changed.

  Update, November 3, 2026: this held from Oct 7 to 22. From Oct 23 the average across all AI calls rose to about 983 tokens, and my logs do not show why. The return estimates on this page run only to Oct 22.

• Routing: I compared the list-price cost of the tasks that moved to cheaper models with what the same usage would have cost on the strongest model, from October 12 to 22. It assumes the strongest model would have needed the same calls and tokens, which I can't prove. It does not mean my total usage fell.
• Chat-length monitor: main-chat cost per call before and after the monitor.
• The October 21 changes: two days of data. I can't separate their effects, or project a weekly figure from them.
• Time: at least 10 hours of machine-measured AI run time, added up across agents, for the three builds that have a time record. That is not wall-clock time. My own time was about four hours, by my estimate, mostly keeping an eye on things.

What It Returned

By my own estimates, these changes avoided $413–704 in usage at list prices through October 22. On my estimates, three changes carry most of that: shorter replies, the chat-length monitor, and model routing. On those estimates, the changes had covered their estimated build cost by October 22, even at the worst end of both ranges. That worst end leans on the shorter-replies estimate, the least certain one.

Two things are left out of that comparison. The first is the rule text I added early in the month, about $55 a week at list price. Counting it, the worst case had not quite covered its cost by October 22. The second is my own four hours.

As of October 22, I estimate the changes return about $296–426 a week at list price, before that $55.

The search cost the most to build, $96–216 at list price, and by my estimates it has returned $0–85. It has not paid back.

These are usage figures. Whether the work paid off for the business is not proven yet.

What Each Change Costs to Keep

Not every change reduces usage. The usage baseline only measures; it reduces nothing. The search adds a little text to each prompt. New rules load into every chat, even when each one looks small.

By an estimate from my usage logs, my rulebook made up about 30% of the text loaded when an agent started. The October 21 trim had a narrow test: keep every rule, and confirm the moved history no longer loads. Every rule line was checked by script or traced by hand, and a separate review checked the result. The documentation said the hidden notes would not load. It was checked anyway: when a fresh agent loaded the file, none of the hidden text came with it. The loaded text shrank 16.5% in size.

These records separate three questions: was the change installed, did it behave as intended, and is it worth running. The records answer the first two for most of the changes. The third is what I measure next.

Caveats in One Place

• Several changes landed in the same week, and the monitor and the search switched on the same day. No single change gets the credit for any drop.
• One long chat holds 22% of October's tokens, through October 22.
• The handoff note is set to start at 250,000 tokens. The first real handoff came at 327,000 tokens, on October 16, and the AI wrote its note without me having to ask. My records don't say why it came later than the setting.
• My usage logs never read the plan's meter. Since the changes, I have not hit the cap, but I still come close by the end of each week.
• I have not measured whether long chats reduce answer quality, whether lower effort changes results, or how much is lost when a fresh chat starts.
• On October 23, while reviewing the main article, I checked my usage. That day's work had used 7% of my weekly limit. By that time on a normal day, I am usually at about 14% and rising. It was a normal day for me: several different projects, one of them with about five sessions open at once. That is one reading on one day, not a trend.

What Comes Next

On October 31, I plan to check the search against 20 known questions, including decisions that have since been replaced. A script will score the answers, not an AI. This first version is keyword search only, and it runs on my own machine. Next, I'm looking at indexing my past chats too, and I'm considering a local model.

The four measurements still open are delivery, quality, my own time, and capacity. The main article explains each one.

If You Want to Talk

If you have a project that is stuck, or work you have won and can't staff, I would like to hear about it.

I start with a two-week assessment of one codebase and how work moves through it, including how your team is using AI-written code. You get a written findings document with a prioritized plan.

Send me a message on LinkedIn, or book a 20-minute call.