Five Ways Engineering Teams Are Cutting AI Spend in 2026 (and What Each One Returned)

The fastest way to reduce AI spend in 2026 is to stop treating it as one bill. The teams getting real reductions split it into access, routing, build-versus-buy, work selection and guardrails, then attack the one that dominates their own usage. The teams getting nowhere buy a dashboard and wait.

Here is the number that should reframe the problem. In a survey of 396 organisations run in April and May 2026, 98% track AI infrastructure costs and only 11% can forecast their AI spend within 10%. Forecast accuracy went down from 2025 while tracking went up. Visibility arrived. Control did not follow it.

What you get here: five approaches, each one attached to a named team that ran it, the steps they took in order, and what came back. Plus the two savings in this set that reversed, told by the people they reversed on.

What changed in your AI bill, and when did it change?

Something specific happened in 2025, and most cost-cutting advice still has not caught up with it.

We checked the pricing history of ten AI coding and AI dev tool vendors against their own blogs, changelogs and docs. Six of the ten repriced between 13 May and 28 August 2025, and three of them did it inside the same 72 hours in mid-June.

The pattern is not that prices went up. Mostly, they did not. GitHub held its seat prices at $10, $19, and $39 across two separate repricings. Anthropic's Pro and Max prices did not move when weekly caps arrived. Windsurf cut its Teams seat from $35 to $30.

What changed is the unit you are billed in. It moved from the seat to the request, and then from the request to the token.

GitHub's second move, announced 27 April 2026: premium requests replaced by credits consumed on token usage, "using the listed API rates for each model."

Cursor published the reason plainly, and it is the most useful sentence a vendor has written on this subject: request cost stopped being uniform.

"The hardest requests cost an order of magnitude more than simple ones. API-based pricing is the best way to reflect that." Cursor, 4 July 2025.

An order of magnitude between your cheapest and most expensive request is the whole story. Under a seat licence, that variance was the vendor’s problem. Under metered billing, it is yours. Every technique below is a way of managing variance you did not have to manage eighteen months ago.

Two caveats, because the pattern is not universal. Windsurf went the other way in April 2025, abolishing flow action credits so customers "only pay per user prompt." Cognition retired Devin’s pure pay-as-you-go plan in April 2026 in favour of fixed $20 and $200 tiers. And OpenAI withdrew Codex pay-as-you-go seats from Business plans in June 2026, less than three months after launching them.

Why has buying visibility stopped being enough?

The standard advice for runaway AI costs is to get visibility first. That advice is correct, but it is no longer sufficient, and the same 396-organisation survey shows why.

Source: Mavvrik with Benchmarkit, State of AI Cost Governance 2026, n=396.

Three findings in that chart are worth sitting with.

Tokens are not the top surprise. Data platform usage overages came first at 47%, ahead of LLM token costs at 43%. The entire token-optimisation genre is aimed at the second-place item. If your retrieval layer, your vector store and your warehouse queries are not in your AI cost report, your biggest unexpected line is invisible by construction.

Most AI cost reports are structurally incomplete. 98% of organisations run agentic workloads and 36% include them in cost reporting. That 62-point gap is where agent spend lives. Separately, 98% use AI coding tools, averaging 2.4 tools each, and only 42% include those tools in AI cost reporting.

Tracking is close to universal. Forecasting is rare, and getting rarer.

The consequences are already landing: 62% of organisations said an unexpected AI cost changed a business decision in the past year: repricing, board escalation, spending freezes, cancelled initiatives.

So the question is not whether you can see the number. It is whether anything in your organisation changes when the number moves.

1. Put spending tiers and approval gates on access

Booking.com ran this one. Christian, a senior technical programme manager there, presented the programme at FinOps X Amsterdam. He owns cloud and AI FinOps and the financial sustainability of their core platforms. The spend in scope is internal: engineering, customer support, and product development tooling, explicitly not the customer-facing trip planner.

The situation: an exponential spend curve on one AI provider from January to June. In his words, that "often triggers panic in finance departments. So they did for us as well, but it shouldn’t necessarily trigger a full shutdown."

What they built, in order:

What it returned: they introduced tiers on one tool in July, and the spend curve flattened from July into August. Worth stating plainly: he shows that effect as a chart on screen and never quantifies it in words. Treat it as directional.

The part that is easiest to skip. His third manager test is the one with teeth: verify whether high usage is intentional "or is it because it’s just unoptimal usage," and he names the two causes to look for, poor workflow design and the wrong model being selected. High usage is not automatically waste and it is not automatically value. Someone has to look.

He is also explicit that the goal is not a lower number everywhere: "In some pockets, we might want to spend a little bit more... to see even more business value."

Right fit: your spend is spread across many individuals on seat-or-credit plans and no one owns the total.

Skip it when: your AI cost is concentrated in one or two production workloads, where tiers add process and save nothing.

2. Route every call to the cheapest model that clears the bar

A software architect at the Israel Tax Authority presented this one at FinOps X Day London in March 2026, drawing on a text-to-SQL application he built there. He describes himself as having spent the last couple of years integrating AI into the software development lifecycle.

The mechanism: put a cheap model in front of the expensive one and let it decide what gets through.

How it works, with his worked example. For a recipe application, a small model first checks whether the incoming query is a recipe query at all. He names the reject cases precisely: "asking you to delete a database" and "asking you for lists of employees." Only in-scope queries continue to the expensive model.

The reframe worth stealing: the guardrail you need anyway is also the cost control. You were going to validate scope for security reasons. Doing it with a cheap classifier means you also stop paying frontier prices to reject junk.

Four extensions he recommends:

His contrarian call, which cuts against most of this category: he expects AI prices to rise, not fall. His reasoning is that current pricing is land-grab pricing. "They price their services very low in order to catch larger market shares... they cannot do that for long so I believe prices will go up." Set against the common view that you can wait for tokens to get cheaper, this is a direct bet the other way, from someone building on a government budget.

Right fit: a high-volume application with a wide spread of query difficulty.

Skip the local GPU step when: your volume is low enough that the hardware never amortises.

3. Replace the paid AI tool with a narrow in-house agent

Prisma's engineering team described this on their own AI Builders podcast: an internal code review agent they built to replace CodeRabbit.

The scale of the thing being replaced, as put to the builder by a colleague on the call: "It’s a billion dollar company. We spend thousands of dollars a month for this thing and you just build a replacement for it in an afternoon that you say is as good or better."

Quote the builder's immediate answer alongside it, because the honest version is the useful one: "As good or better is a stretch still, but we’re iterating on it."

How they built it:

Why it worked this time and not last time. This is worth more than the cost saving itself.

They had tried the same build months earlier and killed it: "we threw like Opus at it at that point and it was costing quite a bit to do reviews because it was loading up all this context. So it was a little bit naive in the context building... we just kind of abandoned that at the time." The second attempt succeeded on three changes, and only one of them was the model: a cheaper open-weight model, the sandbox primitive, and tighter context construction.

Their own test for when this is rational, which is the most transferable thing in the story: blast radius. "If our code review agent were to have an outage, that’s not going to be the most disruptive thing in the world. So the consequences of us operating that is not intense." Build-over-buy is defensible where downtime is survivable. It is not a general rule.

The structural argument underneath it: a commercial product must serve every customer's workflow, so it carries configurability you pay for and never use. An internal tool serves one workflow. That gap, not model pricing, is what makes the replacement cheap.

Right fit: the tool does one narrow job, you can define "done" deterministically, and an outage is tolerable.

Skip it when: the tool is in a critical path, or when the thing you would be rebuilding is the vendor's data rather than the vendor's prompt.

4. Score the work before an agent touches it

Troy Magennis, a forecasting and predictability coach, laid this out in a March 2026 session on how AI changes prioritisation.

The idea: the cheapest agent run is the one you never queue. He is blunt that he nearly got this wrong himself:

"I wrote an article about six months ago where I said, ‘This is fantastic. We can go right through our backlog and throw the whole lot of it at an agent and come back in the morning and have an empty backlog of all of the defects that never got prioritized.’ But that’s plain dumb."

His reason: that plan assumes every item in the backlog was worth doing. Most backlogs contain items that were never prioritised precisely because someone judged them not worth the money.

