Inside companies that have shipped, the number that matters is the other one. Inference, the cost of actually running a model each time someone uses the feature, is recurring, scales with adoption, and behaves in ways that traditional software cost models do not prepare anyone for.

Success is the thing that raises the bill

Conventional software has near-zero marginal cost per use. A feature that becomes ten times more popular costs approximately what it cost before, which is why software companies are structured the way they are and why product teams have spent thirty years being told to drive engagement.

Model inference inverts that instinct. Every invocation consumes compute, and usage growth converts directly into cost growth. Teams that shipped a well-received feature have found themselves in the disorienting position of watching adoption metrics and unit economics move in opposite directions.

This has pushed cost into architecture decisions that were previously made on capability alone. Routing simple requests to smaller models and reserving frontier capacity for cases that need it is now standard practice rather than an optimization. Caching, batching, shortening context and truncating conversation history all matter in a way they did not when the same team was running a pilot with fifty users and an unmetered credit balance.

The forecasting problem is worse than the cost itself. Finance can accommodate an expensive line item it can predict. Inference spend depends on usage patterns, prompt lengths, retry behavior and how much context each request carries, and small changes in any of those move the total substantially. Companies describe budget variances that would be scandals in any other category, and they are mostly a measurement failure rather than a spending one, closely related to the general evaluation gap that leaves organizations unable to characterize their own systems.

The strategic consequence is a reopening of a question that looked settled. The infrastructure buildout assumed inference would run in the same rented environments as training. Steady, high-volume inference of open-weight models is a different profile, predictable and continuous, which is precisely the workload the repatriation analysis targets. Several organizations have run that comparison and reached conclusions their cloud vendors would prefer they had not.

Pricing the feature is the part product teams have handled worst. A capability whose marginal cost is real cannot be given away at unlimited volume inside a flat-rate plan, and several companies have had to introduce usage limits after launch, which is a considerably worse experience than having set them at the outset.

Prices per token continue to fall, and that is the argument for waiting the problem out. It is a weaker argument than it appears, because the same period has seen applications adopt reasoning approaches that consume far more tokens per task. Unit prices falling while units per task rise is not obviously a saving, and it is the arithmetic most budgets have failed to do.

Earlier Cranberry Journal coverage examined Model Deprecation Becomes an Enterprise Risk, the other recurring cost of building on someone else's model.

That arrangement is ending. Across earnings calls, procurement documents and interviews with finance and technology executives, a consistent pattern has emerged this year. AI spending is migrating out of experimental budgets and into the same operating lines that pay for payroll software, cloud hosting and telecommunications. The question inside companies is no longer whether the technology deserves money. It is which department is accountable for the invoice.

From project to plumbing

The distinction matters more than it sounds. Experimental spending is judged on learning. Operating spending is judged on output. When a company reclassifies AI from the first category to the second, it commits itself to measuring the technology the way it measures electricity: continuously, unsentimentally and against alternatives.

Finance chiefs describe the shift in strikingly similar language. One controller at a midsized logistics firm put it this way: the company stopped asking what AI could do and started asking what it would cost to turn it off.

That framing, borrowed from the way businesses think about core infrastructure, changes procurement behavior. Contracts lengthen. Legal review deepens. Vendors that thrived on enthusiasm now face the same renewal scrutiny applied to any utility.

The new line items

The budget migration is visible in three places.

• Inference as a metered cost. Companies increasingly treat model usage the way they treat cloud compute, with monthly variance reports and per-department allocation.
• Data preparation as a standing function. What began as one-off cleanup projects has become permanent headcount, often inside finance or operations rather than IT.
• Evaluation as a control. Larger firms now budget for ongoing model testing the way they budget for audit, a recognition that the systems drift and must be re-verified.

None of these lines existed in most budgets thirty-six months ago. Together they represent a small but structural change in the anatomy of corporate spending.

Who owns the bill

