The AI Hardware Reckoning: What Would It Take to Challenge Our Anthropic Spend?

Challenging enterprise Anthropic spend requires cutting per token inference costs through dedicated or on premise AI hardware, model distillation, and aggressive caching, while enforcing usage governance across agents and users. Meaningful savings demand negotiating volume based contracts, benchmarking alternative model providers, and optimizing prompt and context length so autonomous agents consume fewer tokens without sacrificing accuracy, speed, or the reliability enterprises depend on daily.

Enterprises are discovering that generative AI does not behave like conventional software licensing. The first few hundred users are cheap, the early pilots are easy to approve, and even a capable coding agent looks trivial when its monthly cost sits next to a developer salary. The economics change once AI stops being a pilot and becomes part of the operating model.

Picture a company with more than ten thousand employees, roughly half of whom use AI regularly. Developers run coding agents all day, analysts submit large documents, operations teams use AI to investigate failures, and client facing staff ask for immediate help while a customer is on the line. Autonomous agents retrieve information, call tools, review the results, and repeat the cycle until the task closes.

At that point the company is no longer buying a set of chatbots. It is buying an increasingly load bearing piece of its cognitive infrastructure, and it is paying for that infrastructure one token at a time.

The obvious question is whether to keep sending almost every request to Anthropic, or to buy hardware and run open weight models internally. The honest answer depends on far more than the monthly token bill. It depends on concurrency, latency, context size, model quality, utilisation, resilience, and the cost of the people required to run the platform.

Most importantly, this is a real time problem. In a heavily AI enabled enterprise, something like 99% of useful AI demand is interactive or near enough to it that a person or a production process is sitting there waiting. Batch work can soak up unused capacity overnight, but it does not meaningfully reduce the hardware you need at half past ten on a Monday morning.

So the right question is not whether an enterprise can reproduce Claude, since it cannot reproduce a frontier model and the research organisation behind it merely by buying graphics cards. The commercially useful question is narrower than that.

How much of the Anthropic bill is paying for frontier capability the task does not actually require, and how much of that demand could be served internally without making people slower or the output worse?

1. The company we are modelling

Working model, close to what I see in practice:

Before anyone signs a purchase order for GPUs, get at least 60 to 90 days of Anthropic telemetry, broken down by user and department, application and agent, model, input and output and cache read tokens, request arrival time, context length, output length, time to first token, total response time, tool call count, agent iterations and retries, and cost per completed business task.

Monthly token volume tells you the external bill, while peak concurrent demand tells you the internal hardware requirement, and confusing those two numbers is the fastest way to build a business case that quietly falls apart in front of the board.

2. Why almost all enterprise AI is real time

“Interactive” should not be limited to someone watching words stream into a chat window. A workload is real time whenever a person or a production process is waiting on it.

A coding agent that takes four minutes to inspect a repository, edit files, and run tests is still real time, in the same way that a fraud investigator waiting thirty seconds for a case summary is using a real time service, and an operational agent reviewing logs during an outage is part of a real time incident response. A client facing employee cannot tell a customer the answer will arrive in the overnight batch.

For this enterprise, a sensible planning assumption is that roughly 99% of valuable demand is real time or near enough to it. The small residual might include model evaluation, synthetic data generation, bulk embedding refreshes, historical document enrichment, repository indexing, large scale test generation, offline migration work, and non urgent historical analysis. Those jobs improve utilisation outside peak hours. They do not determine how many GPUs you need at ten in the morning.

The platform instead has to be designed around peak concurrent sessions, prompt ingestion speed, time to first token, sustained output speed, long context behaviour, agent tool call cycles, traffic bursts, model upgrades, hardware failures, disaster recovery, and immediate external overflow.

This changes the economics materially. An API provider charges for consumed tokens and carries most of the spare capacity risk itself. An enterprise buying hardware has to fund capacity for expected peaks, failures, and growth, even while most of it sits idle overnight.

3. Establishing our own baseline

Rather than reverse engineer the bill from assumed token volumes, I have used our actual blended spend. Normal, non developer users average around 40 US dollars per person per month. That already reflects real usage patterns rather than a synthetic estimate.

At 5,000 regular users, ordinary usage alone runs at roughly 2.4 million dollars a year. That is already a meaningful line item, but on its own it still does not obviously justify a production inference estate once staffing, resilience, power, and depreciation are added to the comparison. The picture changes once developers enter the calculation.

