There is a flattering version of enterprise AI strategy in which every dependency is a failure of ambition and every GPU purchase is an act of self-determination. It is an excellent story for the people selling GPUs. For the buyer, the invoices require a less romantic explanation.

The strongest objection to generating your own tokens is that an external provider may be better placed to absorb uncertainty. It can pool demand, operate specialized infrastructure, and offer capabilities your team cannot economically reproduce. Buying that service can preserve more useful freedom than owning a machine whose workload has not yet arrived.

The supplier may deserve its margin

A provider’s price pays for more than the moment of inference. The buyer may also be purchasing access to model improvements, operating expertise, capacity management, and a service maintained by somebody else. Which of those benefits is real depends on the provider and the agreement. They belong in the comparison rather than being dismissed as markup.

Consider an illustrative company with irregular demand for difficult analysis. Its peak needs are large, its ordinary needs are small, and the work changes. Dedicated hardware must either cover a peak it rarely sees or rely on an external service anyway. Meanwhile, the team responsible for the local system has to maintain a capability it seldom exercises.

The external supplier’s ability to share capacity across customers may be more valuable here than a lower estimated generation cost on fully occupied hardware. Michael Armbrust and colleagues make the capital-allocation consequence explicit in Above the Clouds:

In addition, the absence of up-front capital expense allows capital to be redirected to core business investment.

Above the Clouds: A Berkeley View of Cloud Computing Michael Armbrust and colleagues · 10 February 2009 Section 6.1: Elasticity: Shifting the Risk.

The report’s executive summary also explains why paying for capacity as it is needed can beat owning enough to cover a peak, despite a higher rental rate. Its historical cloud examples are not present-day AI price estimates. The applicable insight is that utilization and demand uncertainty belong in the comparison.

That advantage can reverse for a stable, well-understood task. The point is to identify which party can carry each risk more cheaply. Ownership is a production arrangement, not a personality trait.

Cheap generation can be expensive labor

Suppose two routes process the same 1,000 tasks in an explicitly fictional monthly comparison. The local route costs €100 in allocated production expense; the hosted route costs €500. Keep acceptance criteria fixed and suppose both eventually deliver all 1,000 outcomes, but local processing requires 100 extra human repairs, while hosted processing requires 10.

At €10 per repair, the totals are €1,100 locally and €600 hosted, before any other cost difference. The local production bill is one-fifth as large; its combined bill is nearly twice as large. Those figures are an illustration of the mechanism, not a benchmark or a recommended repair rate.

Now suppose better task design eliminates most local repairs. The decision may change. That is why I would resist explaining either result entirely through model superiority. Routing, input preparation, acceptance rules, and human handling influence the economics too.

Anthropic’s 2024 guidance on effective agents recommends starting simply and adding complexity when the task requires it; the page now flags that its tooling discussion has aged. The durable question for an infrastructure decision is similarly plain: which additional responsibility buys enough improvement to justify itself?

Illustrative costs for 1,000 accepted tasks: local production and repair total 1,100 euros; hosted production and repair total 600 euros.
The fictional comparison in the text: local €100 production plus 100 repairs at €10; hosted €500 plus 10 repairs at €10. Both eventually deliver 1,000 accepted tasks. These are not market prices; other cost differences are omitted.

Neutrality has a price too

A vendor-agnostic architecture can become another kind of overbuilding. To support every provider, a team may expose only the features all of them share. It pays for a strong service and then carefully avoids using what makes it strong.

I would keep stable business contracts and supplier-specific implementations separate. The enterprise owns the task, data permissions, acceptance criteria, and outcome history. An implementation can use a provider’s distinctive features when the benefit exceeds the cost of replacing them.

That replacement cost should be visible. An abstraction that conceals it is less helpful than a documented dependency with a tested fallback. Sometimes the rational choice is to accept a substantial dependency for a substantial gain, with a review date and an understood failure plan.

The objective is informed dependence. Universal interchangeability would be nice, but the world has declined to provide it at no charge.

Keep the right assets in-house

The company can buy inference while retaining the knowledge necessary to change its mind. Preserve representative inputs where lawful, evaluation cases, routing decisions, and the record of difficult exceptions. Rehearse another provider for a bounded workload without maintaining an entire parallel production estate.

That arrangement still costs money. It may be cheaper than continuous dual operation, and more useful than an unused server bought as a declaration of principle.

I would own production when it removes a material constraint or supports a valuable, credible alternative. I would rent it when the supplier carries uncertainty better and the organization can preserve enough control over its work. The test of a vendor-agnostic strategy is whether it can recommend either choice without needing to rewrite its ideology.