The unresolved question is organizational. In some companies the chief information officer has absorbed AI spending entirely. In others, business units pay for their own usage, with central IT acting as a broker. A third model, still rare but growing, places AI spending under the chief financial officer directly, on the theory that a metered cost that touches every department belongs with the office that already arbitrates every other shared expense.

Each model produces different behavior. Centralized ownership favors fewer, larger vendor relationships. Distributed ownership produces experimentation but also duplication, with multiple teams paying separately for similar capability.

What it signals

Technology spending tends to pass through a recognizable arc: novelty, enthusiasm, disillusionment, then quiet absorption into the cost of doing business. Electrification followed it. Enterprise software followed it. The evidence this year suggests artificial intelligence has entered the final stage of that arc faster than most prior technologies, not because the enthusiasm was smaller but because the integration was easier.

The physical constraint on all of it is electricity, and the interconnection queue now holds more generation capacity waiting to connect than the grid currently carries. Compute plans that assume power arrives on schedule are making an assumption the queue does not support.

The recurring half of the bill is the one finance departments are now trying to forecast. Inference costs scale with adoption rather than sitting still, which inverts thirty years of software instinct about what success does to a budget.

The companies that adjust their accounting first tend to be the ones that negotiate best. Once a cost is measured like infrastructure, it can be managed like infrastructure. That, more than any single product announcement, is the story of enterprise AI in 2026.

The pattern across deployments is consistent. Companies started with customer-facing chatbots, discovered the reputational risk of a system that improvises in public, and redirected the technology at internal processes where every action is checkable against a document, a ledger or a rule.

Why the back office was ready

Back-office work has three properties that suit autonomous software: it is repetitive, it is verifiable, and it is unloved. An agent that extracts terms from a contract can be audited line by line. One that drafts a collections email escalates to a human before anything sends. The cost of an error is a correction, not a headline.

The economics compound with volume. Finance departments report processing growth without headcount growth, and the displaced hours have largely shifted to exception handling and vendor negotiation, the parts of the job that were always the actual job. As small businesses adopt the same tools, the pattern is repeating below the enterprise tier.

The strategic consequence is a quiet redefinition of what companies buy. Procurement teams increasingly evaluate software by tasks completed rather than seats licensed, a shift with real implications for how AI systems are vetted before they touch a company's books.

The chatbot got the press conferences. The agent got the budget line.

Earlier Cranberry Journal coverage examined Small Models, Big Deployments.

Licensing deals between AI developers and content owners, publishers, image libraries, forums, scientific archives, have moved from novelty to routine, and a genuine market is forming around them, with brokers, standard terms and the beginnings of price discovery.

What archives are worth

Pricing has begun to sort by scarcity and structure. Commodity web text commands little because everyone already has it. What commands real money is the material the open web lacks: cleanly labeled archives, specialized professional content, fresh reporting, and data with clear provenance a buyer can defend in court.

For content owners the shift creates an unfamiliar asset class. Publications that spent two decades watching distribution value collapse are discovering that their back catalogs, organized, dated and rights-cleared, have industrial buyers. The economics of independent media now include a line item nobody projected five years ago.

The unresolved tension is renewal. A model trained once on an archive does not obviously need it twice, which pushes owners toward ongoing-access structures, feeds rather than dumps, and pushes developers to value the one input that depreciates fastest: the present. Whoever keeps producing new, verifiable material holds the leverage, which is, for once, good news for the people doing the producing.

Related reporting has traced the Quiet Fight Over the Numbers Everything Depends On.

Interviews with small-business owners across services, trades and local retail reveal a consistent pattern: generative tools are being adopted for narrow, unglamorous jobs where the alternative was the owner's own evening hours.

Where it sticks

The applications that survive past the first month cluster in four areas: drafting quotes and estimates from job notes, following up with customers who went quiet, translating paperwork, permits, insurance letters, vendor contracts, into plain language, and producing the steady stream of routine content a local business needs to appear alive online.

