Agentic Coding: Rent the Cloud or Own the Hardware?

Authors: Dušan Šalović, Ole Peters

|

4.11.2026

What happens when a year’s AI coding budget is gone in four months? It happened at Uber. Since June 2026, metered pricing has spread across everyday engineering tools and coding agents keep pushing the bill up. Meanwhile, open models handle most routine work on a desktop machine. So: rent by the token or own? Read on for the numbers, the limits and where local hardware pays off.

Uber gave its engineers AI coding agents and encouraged them to use them. They did. Within four months, the AI coding budget for the whole of 2026 was gone. Uber’s answer was a cap: $1,500 per employee per month.

It is easy to read that as a story about one company that planned badly. Then came June 2026. In June, GitHub Copilot switched from a flat fee to usage-based billing and one developer watched a $29 bill turn into $750. Other vendors followed.  In the same month, Gartner predicted that AI coding costs will pass the average developer’s salary by 2028.

All of this is a consequence of success. Agentic coding works. Nutanix calls it the “killer app” of enterprise AI and, in the same breath, its greatest expense. Agent use among developers almost doubled in a year, from 31% to 59%.

So the question has changed. Whether coding agents are worth using is largely settled. The open question is who should own the machine they run on.

Why the bill keeps growing – 3 drivers

There is no single reason for the growing bill. Evidence from Accenture, Gartner and emerging research on multi-agent software engineering systems suggests that three trends are converging at the same time.

  1. Agents reread everything
    A coding agent works in a loop: it reads the code, changes something, runs the tests, reads the failure and tries again. Each step reloads its full context and in large codebases that context is huge. In a study Accenture published in September, 98.1% of the input tokens in agent-heavy work were context the agent had already read.
  2. Usage is not yet optimised
    Much of today's consumption is waste. An agent with a vague task or too much irrelevant context circles until it works out what to do. In the Accenture data, corrections and rework made up more than a third of the spend. Gartner advises training developers to give agents only the context they need and warns that this discipline "will not emerge through developer choice alone". This is a transition phase and consumption per task can be expected to fall as engineers gain practice.
  3. The work itself is getting bigger
    The newest approach stacks loops into a graph of loops: every task is its own loop, often checked by a second agent whose only job is to tear the first agent’s work apart. Code gets written, checked, rejected and rewritten several times before a human looks at it.

Today’s heavy users are tomorrow’s average

The second driver will shrink as teams learn. The first and third will not. And learning takes practice, which is expensive when every practice run is billed. Today the spend is still uneven.

  • Average Claude Code user: $150 to $250 a month.
  • Accenture's modelled enterprise engineer: about $800 a month.
  • Uber's heaviest users: up to $2,000 a month.

The direction is the same everywhere. Token consumption per developer rose 18.6 times in nine months. Better habits will save tokens per task, but the number and size of tasks are growing faster. On this trend, the heavy usage of today becomes the normal usage of tomorrow.

A spending cap is the usual response. Its side effect is that engineers are stopped at the moment they are learning to use agents well.

Open models catch up, hardware requirements shrink

While the bills were climbing, two other things happened.

The first is a model. In August, Alibaba released Qwen3.8-27B with open weights, which means anyone can download it and run it on their own hardware. It is small enough to run on a single desktop machine and it is tuned for coding and agent work. It serves as the example here. The argument does not depend on this one model.

Open models have been closing in on the frontier, the most capable models available, with every release, and Qwen3.8-27B shows how fast. Its predecessor of the same size, released in April, scored 53.5 on SWE-bench Pro, a standard test built from real software engineering tasks. Four months later, Qwen3.8-27B scores 61.7. That puts it ahead of the 53.4 that Alibaba lists for Claude Opus 4.6, a frontier model from earlier this year.

89.9

Claude Opus 5.5

61.7

Qwen3.8-27B

53.4

Claude Opus 4.6

Scores

A score of 61.7 means the model resolves about six in ten of the benchmark’s real-world engineering tasks on its own. On this benchmark, a model that runs on a desk matches the best cloud model of about one generation ago. That is the threshold that matters: good enough for everyday engineering work and small enough to run locally.

Gaps remain. The scores are the vendor’s own. The frontier has also moved on, as it always does: Claude Opus 5.5, released in September, reports 89.9 on the same benchmark. The hardest problems still belong there. Routine implementation, tests, refactoring and review do not, and that is where most of the tokens go.

Desktop hardware built for local AI

The second is a box. Several vendors now sell desktop machines built to run such models. Nvidia’s DGX Spark, a 1.2 kg machine about the size of a thick paperback, is the reference here because public benchmarks for this model were run on it. On 2 October, Nvidia announced a version for $4,999 that has enough memory for this model.

In practice the setup is simple. The box sits on a desk or in a server room and engineers point their coding tool at it instead of a cloud service. The model then runs on hardware the company owns, with nothing billed per use.

It is fast enough for daily work. In tests on the larger 128 GB version, a well-configured Spark writes about 48 tokens per second with this model, faster than anyone can read and on par with what cloud providers deliver for the same model. Software is also making ordinary hardware go further: the developers of Strata, an open-source tool, report running a much larger model on a standard gaming PC.

The Spark is one machine in a new category: desktop computers that arrive with the AI software already installed. AMD sells a comparable system and Apple markets its latest Mac Studio for running large models “without counting tokens or worrying about rising cloud costs”.

