# AI prices fell up to 22x. Our bill fell 2x. Here is where the rest went.

Published: 2026-09-16T13:00:00.000Z · Author: Rod Amora · Canonical URL: https://rodamora.com/blog/ai-prices-fell-up-to-22x-our-bill-fell-2x-here-is-where-the-rest-went

> At Berry, we use cheaper models to give agents harder work, with a monthly model bill less than half its old size. But making the output useful can take better instructions, not more tokens.

If you see a model get twenty times cheaper and expect your company's AI bill to fall by the same amount, that's a reasonable read of the pricing page. What happened to my company was that we used the lower prices to give the agents harder work, so we kept part of the saving and spent part of it on what they could do.

The old models were 9.1x to 22.2x more expensive than the ones we use now, and our monthly model bill fell by a little more than half. Our new software uses about ten times as many tokens across the month, these are Berry's actual monthly figures, not a comparison of the cost of one task.

But some of what we produced was so far from what people wanted that they took it to ChatGPT to summarize it themselves. They told us the meeting transcripts were too long, they weren't useful, they weren't going to use them.

We only had to change the instructions for those transcripts. That's a different kind of improvement from the extra work we were paying the agents to do, because making the output useful doesn't always mean spending more.

## AI token cost and the bill move on different lines

The simple arithmetic is a price divided by twenty, multiplied by ten times the usage, which leaves you with half the original bill. That's an illustration of how the two changes work together, not an exact reconstruction of our invoices across different models over several months.

I'm talking about the [tokens a language model bills you for](https://rodamora.com/glossary/token), not crypto tokens. For that part of the bill, you multiply each type of usage by its rate and add it up.

So yes, cheaper models can give you a proportionally smaller bill if the work and the way it runs stay the same. But at Berry we changed both, because work that hadn't been worth running became affordable.