4. Developers dominate the bill, and the average hides the real story

Our developer spend averages around 400 US dollars per developer per month, roughly ten times the normal user figure. But the ceiling is far higher again. Our heaviest individual developer months peak at around 10,000 US dollars per developer, twenty five times the average and two hundred and fifty times a normal user.

That gap matters more than the average does. An average of 400 dollars is not evenly distributed across the developer population. It is the result of a small number of developers running agents almost continuously against large repositories, alongside a much larger group whose spend is modest. If, say, 5% of a thousand strong developer population were running near their peak in a given month, that alone could be:

50 developers × $10,000 = $500,000

against the remaining 950 developers at average:

950 developers × $400 = $380,000

giving a combined monthly bill of $880,000, more than double what the blended average of 400 dollars would suggest for that population. The bill is driven by the tail, not the median developer. This is the same shape you see in most consumption based infrastructure cost, and it is exactly why an average figure on its own is a poor basis for a hardware business case. You need the distribution, not just the mean.

For planning purposes, the table below uses the blended average of 400 dollars per developer per month, which already incorporates that tail, since it is derived from actual telemetry rather than an assumed uniform rate.

A company can find that a thousand or two thousand developers generate more Anthropic spend than several thousand ordinary users combined. That is not automatically waste. Research on a large early 2026 rollout at Microsoft associated adoption of command line coding agents with roughly 24% more merged pull requests, although a merged pull request is a proxy for productive value and does not capture quality or commercial impact on its own.

The correct response is not to cap every developer until the number feels comfortable. It is to work out which coding tasks genuinely require Claude and which could be served by something considerably cheaper.

5. Why coding consumes so many tokens

A conventional chatbot receives one question and produces one answer. A coding agent runs a chain of related activity: reading repository instructions, inspecting project structure, searching for symbols, reading implementation files and tests, inspecting build configuration, generating a change, running the build, reading the output, revising, running tests again, reviewing the diff, and producing a final explanation.

The developer experiences one task, while the model may process hundreds of thousands, sometimes millions, of tokens across many turns to get there. Coding agents also create concurrency of their own. A developer might run an interactive agent in the terminal while another reviews a pull request and continuous integration kicks off a third. Each developer effectively comes with several virtual engineering assistants attached, all drawing on model capacity. Coding traffic is expensive, bursty, and unforgiving on latency.

6. Why coding is still the easiest workload to move

Despite the cost, coding is the most credible first target for open weight models, for four reasons.

Generated code can be validated, compiled, type checked, linted, unit tested, security scanned, benchmarked, and reviewed through a pull request. Natural language advice can sound convincing while being wrong, but code has a surrounding system that catches a good proportion of failures automatically.

Much of the work is structurally repetitive: generating unit tests, writing documentation, explaining unfamiliar code, producing boilerplate, mechanical refactoring, dependency updates, format fixes, migration scripts, pull request summaries, repository search, and translation between similar languages or frameworks. None of that inherently requires the strongest model available.

Developers understand escalation, and showing a developer that an internal model attempted the task, failed validation, and handed off to Claude is a far more transparent experience than silently swapping the model under every employee without explanation.

The workload is measurable, and you can track whether the build passed, whether the tests passed, whether the change was accepted, how many human edits it took, how long the developer waited, how often the task escalated, and the total cost per completed task. That gives you cost per successful outcome rather than cost per token, which is the only comparison that actually matters.

7. What should move away from Claude

Not a single open model taking everything, but a portfolio routed by task.

The objective is not to remove Anthropic from the stack. It is to stop paying frontier model prices for tasks that never needed frontier model capability in the first place.

8. Throughput is not the same as user capacity

Hardware sizing conversations tend to quote tokens per second as though it were a fixed property of a GPU, when it is not, since inference performance depends on model size and architecture, quantisation, prompt length, output length, batch size, concurrent sequence count, key value cache size, speculative decoding, prefix caching, inter GPU communication, serving software, and the latency target you have set yourself.

Prompt processing and output generation behave differently too. A coding agent might submit a hundred thousand token context and ask for five hundred tokens back. Another user might submit a short question and expect a long answer. Both consume resources in different shapes. You have to benchmark the actual models against representative workloads. Public benchmarks are fine for shortlisting, but they are not sufficient for procurement.