More is on the way. Nvidia and Microsoft have announced RTX Spark, a class of Windows PCs built to run agents locally, with machines from Dell, HP, Lenovo and others due in autumn 2026.

“The goal is to deliver unmetered intelligence to every home and every desk”
Satya Nadella
Microsoft CEO

Three of the largest hardware vendors are now building for the same use case: capable models running on the desk, without a meter.

The maths: when does a box pay off?

When does owning agentic coding hardware pay off?

A $4,999 desktop AI machine pays for itself in about six months for an engineer with an $800 monthly token bill, in just over three months at $1,500 and in about two years at today’s average of $200. The figures assume one engineer per machine and exclude electricity and administration time. Because token consumption per developer rose 18.6 times in nine months, average bills are expected to move towards the higher cases.

One box can also be shared by several engineers, which shortens the payback. Teams that already own a workstation with a 24 GB graphics card may not need to buy anything, since a compact version of the model fits on such a card.

The meter affects how engineers work. When every loop is billed, each extra review pass is a spending decision. When the machine is already paid for, another loop costs electricity and time. An engineer can let a graph of loops run overnight, add a second reviewer agent or regenerate a module five times without the invoice moving.

The code stays in the building

Cost is half the argument. The other half is control.

With a local model, source code, prompts and agent logs stay on hardware the company owns. For regulated industries and confidential client work, a whole category of questions disappears. There is no external processor to assess and no debate about which region served a request.

Vendors are responding to that demand. On 1 October, for example, IBM announced a self-hosted version of IBM Bob, its agentic development platform, so that enterprises can keep sensitive code out of external services. IBM’s own research found that

68%
Executives struggle to meet data residency and sovereignty requirements
1%
In Germany, only 1% of companies that use AI use Qwen, according to Bitkom.

The origin of a model can raise concerns. With a hosted AI service from any country, the concern is where the data goes. A downloaded model on an offline machine sends data nowhere. What it writes still needs the same review, tests and scans as any other agent output.

The catch

Two things could get in the way.

The first is regulation. Open models are the subject of a policy dispute. In September 2026, Anthropic published a report alleging that seven Chinese labs used Claude’s outputs at industrial scale to train their own models, with Alibaba, the maker of Qwen, among those named. The US Treasury Secretary has said that sanctions are on the table. Other parts of the industry disagree: in July 2026, Nvidia led an open letter urging Washington not to restrict downloadable models, signed by Microsoft, Meta, Dell and IBM.

How the dispute ends is open. Published weights cannot be recalled, but the rules for using them could change. That makes it sensible to treat the model as a replaceable part.

The second is that a box has limits.

  • Quality
    The local model is about a generation behind the frontier. The hardest design problems still belong in the cloud.
  • Capacity
    One box can only do so much at once. Each request slows down as more run in parallel: with eight at a time, speed fell by about 40% in tests.
  • Operations
    Someone has to configure it, patch it and secure it. In tests, the same machine ran several times faster once it was properly configured. That load may fall as agents become able to manage the setup themselves.

What this means for your team

None of this argues for leaving the cloud. It argues for splitting the work.

  • Keep the cloud for what is unpredictable
    Customer-facing applications, sudden peaks and shared services are what per-token pricing is good at.
  • Own the capacity for coding
    It is steady, heavy and confidential. Start with the engineers who use agents most and plan for the whole team.
  • Route by difficulty
    Routine loops run locally. The hardest problems go to the best model available, at a fraction of today's volume.
  • Keep the model replaceable
    A routing layer between agents and models, such as the open-source LiteLLM, lets agents call a model by name while the router decides whether the request goes to the local box or a cloud endpoint. If one model becomes unavailable or unwelcome, the next one takes its place without a rebuild.
  • Run a pilot
    A few machines, one team, three months, measured against the current token bill.

When a new engineer joins a company today, they get a laptop and a monitor. A third item may soon join that list: access to a machine that runs their agents, on their desk or in a rack down the hall.

The reason is ordinary. Once a cost becomes large, steady and predictable, companies stop renting and start owning. Agentic coding has reached that point for its heaviest users. Usage across the rest of the profession is moving the same way.

Rent or own? Split the work

Own the capacity for routine coding and rent it for the hardest problems. Start small: one box, your heaviest agent users, routine loops routed locally and frontier models kept for the hard cases. After three months, the invoice will tell you whether it pays off.

About the Authors

Ole Peters is a Senior Data & AI Engineer at IBM iX DACH, working on AI agents, LLM applications, RAG systems and data-driven risk analytics for international clients. He comes from (laser-)physics, is a developer at heart and enjoys taking a use case from concept to production. In his free time he follows where the agent world is heading, from MCP servers to autonomous AI Agents.

Ole Peters
Senior Data & AI Engineer

Dušan Šalović is a Senior Data Scientist at IBM iX, specialising in generative and agentic AI. He supports large enterprises across retail, e-commerce, consumer goods and pharma in designing and delivering AI-driven transformation, from strategic prioritisation to scalable implementation. With expertise spanning advanced AI architectures, cloud platforms and enterprise integrations, Dusan helps organisations turn emerging technologies into tangible business impact. At IBM iX, he also contributes to the development of new offerings in Agentic AI and mentor teams on applied AI excellence.

Dušan Šalović
Senior Data Scientist

This might also interest you