In June 2026, Gartner predicted that by 2028, AI coding costs will overtake the average developer’s salary. The drivers are rising token consumption and the shift from seat-based to consumption-based pricing. 

For me, the more important point in that announcement is a different one. According to Gartner, token discipline won’t emerge from developers’ own choices, because developers optimize for speed and convenience rather than cost. I agree, and not because developers are careless. In most setups, nobody can see what the work actually costs. 

So the useful question isn’t “how much AI budget do we need?” It’s “can we see and steer what we spend?” We’ve spent the past year building our answer to the second question. This article walks through the four building blocks we use today and the decision behind each one that every organization has to make for itself. 

Why a budget number alone won’t help

If you have no data at all, you need a starting point. Mine is around €200 per developer per month. We calculated it a year ago, and as top models have become more expensive, it drifts upward rather than down. It sits at the lower end of what the market reports: Gartner Peer Insights found that 23% of tech leaders already spend $200 to $500 per developer per month on tokens for coding agents, and Anthropic puts enterprise Claude Code usage at $150 to $250 per month. 

But the number is the least interesting part. Consumption is highly individual. It depends on your codebase, your process, and your people, so an average tells you very little about any specific team. 

What happens without visibility is well documented. Microsoft gave engineers in one division access to Claude Code in December 2025 and canceled most licenses by June 2026, after token billing had consumed the annual budget well ahead of schedule. Uber reported its average monthly AI tool cost at $150–$250 per engineer, with heavy users reaching $500–$2,000 before caps. In both cases, the tool worked. That was the problem: people used it heavily, and nobody saw it until the invoice arrived.  

At the same time, providers are moving to consumption-based billing. GitHub, for example, switched every Copilot plan to usage-based billing in June 2026. Flat-rate subscriptions are no way out either, because they don’t scale to enterprise headcounts: Anthropic’s Team plan caps at 150 seats.  

Four building blocks for visible and controllable AI costs

1. An independent AI gateway

The first decision is how you buy. You can sign an enterprise plan with a single provider. But you can also place an independent AI gateway in front of several providers and manage access, budgets and metering at the infrastructure layer. 

We deliberately chose the gateway. Enterprise pricing is usually just API rates minus a volume discount, so the real reason is positioning: in recent months, frontier releases from three or four vendors have each briefly led either in terms of cost or performance. The gateway sits between our tools and all providers. Developers get project keys instead of provider accounts, every request is logged by project, person, and model, and switching models needs no new contract. 

It also opens up an option that a single-provider contract keeps closed: models on our own hardware. Running a top-tier model on-premise is still expensive. With around €35,000 of GPUs, we can serve an Opus-class model for a single session. What works in practice is an efficient open-weight model: DeepSeek V4 Flash runs entirely on our hardware at roughly Sonnet level for around 50 parallel users. No provider receives any data, which makes AI-assisted work possible on projects where clients don’t permit external providers. 

Gartner sees the same shift. In its Market Guide for AI Gateways, it expects 70% of software engineering teams building multi-model applications to use AI gateways by 2028, up from 25% in 2025. 

Diagram showing the Gateway infrastructure, with multiple Coding tools going into the Gateway and multiple AI providers going out

2. Token tracking and budgets per project

The second decision is where the budget sits. The usual instinct is to centralize. We keep only what needs an overview at the center: which models are available, how much training is needed, whether to invest in hardware. Whether a usage pattern is worth it can only be judged within the project. 

So, every request through the gateway is assigned to a project via a project key, and the project lead sees consumption by person and model. The lead distributes budget by seniority and, above all, by responsibility. The architect accountable for success uses what they judge necessary. People who are still learning these tools, including many experienced developers, can spend a lot quickly with little to show for it. 

This also reframes the ROI question from “how much do we need?” to “how much can this project carry?” Like any investment, AI spend should be justified by what it returns, and that’s only possible where cost and outcome are visible side by side. 

Limits do get hit. The most extreme case I’ve seen was someone using their individual AI budget with a frontier model. They got an excellent result, and the budget was gone within half an hour. That isn’t misuse; it’s what real work costs.  

We don’t quietly top people up because everyone should have the same baseline. If there’s a business reason for more, the cost goes onto a project, where it can be reviewed. For private use, employees can buy personal subscriptions through their individual R&D budget.  

3. Model choice that fits the task

Once consumption was visible in our gateway, the first finding was clear: we used far too much Opus. As one of the stronger models available, it becomes the default. But frontier models earn their cost in planning and working out an approach. Implementation and simpler tasks can be handled by smaller models with a very good success rate. 

The second finding concerns how people work. Language models are stateless. Every message sends the entire preceding conversation back to the provider, and you pay for all of it. Cached content is cheaper, currently 10% of the input rate at Anthropic, but 10% of a very large number is still quite a number. Long sessions with many small messages mean paying again and again for context that stopped being useful long ago. Fewer, larger requests beat many small ones, and long sessions should be reset rather than extended. 

Both are behavioral fixes, not technical ones. And neither is possible without visibility. Gartner’s recommendations match this almost exactly: route simpler, high-frequency tasks to smaller models. Reserve frontier models for complex work, and make context engineering a mandatory practice. 

4. Agents in an isolated environment

The fourth decision is which risks you accept. Coding agents don’t just suggest code. They execute commands and change files. You can put an agent on a laptop and let it run, and many organizations do. In my view, it’s then only a matter of time until something goes wrong: a deleted directory or an action nobody intended. 

That’s why our agents run in a standardized container. It only sees the project folder it was given, and its network access is limited to the gateway. It can’t damage the machine. There is, of course, a trade-off: teams outside engineering need a developer’s help to set it up. We accept that because the alternative is hoping nothing will happen. The same logic applies to people. Training is a prerequisite for access with us, not something that follows it. 

Two office workers chatting while a humanoid robot works

Gartner’s analysis supports drawing the boundary around the agent itself. In its Market Guide for Guardian Agents, it expects that through 2028, at least 80% of unauthorized AI agent transactions will stem from internal policy violations, oversharing or misguided AI behavior rather than from malicious attacks. In other words, you shouldn’t be afraid of an outside attack as much as your own agent doing what it was told, in a way nobody expected. 

Where to start 

  • This month: find out what your teams actually consume. If you can’t, that’s your first finding. 
  • Before you set a number: decide how you buy: a single provider’s enterprise plan or provider-independent metering through a gateway. 
  • When you set a number: start around €200 per developer per month, assign it to projects and let project leads distribute it. 
  • Continuously: watch model mix and session length, and isolate agents before you scale them. 

The organizations that handle this well will need more than just guesseing the right number. They’ll be the ones that can keep answering the question as the number changes. 

How Cloudflight can help 

Gateway, project-level metering, model choice, and agent isolation aren’t only concepts for us. They’re how we deliver software today. If you want to give your engineering teams AI capability without discovering the cost in a quarterly review, the conversation starts with your architecture, not your budget line. 

Talk to us about AI-assisted software engineering.