9. A real time concurrency model

Take 5,000 AI users. At peak, perhaps 20% are actively engaged with an AI application, giving 1,000 active sessions. Of those, perhaps 20% are generating output at any given instant, giving 200 simultaneous generation streams. Each stream needs roughly 25 output tokens per second.

200 streams × 25 tokens per second = 5,000 output tokens per second

That excludes prompt ingestion, cache movement, agent retries, routing, and operational headroom.

A developer environment is more demanding again. With 1,500 developers, 50% using coding agents during a busy period, and 25% of those with an agent actively waiting on inference at any instant, you get roughly 188 active generation streams. At 30 output tokens per second each:

188 streams × 30 tokens per second ≈ 5,640 output tokens per second

An agent can tolerate a task taking several minutes. It cannot tolerate a long delay between every model turn. A fifteen second scheduling delay repeated across thirty turns adds seven and a half minutes to a task the developer expected to take moments. The service has to be measured on aggregate throughput and on tail latency together.

10. Why real time systems need spare capacity

You cannot run an internal cluster at 95% utilisation and still deliver a good interactive experience. As utilisation approaches the system’s limit, queues grow fast. A modest traffic increase, one failed node, or one unusually large prompt can push latency out across the whole platform.

A production service should assume normal peak utilisation well below the technical ceiling, hardware failure, model upgrades, rolling deployments, traffic bursts, long context requests, sudden agent loops, new application launches, disaster recovery, and demand growth across the life of the hardware. Depending on how variable the workload is and how strict the latency target is, targeting 50% to 70% utilisation at expected peak is a reasonable starting point. The rest is not waste so much as what keeps the service usable when demand is slightly higher than forecast, which it always eventually is.

This is one of the most important differences between an Anthropic bill and owned infrastructure. Anthropic monetises shared capacity across many customers, whereas we would be funding our own headroom alone.

11. Consumer grade hardware: the RTX 5090 approach

NVIDIA’s GeForce RTX 5090 carries 32 GB of GDDR7 memory and an official starting price of 1,999 US dollars, with a reference power draw around 575 watts before you add the rest of the system. Its price relative to memory bandwidth and compute makes it genuinely attractive for inference, provided you treat it as an inexpensive inference worker rather than a cheap substitute for an enterprise eight GPU server.

An indicative four GPU consumer node: four RTX 5090 cards giving 128 GB of aggregate GPU memory, 32 to 64 modern CPU cores, 512 GB of system memory (preferably ECC), two enterprise NVMe drives, 25 GbE networking at minimum, roughly 2.5 to 3.5 kW of power draw for the complete node, high airflow or properly engineered liquid cooling, enterprise Linux, and a serving layer such as vLLM or SGLang. Indicative cost, around 20,000 to 35,000 US dollars per node, which is an illustrative planning figure rather than a quote.

The best deployment pattern is usually independent models or replicas per GPU rather than one model spread across all four. A larger model can be split across two or four cards, but the communication has to travel over PCI Express, since consumer cards do not carry the NVLink and NVSwitch fabric used in data centre systems. The consumer estate favours models that fit on one GPU, or at most two, rather than chasing the largest model the aggregate memory could theoretically hold.

On 32 GB, a 7 billion parameter model needs about 14 GB at 16 bit precision or 3.5 GB at 4 bit. A 32 billion parameter model needs about 64 GB at 16 bit, 32 GB at 8 bit, or 16 GB at 4 bit. A nominal 32 billion parameter model at 8 bit is already tight on a single card once runtime overhead and key value cache are accounted for, while the 4 bit version leaves more room for context. Long context coding workloads eat cache memory fast, so a model that copes fine with short prompts may support far fewer concurrent users once repositories and tool histories grow.

Indicative consumer cluster sizes:

A 48 node estate drawing roughly 3 kW per node consumes around 144 kW for inference servers alone, before networking, storage, and cooling losses push facility demand higher still. This is not a room full of desktops so much as a small data centre service, and it needs to be resourced like one.

12. Advantages and limitations of consumer hardware

The advantages are real: low acquisition cost, strong performance per dollar, fast experimentation, cheap replication of small and medium models, easy allocation of dedicated capacity, limited exposure during a pilot, and straightforward horizontal scaling. For coding, a fleet of inexpensive independent workers can outperform one large tightly coupled model on cost per completed task.