What these share is a common shape. Each takes unstructured input the owner already has and produces a document the owner already knows how to judge. There is no workflow redesign, no integration project and no committee.

The adoption advantage

Small firms are, in one respect, structurally better positioned than large ones. There is no procurement process to survive and no legacy system to reconcile. The owner tries the tool on Tuesday, and by Friday it is either part of the business or abandoned.

The failure mode is equally distinctive: overreach. Owners who tried to hand off judgment, pricing, hiring decisions, anything requiring knowledge of a specific customer, reported retreating within weeks. The tools that stayed were the ones assigned to paperwork, not decisions.

For software vendors, the lesson is uncomfortable. The small-business market is adopting faster than the enterprise, but it is adopting the cheapest general-purpose tools, not the specialized products built to court it.

Earlier Cranberry Journal coverage examined AI Agents Take Over the Back Office, Quietly and the Rise of the Operator: Why Founders Are Hiring COOs Earlier.

What is usually absent is a measurement of whether the system does its actual job better than the process it replaced, evaluated against cases where the right answer is known.

The pilot metric that did not survive contact

This is not carelessness so much as a structural feature of how these deployments happen. A pilot is scoped narrowly and measured, because it has to justify expansion. The expansion inherits the credibility of the pilot without inheriting its measurement, since applying the same rigor at production scale requires labeled data, sustained human review and someone whose job it is.

The difficulty is genuine. Evaluating a summarization, a drafted response or an extracted field requires knowing what the correct output was, and for most business processes nobody ever wrote it down. Building that ground truth is slow, unglamorous work that competes for budget with the next deployment, and it produces no demo.

The consequences differ by application. In back office automation the errors are often self-revealing, because an invoice coded to the wrong account eventually surfaces in a reconciliation. In customer-facing and advisory applications they are not, and a system that is subtly wrong in a consistent direction can operate for a long time before anything visible happens.

The gap also undermines the decisions built on top of it. A company that cannot measure its current system's performance cannot evaluate a replacement, which turns every model deprecation into an act of faith. It cannot make an honest build-versus-buy comparison. And it cannot answer the question its auditors and increasingly its regulators have started asking, which is not whether the company uses AI but whether it has evidence about how well it performs.

Some of the discipline is migrating from procurement inward. Buyers who negotiated standard contract terms discovered in the process that they needed acceptance criteria, and acceptance criteria require a test set. That is an unheroic path to good practice, and it is working better than exhortation.

Vendor benchmarks do not substitute, and treating them as though they do is the most common error. A published score describes performance on a public task set the vendor selected, which says close to nothing about performance on a particular company's documents, customers and edge cases.

The organizations that do this properly share an approach that sounds obvious and is rare: a fixed set of representative cases with known correct answers, scored the same way every time, run against every version and every candidate replacement, with results tracked over time. It costs real money to build once. It converts every subsequent question about the system from a debate into a measurement, which is the entire point, and it is the difference between deploying a capability and merely installing one.

Procurement executives at large buyers describe a convergence on a handful of non-negotiable terms: clarity on whether customer data trains future models, audit rights over model changes that could affect output quality, benchmark commitments tied to renewal, and defined exit provisions, including data return and transition assistance.

Buyers are writing the standard

Notably, the standardization is being driven from the buy side. Industry groups in financial services, health care and insurance have circulated model clauses, and vendors that once treated every term as bespoke now arrive with pre-approved language.

The motivation is workload as much as risk. Legal departments that negotiated a handful of AI contracts in 2024 are handling dozens now. Novel terms do not scale.

What remains contested

Two areas remain genuinely unsettled. The first is liability for model output, where vendors continue to resist meaningful responsibility for errors. The second is version stability: buyers want notice and testing windows before models change underneath them, while vendors want the freedom to improve continuously.