What he built instead:

The cost he is pointing at is not tokens. It is the work that follows a change nobody should have made. His example: change one English string and you now owe re-translation, help docs, online documentation, and a layout check in every language, "which one AI coding agent may or may not understand to do."

The line to keep: "There’s going to be more review churn and there’s going to be more regressions and there’s going to be more AI budget spent on work that should never have been automated and done in the first place."

And the cheapest filter of all costs nothing. A senior engineer can dismiss a high-risk, low-value backlog item in seconds, which beats an agent attempting it for an hour.

Right fit: you are running agents against a backlog in bulk.

Skip the tooling when: your team is small enough that one experienced person can triage the queue by eye, which is the same control at lower cost.

5. Swap prompt-level pleading for deterministic guardrails

Two sources arrived at this independently, which is why it earns a place.

A practitioner on a public engineering roundtable described trying to stop his model from generating generic exception handlers. He tried prompting. It failed. "I was trying everything to get my LLM to stop doing this, to stop producing it, and in the end the first thing that was really efficient was to have like a manual script that would point it out." A linter wired into a write-time hook rejects the edit before the agent can iterate on it.

Prisma's file-accounting rule is the same shape: the agent cannot declare itself finished while a changed file is unaccounted for, and until the deterministic check passes, "we don’t let it move forward."

The cost mechanism: every prompt-level attempt to control behaviour is a round trip you pay for, and it works probabilistically. A deterministic check costs nothing per run and works every time. On a multi-step agent workflow, that difference compounds.

The best reframe in this entire research set came from the same roundtable, and it changes how you should read your AI bill:

"It was just as important for humans, except the cost was hidden in salary where now you’re getting hit with a bill and the cost is obvious."

Badly structured code always cost money. Under per-token billing it stops being absorbed into headcount and starts appearing on an invoice, because a disorganised repository inflates the context an agent must load to do anything. He extends it past the code itself: you now architect your skills, agent definitions and config files for context efficiency too.

AI spend did not create that cost. It itemised it.

Right fit: a repeatable behaviour you keep trying to prompt away.

Skip it when: the rule is genuinely a judgement call, where a hard check will produce false rejections that cost more than the behaviour did.

What else is worth doing, in less time than the five above?

These came up repeatedly and are cheap to implement, but none of them carries a named team with a measured result, so they sit here rather than in the list.

What usually works, and which savings quietly reverse?

Across every source in this research, three patterns hold.

The biggest savings come from not running the workload, not from running it cheaper. Four of the five approaches above are selection mechanisms: which people get access, which model gets the call, which tool you own, which work reaches an agent. Only the guardrail one is about execution. Token-level efficiency is real and it is second-order.

Visibility is necessary and it is not a control. 98% track, 11% forecast. Booking.com's dashboards were step one of five, and the four steps after them are where the curve bent. A dashboard with no approval gate, no expiry and no named owner changes nobody's behaviour.

The savings that reverse share one signature: they were measured on the wrong boundary. Three examples from this set, all first-hand. Prisma abandoned a code review agent on cost before rebuilding it successfully, because the first version was naive about context construction. Troy Magennis nearly recommended emptying a backlog into an agent overnight, which would have bought throughput on work with no value.

BCG's position, from their July 2026 article on cost reduction programmes, is that copilots layered onto existing workflows deliver modest cost impact, because the process is unchanged and the tool is additive.

The Faros AI and McKinsey telemetry study puts a name to what that feels like at scale. Their term is acceleration whiplash: throughput rises while quality falls. Martin Harrysson, a senior partner at McKinsey, frames the cost that never reaches the AI invoice: "We’re sort of paying a bit of a downstream tax, where our ability to review code that comes out, our ability to validate it, our sophistication in how to write evals, has not kept up in the same pace."

A saving that moves work from a metered bill into an unmetered review queue is not a saving. It is a transfer.

How do you know a saving is real?

Four things to put in place before you change anything, drawn from what the teams above did in sequence.

Where does ML.ai fit into this?

Most of the five approaches above exist because the billing unit moved to the token and someone has to manage the variance. That is a standing engineering cost on top of the product you were trying to build.