The limitations are equally real, and they show up after the pilot, not during it. Large consumer cards take up several expansion slots and use coolers built for workstations, so fitting four into a rack server needs specialised chassis design. Four high power cards generate well over two kilowatts of GPU heat before the rest of the node is counted, and a rig that survives a benchmark is not automatically fit for continuous production. PCI Express is fine for independent replicas but a poor fit for a model that has to synchronise across four cards on every token. Retail and workstation warranties are not four hour data centre support. Card designs, firmware, and suppliers vary across procurement cycles, making a uniform fleet hard to maintain. Consumer cards offer fewer options for partitioning, virtualisation, telemetry, and certified multi tenant operation. And the business ends up owning the drivers, serving stack, model upgrades, quantisation, capacity management, observability, security, and incident response that a managed API quietly absorbs today.

Consumer hardware is cheap because a lot of enterprise responsibility stays with the buyer.

13. Enterprise grade hardware: the H200 class approach

NVIDIA’s H200 carries 141 GB of HBM3e memory and roughly 4.8 TB per second of memory bandwidth, offered in certified four and eight GPU systems, with DGX and HGX platforms using high speed GPU interconnect built for tightly coupled workloads. An eight GPU H200 class system gives 1,128 GB of aggregate GPU memory, much higher bandwidth per GPU, enterprise interconnect, large key value cache capacity, proper cooling, enterprise management, redundant components, predictable rack integration, and vendor support.

Indicative enterprise node: eight H200 GPUs at 141 GB each, NVLink and NVSwitch interconnect, dual enterprise server CPUs, 2 to 4 TB of system memory, redundant enterprise NVMe, 200 or 400 GbE or InfiniBand, roughly 8 to 12 kW of system power, and enterprise management tooling. Indicative acquisition cost, around 300,000 to 500,000 US dollars, again a planning figure rather than a quote.

The interconnect matters when one model spans several GPUs, when the model runs into the hundreds of billions of parameters, when contexts are very large, when large caches need to stay resident, and when the platform serves many simultaneous users with a predictable latency target. For small models running as independent replicas, the expensive interconnect buys comparatively little, though for large models it can be decisive.

Indicative enterprise cluster sizes:

None of this includes high speed switching, shared storage, racks, power distribution, cooling upgrades, disaster recovery capacity, implementation services, software subscriptions, support contracts, or platform staffing. The enterprise system costs more, but you are buying operational certainty as well as compute.

14. Consumer versus enterprise hardware

The consumer cluster wins when the model fits on one card and the workload scales through replicas, while enterprise hardware wins when many GPUs need to behave as one coherent machine.

15. The developer only business case, run against our real numbers

At 2,000 developers averaging 400 dollars a month, our annual Anthropic developer spend sits around 9.6 million dollars, before allowing for the tail effect described in section 4, which can push the effective figure meaningfully higher in any given month.

Assume an internal platform can safely serve 70% of coding work, with the remaining 30% staying on Claude because it is complex, high risk, or beyond the internal model’s confidence threshold.

None of this is savings on its own, since internal infrastructure, people, and power still have to come off the top. It establishes the maximum available pool, which at our developer numbers is considerably larger than the source assumptions this kind of analysis usually starts from.

A consumer developer platform, built as 24 four GPU nodes (96 GPUs, several small or medium coding models, separate interactive and autonomous agent queues, at least 20% operational reserve, Claude overflow, and a second site for disaster recovery), lands in the range of 950,000 to 1.69 million dollars once networking, storage, spares, and facility work are included. Against a 9.6 million dollar annual developer bill, displacing even a portion of that spend recovers the capital outlay quickly, provided the internal model holds up on quality and speed once staffing, power, and remaining Anthropic usage are added back in.

An enterprise developer platform, four H200 class nodes (32 enterprise GPUs, roughly 4.5 TB of GPU memory, high speed interconnect, and formal support), lands in the range of 1.5 to 3 million dollars fully built. Against the same bill, this remains financially credible, and it produces fewer operational surprises than the consumer route, at the cost of a slower procurement cycle and a higher entry price.

16. Latency can quietly destroy the savings

A cheaper model is not cheaper if it wastes developer time. If a coding task needs thirty model turns and the internal service adds five seconds of avoidable delay per turn, the developer loses two and a half minutes. If congestion adds twenty seconds per turn, the task takes ten minutes longer than it should. Across two thousand developers, a small daily productivity loss can exceed the entire API bill without anyone noticing until the complaints start.

