Token prices keep falling... while AI bills keep growing. We found five levers that cut agent costs without asking you to accept worse output.
Why cheaper tokens lead to bigger bills
In 1865, English economist William Stanley Jevons noticed something odd about coal. Steam engines kept getting more efficient and needed less coal for the same work, yet Britain burned more of it every year. Cheaper energy made far more things worth doing with coal, and demand ate the savings.
Tokens are going through the same thing. The price of a single token has dropped more than 90% since 2023, and spending on LLMs has roughly doubled since late 2025.¹ Apollo's chief economist Torsten Slok calls it "Jevons paradox in action": as tokens get cheaper, companies run more agents, automate more workflows and generate more code, so total spend climbs while each unit of intelligence gets cheaper.²
In September, the market shipped a partial answer. TypeSafe released Jev, a "decision model" for the small judgment calls an agent makes all day: which tool to call, which model fits the task, whether a result is good enough to act on, etc. It returns typed decisions with confidence scores, and its input costs $0.042 per million tokens, against $5 for Claude Opus 5 input.³ ⁴
Our guess is that this kind of infra change will take a while to reach most stacks. We run agents in production at Vybe, and the five changes below are the ones that worked for us. None of them needed new infra, and our output held up on the checks we run. Each section comes with our own numbers.
Choosing the model for each task
If every agent in your stack runs on the most expensive model, it's usually because that was the default and it never got revisited. It's also the cheapest thing on this list to fix.
We set the model at several levels: for each agent, each scheduled task, each skill and each step inside an agent. That way one agent can draft a customer reply on a frontier model and tag the incoming ticket on a small one.
Go task by task and ask what each one needs. Pulling a few fields out of an email, tagging a support ticket, deciding which queue a request goes to or turning meeting notes into a table all follow fixed instructions, and a small model usually handles them as well as a frontier one. The price gap between tiers is large: on Anthropic's public pricing, Claude Opus 5 costs $5 per million input tokens, Claude Sonnet 5 costs $2 and Claude Haiku 4.5 costs $1.⁴ That's a 5x gap between the top tier and the bottom one, from the same provider...
Say a scheduled task summarizes your support tickets every day on Opus 5. Move it to Haiku 4.5 and the input side of that job costs 80% less at list price. Your task mix will be different from ours, so check that ratio against your own bill.
Make sure you don't swap models blindly, though. You should instead run both models on a sample of real tasks. Then compare the output, and only keep the cheaper one if the quality is good enough.
(P.S.: you can't imagine the number of people who use Fable 5 for simple tasks...or lesser models for intelligence-intensive ones)
Cutting how often our crons run
While most people think about choosing the right model for the right task, they sometimes overlook their cron tasks. When you use scheduled tasks, you are just periodically prompting an LLM, no matter if there is something to do or not. We audited our own scheduled agents, and it turned out there were a few ugly numbers.
One hourly cron was on track to cost about $961 a month. A sync scheduled every 15 minutes ran 96 times a day, and almost every run found nothing new to process. If you have a few like these across your fleet, you'll end up paying a lot for polling that returns no results.
Then the weekend numbers came in: our runs cost more on Saturday than on Wednesday, even though tokens cost the same on both days. What changes is the mix of agents. On a weekday, the cheap agents that answer humans do most of the runs. On the weekend, the heavy scheduled agents keep running while the team is offline, so the average run costs more. And if one of them is wasting money on a Sunday morning, it keeps wasting it until someone looks on Monday.
Below are a few things we tried:
- We audited at the agent level. We walked the whole roster of scheduled tasks and asked what each run was for. Each cron task looks small and justified on its own. You only see the total when you put the whole list side by side.
- We matched each schedule to how often events happen. A sync that checks something every 15 minutes should run that often only if records arrive every 15 minutes.
- We now handle no-ops: the run checks for work and if there's nothing new it stops before touching a premium model.
- We slowed down schedules for output that waits on a human. If the result won't be read until Monday, running it hourly all weekend buys you nothing.
Moving from polling to triggers
Imagine having an employee knock at your door every 15 minutes asking you if there's work for them. At some point you'll get annoyed and tell them you'll be in touch when there's work (...or fire them but let's not go that far). A scheduled task is basically that employee: an agent asking "anything new?" over and over and coming back empty-handed most of the time. That's why triggers exist: they flip the whole logic around. The trigger just waits patiently (for free), until they're told there's work to do.
On the agents we moved from polling to triggers, the trigger setup ran at about 5% of the polling cost.
But of course triggers aren't perfect either. In some cases polling works best: when there's no event source to subscribe to, when you need a guaranteed check at a fixed interval or when you need to process stuff in batch, like once a week ("every week, check new deals and enrich them" would perform better than "enrich each new deal as they arrive" if that makes sense in your workflow).
Running batch jobs on a cheap model
The weekly deal enrichment above is one example. Some workloads are batch by nature: tagging a whole contacts database, cleaning a backlog of records, classifying a quarter's worth of tickets, stuff like that. There's a lot of it, but every record gets the same treatment.
For instance, we needed to categorize an entire contacts database: sending the work as a batch enabled us to pay only $2 for the whole job. Two things made that possible:
- The pareto frontier is progressing fast, meaning cheap models are now very good for "mechanical" output
- Batch jobs are pretty easy to verify and loop on: you sample 10-20 results and ask a better model to judge the output, then improve the prompt and run the whole batch.
Jev (that we talked about a bit earlier) is pretty good for such cases.
Get that check in place before you let the job run on everything. Then give the work to the cheapest model that passes it.
Trimming context
Most agent cost is input cost, and a lot of that input is context the task never needed.
Spotify's engineering blog recently described routing bulk file reads to a cheap worker model, so the expensive model never sees the bulk I/O. In their test against a Java monorepo, bulk reads came in around 90% cheaper than Claude Code doing those reads itself.⁵
We ran our own version: a cheap extraction model read webpages first and passed the main model only what it needed. On our evals, that cut combined model cost by 36% against the main model reading the pages directly, and the answer checks still passed.⁶
We also got it wrong once. When we applied the same trick to file reads, we worried the agent would miss dependencies, so we gave it broad line ranges instead of targeted ones. Cost went up: the broad ranges cut out the surrounding structure, so the agent spent extra reads rediscovering dependencies a full read would have shown it, and the extra round trips cost more than the trimmed context saved. Targeted ranges, chosen more selectively, turned it around: a 6% saving, with all 18 tasks passing. We'll publish the full experiment in a follow-up piece.
Not everything should cost a token makes the same point about deterministic work: send the cheap model what it needs, and keep the expensive model for the reasoning only it can do.
Compaction and other model calls that could be tools
Agent runs carry meta-work the user never sees, and conversation compaction is the clearest case: when a thread gets long, its history gets compressed so it keeps fitting in context. The default is to ask the main model to summarize its own conversation, so your premium model re-reads the whole thread at full input price to produce scaffolding. A cheap specialized tool or plain deterministic trimming (keep the system prompt and recent turns, drop dead tool outputs) does the same job for a fraction of the cost.
Structured extraction, classification and formatting belong in the same bucket. When the output follows a fixed format, a tool or a small model can usually produce it.
Reviewing the bill every month
You'll have to redo these checks regularly. New agents show up and schedules drift. A model swap that made sense in June might not be the right call by December.
Once a month, look at cost per run and cost per agent, week over week. Check which agents grew, which runs found no work to do, which model tiers got more expensive and where retries piled up.
And then there's Jevons again. Every change above makes agents cheaper to run, which makes it tempting to run more of them, and the monthly review is how you find out whether the savings survived. Check quality after every change too, and roll back any swap that starts failing its checks.
Where we are with it
We're still tuning most of this. The context experiment is the one with the most open questions for us, so its full results get their own post rather than a paragraph here.
If your AI vendor bills per seat while your costs scale with usage, that gap grows every month. We wrote up why per-seat pricing is about to break if you want the longer argument.
Sources
- Fortune, "Tokens are getting cheaper, but companies are spending even more on AI as a result, top economist warns" (June 17, 2026): the price of a single token has dropped more than 90% since 2023 while spending on large language models has roughly doubled since late 2025, per the Silicon Data Token Expenditure Index. https://fortune.com/2026/06/17/why-is-ai-spending-increasing-as-tokens-get-cheaper-jevons-paradox/
- Torsten Slok (Apollo), "Cheaper Tokens, Bigger Bills" (June 12, 2026): "The Silicon Data Token Expenditure Index, which tracks total spending on large language model usage, has roughly doubled since late 2025 even as the price of a single token has fallen more than 90%." He calls the dynamic "Jevons paradox in action." https://www.apollo.com/wealth/insights-news/insights/daily-spark/cheaper-tokens-bigger-bills
- TypeSafe, "Introducing System One Models & Jev" (September 15, 2026): Jev answers the small judgment calls an agent makes constantly with typed decisions and confidence scores instead of generated text; input costs $0.042 per million tokens, output tokens are free. https://typesafe.ai/blog/introducing-system-one-models-and-jev
- Anthropic, Claude Platform pricing docs (verified live September 21, 2026): Claude Opus 5 $5 / MTok input, Claude Sonnet 5 $2 / MTok, Claude Haiku 4.5 $1 / MTok. https://docs.claude.com/en/docs/about-claude/pricing
- Spotify Engineering, "Portal by Spotify cut my Claude Code token usage by 90%" (September 2026): "Tested against a Java monorepo across four scenarios... Mean bulk-read savings were around a whopping 90%." https://engineering.atspotify.com/2026/09/portal-by-spotify-cut-my-claude-code-token-usage-by-90
- Vybe internal experiment, September 2026: controlled runs with extraction-worker costs included in every figure; experiment-scale results, not production-wide averages. The 36% (webpages) and 6% (file reads) figures are from our own controlled eval runs.