How those two questions resolve will shape the market's structure. If buyers win version stability, the market favors fewer, slower, more accountable vendors. If vendors win, buyers will respond the way they always have, by building evaluation muscle in-house and treating every model as replaceable.

Earlier Cranberry Journal coverage examined the Training Data Market Grows Up, AI Spending Moves From Experimentation to Infrastructure and Companies Should Disclose AI Use the Way They Disclose Auditors.

Model providers do not offer it. Models are deprecated on vendor timelines, sometimes with a year of notice and sometimes considerably less, and the replacement is not a drop-in. It is a different system with different behavior that happens to accept the same API call.

Why a version bump is not a version bump

Conventional software dependencies break loudly. A removed function throws an error, a test fails, and the failure points at its cause. Model changes break quietly. The new version returns a plausible answer that differs from the old one in ways no type checker detects: a classification boundary shifts, a summarization style changes, a prompt that reliably produced structured output starts producing it with occasional variation.

Anything built on top of that behavior inherits the drift. Prompts tuned over months against one model's quirks are not portable. Evaluation thresholds calibrated to one version's error profile mean something different against another. Downstream systems that learned to expect a particular output shape encounter a new one. Teams that have been through a forced migration describe the work as a rebuild of the surrounding scaffolding rather than a swap.

The cost lands unevenly. Organizations running smaller models they host themselves control their own upgrade timing, which is turning out to be a more significant advantage than the cost argument that usually justifies that choice. Companies on frontier hosted APIs get capability they could not otherwise obtain, and accept a dependency whose lifecycle belongs to someone else.

Procurement has started to respond, which is the clearest sign that this has stopped being a research concern. The contract terms corporate buyers are pushing for now routinely include minimum deprecation notice, version pinning for a defined period, and access to a prior version during a transition window. Those are unremarkable provisions in any other category of enterprise software, and the fact that they had to be negotiated specifically tells you how new this market still is.

The internal discipline that helps is unglamorous and mostly absent: maintain an evaluation suite that captures what the system is actually supposed to do, run it against candidate replacements, and treat the results as the migration criterion. Organizations that have this can assess a new model in days. Organizations without it, which is most of them, are in the position of having deployed something whose correctness they cannot re-verify, which is a problem that predates deprecation and merely becomes visible because of it.

The cost compounds for organisations that deployed widely without measuring, since a migration forces the question of whether the replacement performs adequately and the evaluation infrastructure to answer it was never built. A forced migration is where that debt comes due, all at once and on someone else's schedule.

The strategic question underneath is one that few companies have answered explicitly. Building on a frontier model means renting a capability that is improving faster than you could develop it, on terms that include the provider changing it. That trade is often correct. It is rarely made deliberately, which is the part worth fixing.

The logic is operational. A compact model tuned to a narrow job, routing support tickets, extracting fields from freight documents, summarizing case notes, matches or beats a giant generalist on that job while costing a fraction to run. It can live on a company's own hardware, which resolves at a stroke the privacy and data-residency questions that stall enterprise deals.

The portfolio approach

The emerging corporate pattern is a portfolio: a frontier model rented for the hardest reasoning, a mid-sized workhorse for general tasks, and a fleet of small specialists embedded in workflows. Costs concentrate where capability is actually needed instead of being smeared across every API call.

Hardware trends reinforce the shift, as laptops and phones ship with accelerators that make local inference ordinary, and spending on AI infrastructure increasingly splits between training giants and serving dwarfs.

None of this diminishes the frontier, which still defines what is possible and generates the distilled knowledge smaller models inherit. It does redistribute the money. The frontier is a research budget. The small model is a cost of goods sold, and the second category is always, eventually, larger.

The cost argument has become the main one rather than a secondary consideration, as inference moves from footnote to line item in budgets that were built when usage was a pilot.

Related reporting has traced AI Agents Take Over the Back Office, Quietly and States Are Writing the AI Rulebook, One Legislature at a Time.