The business case has to measure time to first token, prompt processing time, tokens per second, queue delay, end to end task duration, number of attempts, developer intervention, test failures, code defects, escalation rate, and cost per accepted change. A local model that costs half as much but needs twice as many attempts is not cheaper. A local model that quietly introduces production defects is catastrophically expensive, and the invoice for that arrives much later than the GPU invoice does.

Early research comparing a proprietary coding agent with an on premises open model found a genuinely mixed picture: local inference reduced infrastructure cost in some shared utilisation scenarios, but the local configuration was also associated with a higher defect repair burden and more developer time lost to debugging. The study was small and not randomised, but it makes the point well: token price alone is not an adequate metric.

17. The router matters more than the GPU

The key asset here is not the internal model. It is the gateway that decides which model gets which task. The router should weigh task type, repository sensitivity, programming language, context size, model confidence, availability of tests, previous failed attempts, production criticality, security classification, user latency requirement, internal capacity, and expected external cost.

A practical starting policy: inline completion, code explanation, documentation, unit test creation, boilerplate, and mechanical refactoring default to the internal model. Dependency upgrades and simple defects with a failing test go to the internal model with build validation. Complex defects without reproduction, architecture decisions, security critical code, and repeated internal failures escalate to Claude automatically. Anything above the internal latency limit, or below the confidence threshold, overflows to Claude without a developer having to ask for it.

Escalation should be automatic, since nobody should have to fight a weak internal model just because the compute happened to be cheaper.

18. Optimise the Anthropic spend before buying anything

Before any hardware conversation, challenge the implementation, not just the price.

Maximise prompt caching for repository instructions, system prompts, tool schemas, security policies, coding standards, architecture documents, frequently used source files, and repeated conversation prefixes. Paying full input price for unchanged context on every turn is an implementation failure, not a pricing problem.

Reduce unnecessary context. Agents often send entire files, large command outputs, or full conversation histories when only a fraction is relevant. Better retrieval and context compaction can save more than a hardware migration ever will.

Control agent loops with a maximum iteration count, a maximum cost, a maximum elapsed time, a maximum number of parallel sub agents, a maximum number of failed tool calls, an escalation policy, and a human intervention threshold. Unlimited autonomy paired with token based billing is an open ended financial exposure, and it is the single most common way these bills run away from the business case that was originally approved.

Route by capability so routine work uses the lowest cost model that can complete it correctly, and remove duplicated instructions that enterprise gateways add on top of content the application already sent. Allocate cost to outcomes, cost per developer, per application, per agent, per pull request, per resolved incident, per completed workflow, rather than a single token dashboard that shows consumption without showing value. And do not build the business case around batch pricing. At roughly 99% real time demand in this profile, batch discounts are close to irrelevant to the core architecture decision.

19. The hybrid architecture

The rational design owns stable base demand internally and keeps Anthropic for capability, peaks, and failures. That means one enterprise AI gateway, identity and access control, data classification enforcement, internal open model endpoints, Anthropic and other external providers, prompt and prefix caching, request classification, cost attribution, quality telemetry, automated validation, automatic escalation, capacity aware overflow, rate and budget controls, model version management, security monitoring, and full production observability, all in one place.

A request should flow through: determine whether the data may leave the enterprise, classify the task, estimate context and output requirements, select the cheapest suitable model, check internal capacity and queue latency, execute, validate the result where possible, escalate on failed validation, and record latency, cost, and outcome for the next iteration of the router’s decisions.

Sizing internal hardware to handle 60% to 80% of normal peak demand, with Anthropic absorbing the remainder, is likely more economical than buying enough hardware for the busiest few hours of the year.

20. Three year platform economics

A broad consumer deployment, 48 four GPU nodes, 192 RTX 5090 GPUs, roughly 1.6 million dollars of server hardware, 500,000 dollars of networking, spares, and facility work, average facility demand of 200 kW, electricity at 0.12 dollars per kWh, a platform team costing 1.2 million dollars a year, and 300,000 dollars a year of maintenance and replacement, comes out at roughly 7.23 million dollars over three years once electricity, staffing, and maintenance are added to the hardware.