ML.ai takes a different position on the same problem: one flat price, and no token counter to watch. Set against a survey where 98% of organisations track AI costs and 11% can forecast them within 10%, a predictable number is the thing that was missing, not another chart.

Underneath that, several of the techniques above are handled rather than configured. It reads your repository and picks a model for each step rather than sending every call to one tier, which is approach 2 applied per step instead of per route. Work runs in parallel jobs, each in its own sandbox, the isolation that made Prisma's agent affordable.

Reasoning effort is a five-level dial set per message, so the expensive setting applies to the design step and not the twenty mechanical steps after it. Nothing writes to disk until you approve a diff, which keeps the deterministic gate from approach 5 in front of every change.

Two details are worth naming because they address the measurement problem directly rather than the cost one. A context meter reports usage against the model’s limit and turns amber at 65% and red at 85%, so a session that is about to produce expensive, drifting output is visible before it does. And anything trimmed before it reaches the model is marked as trimmed, never silently dropped, which is the same class of problem as a cost report that quietly excludes agentic workloads: what you cannot see, you cannot price.

Team-level instructions and reusable skills live in the repository, which is where the roundtable's point lands. If context efficiency is now a cost input, the files that shape your agents belong under version control with everything else.

What to do Next?

You now have five approaches with the teams behind them, the dates your billing model changed, and the two savings in this set that reversed on the people who tried them.

Start with the cheapest check here: open your AI cost report and see whether it includes your data platform, your vector store and your AI coding tools. For most organisations, it does not, which means the single largest source of unexpected cost is outside the number everyone is looking at. That audit takes an afternoon and tells you which of the five approaches is even relevant to you.

Then pick one, and change one thing at a time. If you would rather not spend the next two quarters building variance management around a metered bill, that is the problem ML.ai is built to remove.

Frequently Asked Questions

How much should we budget for AI tools per developer in 2026?

Published figures cluster between $500 and $3,000 per developer per year. In a poll of 275 engineering leaders reported by DX, 38.4% spent $101 to $500 per developer per year on AI developer tools in 2025, 10.5% spent $501 to $1,000, and another 10.5% spent over $1,000. DX's CTO Laura Tacho expects the common $1,000 target to rise during 2026. Nearly half of the 50 budget holders DX surveyed set aside 1% to 3% of total engineering budget for AI tools.

What is the biggest source of unexpected AI cost?

Data platform usage overages, cited by 47% of 396 organisations surveyed in April and May 2026, ahead of LLM token costs at 43%. Most AI cost-reduction advice targets the second item. If your warehouse queries, retrieval layer and vector store sit outside your AI cost report, your largest surprise is one you cannot currently see.

Will AI costs come down on their own if we wait?

The people building on these models disagree, and the disagreement is worth knowing. Prisma’s team argue tokens are becoming a commodity, "increasing in value and decreasing in price." A software architect at the Israel Tax Authority argues the opposite, that current prices are land-grab pricing and will rise. Planning for either is a bet. Planning so that a price move in either direction is survivable is not.

Should we consolidate onto one AI vendor to cut costs?

Consolidation is the standard cost advice and this is one category where it is contested. DX found 86% of engineering leaders uncertain which tools deliver the most benefit, and argues multi-vendor AI tooling is a deliberate exception to the usual rule, because no single vendor leads across code authoring, review, debugging and planning. Weigh the discount against being locked to one vendor’s roadmap while the category is still moving.

Is building our own AI tool cheaper than buying one?

Sometimes, and the deciding factor is blast radius rather than price. Prisma replaced a paid code review tool with an internal agent, and their stated test was that an outage of it "is not going to be the most disruptive thing in the world." They had also abandoned an earlier attempt at the same build on cost. Narrow job, deterministic definition of done, survivable downtime: those three together make it rational.

Does cutting AI spend hurt developer productivity?

It depends on which lever you pull. Access tiers, model routing and work selection reduce spend without touching the quality of the work that does run. Compaction, aggressive context trimming and downgrading models on hard tasks all trade quality for cost, and need an evaluation set behind them. The failure to watch for is a saving that moves work into an unmeasured review queue, which shows up as a lower bill and a slower team.