And OpenAI puts the cost distinction plainly in its [July 2026 investment guide](https://openai.com/index/managing-ai-investments-in-agentic-era/): “The lowest token price does not always produce the lowest total cost.” You still have to count the attempts and the people checking what came back.

## Where the tokens went

At Berry, we started handing the agents much more complex tasks, analyzing large amounts of data, creating charts, building presentations, monitoring data, updating their own memory, joining in more often in group conversations they were already part of.

Those were things we could now afford to have the software do, including work that happened without another request from a person.

Take monitoring as an example of what that means. Asking for a report when you need one and having an agent keep reading the data so it can notice a change are different jobs, even if the person ends up reading one short message in either case.

And the memory work happens behind the answer too, the agent updating what it needs to remember doesn't have to produce another document for someone to read. More tokens can mean more work behind a smaller amount of visible output.

That is what I see at Berry, not a list of jobs every service firm should automate. And getting there took several months of changing the software, it wasn't something we got by choosing a cheaper model from a menu.

## The cheaper model did not do this. The rebuild did

Over those months we redid pretty much all the code, with better rules for the model, code that prevented bugs, better system prompts, better memory, newer approaches and technologies. The system prompts are the standing instructions the model works from.

So the tenfold increase in monthly tokens came from that rebuilt software doing more work, it doesn't mean each task became ten times larger. That broader change took months, the transcript instructions were a much smaller fix inside it.

If the work you want requires that kind of rebuild, your team needs time to change the software and check it. They aren't slow to adopt because they haven't fitted months of work around their existing jobs.

The smaller monthly model bill doesn't tell us whether we've paid for those months of work. As I explained in [the cost cut we couldn't call a win](https://rodamora.com/blog/the-23-ai-cost-cut-we-couldnt-call-a-win), you need to count work that met the standard and time spent correcting it before you can say delivery got cheaper.

And even after you've built it, you still have to find out which of those newly affordable tasks produce something people want.

## People told us what they wanted to read

With the meeting summaries, people were explicit about what they didn't want. They were summarizing the summary in ChatGPT themselves, so we had left them another step to do before they could use what we sent.

And they mostly knew the format they wanted, a TLDR, a quick summary at the top, a short list of the points discussed with the times they happened, then a to-do list of what they had agreed upon and a closing summary.

That gave us something specific to put in the instructions. We didn't need to rebuild the software to make that change, and it isn't an example of spending more tokens to get a better result.

So if you've done that too, it's okay, we got it wrong as well. I would look at what the system is sending before deciding that people aren't paying enough attention to it.

We also added too many notifications about changes, and that turned into noise too. What I found was that people welcomed less output of better quality, and I felt the sweet spot was to show only what was relevant at the time it was relevant.

So before spending more, I would find out what the person actually needs to receive.

We should not build a feature just because we can.

We ran into that with reports at Berry too, producing more didn't help when nobody wanted to read them. Making the result useful comes before deciding whether it needs more work behind it.

## Review time went down, not up

There were other parts of our work where the model was doing more behind the answer, including checking part of what it had done. As the models improved at Berry, we saw fewer mistakes and review time went down, even as we handed the agents harder work.

That matters because [being able to afford more agents doesn't mean you can afford to watch them](https://rodamora.com/blog/you-can-afford-more-agents-you-cant-afford-to-watch-them). If each new task adds something a person has to inspect, the model bill can stay small while the manager's week fills up.

I call that depth, work behind an output to make it more correct, better checked or better timed, and part of our extra token use went into those checks. Output is the amount we put in front of a person to read.

For example, an agent can read the records behind a report and check the figures without sending the manager another report. That is a reason to consider more work behind the answer, while making the meeting transcript longer gave people more to read without giving them what they wanted.

I don't have a clean before-and-after number for time spent reviewing to give you. This is the direction I observed in our work, not a measured ratio you should put in your own budget.

And a model checking itself doesn't remove the need for a person to own the standard. Keep [model cost and review cost together](https://rodamora.com/blog/the-four-stages-of-reviewing-ai-work), and check whether the finished work passes, rather than treating an extra AI check as proof that it does.

## How much work we assign matters more now

Earlier at Berry, we were paying for more intelligence than some of the work needed, so [the model choice](https://rodamora.com/blog/your-ai-employee-has-a-rate-card-you-set-it) was the first cost setting I would look at.

But by September 2026, at Berry, we were using one policy for pretty much everything. Models got so good that even the cheap ones were enough for most of our workflows, so we no longer needed to spend most of our attention on that choice.

The larger decision became scope, how much work we handed the agents, how many steps they took, how much background information they read, what they remembered and what they kept monitoring. Adding another recurring monitoring job changes usage even when nobody changes the model.

That doesn't mean you should put every task on the same model because we mostly do. A mistake in a draft and a mistake in a price sent to a client still carry different consequences, so [sort the work by what getting it wrong costs](https://rodamora.com/blog/cheap-mistakes-go-to-ai-expensive-ones-wait), and keep the stronger model and extra check where the work needs them.

## Decide where the cut goes before it arrives

Before adopting the next cheaper model, sit down with whoever owns the system and the person who uses its output. Start with what that person needs to get from it, rather than how much more the agent can now afford to do.

For every proposed task that sends something to a person, answer “who reads this, and when?” If the answer is a manager before the weekly meeting, that gives you a reason to choose that timing instead of sending every change as it happens.

Then look at the simplest change that could deliver it. If people can describe the format they need, put that in the instructions and have them look at what comes back before planning a larger rebuild.

For background work, name the result it improves instead, a memory update doesn't need its own reader. But somebody should be able to explain which later answer needs that memory.

Where the proposed work does need more steps, more checking or new software, ask whoever maintains the system what that change requires. Put the work of building and checking it beside the added running cost, so the cheaper model doesn't hide the larger commitment.

Now you can decide where the saving should go. You can keep it as margin once the full costs support it, spend it on depth, add new scope, or pay to get work finished sooner, but the decision should name the work and the result you expect from it.

At Berry, the model bill ended up less than half its old size while we spent more on scope and depth, and some of that scope turned out to be noise. Those figures tell you where we ended up, they don't tell you that we planned that exact split or that profit went up after paying for the rebuild.

Keep counting accepted tasks, the ones that meet your standard, as you expand, with failed attempts and correction time still in the cost. Otherwise the new work can look cheap because you're counting everything the agent attempted as something useful it finished.

This is the question in the [Four Numbers](https://rodamora.com/four-numbers), where did the freed capacity go? It applies to cheaper model usage for the same reason it applies to [the extra time AI buys your team](https://rodamora.com/blog/the-extra-time-ai-buys-you-is-already-gone), someone needs to assign what became available and check what it produced.

This advice assumes agents already run inside real workflows with an acceptance check, the move from Stage 2 toward Stage 3 on the [Delivery Model Ladder](https://rodamora.com/delivery-model-ladder). If people are only using a fixed-price chat subscription, a lower token price doesn't automatically lower that subscription or give you a usage budget to redirect.

And someone has to be able to change the software, inside your firm or through whoever maintains it. A lower rate can reduce the bill for unchanged usage, but the new capability we got took months of rebuilding.

You don't control when the next price cut arrives, but you can decide what work it will pay for before you adopt it.

Decide before the invoice does.