An eight node H200 class platform, 64 H200 GPUs, roughly 3.2 million dollars of server hardware, 1 million dollars of networking, storage, and integration, average facility demand of 120 kW, platform staffing of 1.1 million dollars a year, and 400,000 dollars a year of support and maintenance, comes out at roughly 9.08 million dollars over three years.

Against a developer bill already running at 9.6 million dollars annually before the tail effect, both platforms clear three year parity comfortably if they displace even a moderate share of that spend, which is a materially stronger position than the same analysis would produce against a bill closer to 3 to 6 million dollars. The gap is exactly why the actual telemetry matters more than a generic industry assumption. Our numbers make the internal platform case earlier and more decisively than most published models of this trade off would suggest.

None of that means the enterprise platform automatically wins. It may also deliver data residency, predictable internal latency, control over model versions, capacity for confidential workloads, strategic independence, and reuse across other business functions. Those benefits need to be valued explicitly rather than folded quietly into an optimistic token calculation.

21. When each option makes sense

Stay primarily with Anthropic when annual spend is below roughly 1 million dollars, demand is highly variable, frontier quality is consistently required, there is no inference platform team in place, internal hardware would sit underused, data residency does not require local execution, and time to market matters more than unit cost.

Build a developer focused platform when coding agent spend exceeds roughly 2 to 3 million dollars annually, hundreds or thousands of developers use agents heavily, many tasks can be automatically validated, platform engineering capability already exists, open models pass the internal benchmark, Claude remains available for escalation, and real time latency can be held.

Build a broader enterprise platform when total model spend exceeds roughly 5 million dollars annually, demand is predictable and sustained, multiple departments can share the platform, data sovereignty adds real value, the organisation can run a production AI service, internal models have proven themselves on quality, and external overflow remains available as a safety valve.

Given our own numbers, we clear the developer focused threshold comfortably and sit close to the broader enterprise threshold on developer spend alone, before normal user spend is added.

22. The recommended path

Measure actual Anthropic consumption first, sixty to ninety days of telemetry, peak demand, model mix, cache rates, context lengths, developer concentration, and agent retries. Remove avoidable expenditure through caching, retrieval, context management, model selection, agent limits, and cost allocation. Build an internal coding benchmark from real historical tasks, measuring both model quality and developer elapsed time. Stand up a small consumer pilot, four integrated four GPU nodes are enough to test several model sizes, serving engines, and routing policies without a major capital commitment. Migrate the low risk coding work first, documentation, tests, explanation, boilerplate, repository search, mechanical refactoring. Introduce automatic Claude escalation so the internal model only gets the first attempt where it has demonstrated it deserves it. Load test real time concurrency with hundreds of simulated active agents and realistic context sizes. Then, and only then, choose the production hardware class, a larger consumer cluster, enterprise H200 class systems, hosted dedicated inference, a mixed internal fleet, or continued reliance on the external API, based on what the benchmark actually showed rather than on what looked good in a slide.

23. The final challenge to our Anthropic spend

This is not a choice between Anthropic and open source. Anthropic is valuable precisely because it absorbs model development cost, capacity risk, infrastructure complexity, and the ongoing burden of improving a frontier model. For a large share of our usage, that remains a genuinely good deal.

The problem starts when every task, regardless of how routine, gets sent to the most capable external model simply because that is the easiest architecture to build. At roughly 9.6 million dollars a year in developer spend before the tail effect, and with a clear pattern showing a small number of heavy users driving a disproportionate share of the bill, we have more than enough signal to justify a serious internal coding benchmark. If an internal model can complete 70% of routine coding tasks without slowing developers down or increasing defect rates, that spend deserves to be challenged properly, with real telemetry, not assumptions borrowed from someone else’s enterprise.

If our total Anthropic spend across the whole organisation were closer to half a million dollars a year, none of this would be worth the operational burden, but it is not. The strongest first move is not to replace Claude across five thousand employees. It is to build a real time internal coding service for the developers who consume the most tokens, whose output can be tested, and whose tasks can be routed intelligently between what is cheap and what is genuinely frontier.

Claude should stay available for the hard work, the internal capacity peaks, and the failures. The internal platform should carry the repeatable work that never deserved a frontier model price in the first place. The advantage will not belong to whoever picks proprietary AI or open AI as a religion. It will belong to whoever builds the controlled market between them and routes every real time task to the cheapest model that can complete it quickly, safely, and correctly.