Priced Per Token, Incurred Per Task

A Canadian firm evaluating an AI capability is quoted a price per million tokens, converts it to a monthly estimate, and finds the number reassuringly small. Six months later the invoice is several times the estimate and nobody can say which decision caused it. The pricing was accurate. The unit was wrong.

The Wrong Unit

The framing correction that the rest of this article develops.

One source puts it directly: inference cost is not just the headline price per million input tokens, since a realistic estimate adds input tokens, cached-input reads or writes, output tokens, reasoning or intermediate turns, tool fees and retries. It concludes that the cheapest model for a short prompt can be the wrong choice for a long-context or agentic workload, so the comparison should be cost per completed task rather than cost per token alone[1].

The same source describes the transition from evaluation to production: pricing pages look simple until an application leaves the demo stage, because production traffic adds system prompts, retrieved documents, tool schemas, conversation history, cached prefixes, structured outputs, retries and sometimes hidden reasoning tokens. It frames the result as a unit-economics problem, asking how much one successful answer, document, support ticket or agent task costs when the whole workflow is included[1].

A finance audience will recognise the error immediately, because it is a standard costing mistake in unfamiliar clothing. Pricing a service on the cost of one input, ignoring the other inputs and the yield, is what a costing exercise exists to prevent.

The word successful in that formulation is doing quiet work. A task that fails and is retried consumed cost and produced nothing, so the denominator is completed tasks and the numerator includes the failures.

What A Task Actually Contains

Decomposing the gap, because each element is separately estimable.

Working from the components the source lists[1], a single completed task in a Canadian professional workflow typically carries:

The system prompt, which is sent with every request and may be long. This is why prefix caching matters below.

Retrieved documents, which in a grounded workflow can dwarf the user's actual question. A retrieval returning ten passages sends ten passages.

Conversation history, which grows through a session, so the tenth exchange costs more than the first even where the question is shorter.

Tool schemas, being the descriptions of available tools sent so the model knows what it can call.

Intermediate turns, where an agentic workflow makes several model calls to complete one business task.

Reasoning tokens, which the source notes are sometimes hidden, meaning consumed and charged without appearing in the visible output.

Retries, on failure, malformed output or validation rejection.

The pattern worth noticing is that most of these scale with something other than the size of the request. Retrieved context scales with how much the system decided to retrieve. Turns scale with task difficulty. Retries scale with failure rate. None is visible on a pricing page, and none is controlled by the person who asked the question.

The Deflation Trap

The finding that should govern how a firm forecasts this cost line.

One source describes what it calls a cost paradox: per-token pricing dropped tenfold, but token consumption increased a hundredfold for certain workloads, and the mathematics does not favour the providers. It states that a customer paying twenty dollars a month might generate eighteen to twenty-five dollars in inference costs during heavy reasoning tasks, that some providers responded by capping reasoning tokens to limit how much internal thinking a model performs, and that others implemented tiered pricing where reasoning-heavy requests cost more, with both creating friction and complexity[2].

We report the ratios as stated, note they are described as applying to certain workloads rather than universally, and did not access underlying data.

The structure is one a Canadian finance professional will recognise from other contexts: unit price falls, consumption rises faster, total spend increases. Efficiency improvements that reduce the cost of doing something frequently increase how much of it gets done.

The forecasting consequence is direct and runs against the prevailing narrative. A firm budgeting on the basis that prices are falling roughly tenfold every year or two[3] may nonetheless see its bill rise, because the price is only one term.

The right question for a budget is not what the price per token will be next year. It is how many tokens a task will consume next year, and the section below argues that number is going up for reasons that are hard to resist.

Why Consumption Rises With Quality

The mechanism behind the paradox, offered as our own analysis.

Consumption is not rising because users became wasteful. It is rising because the techniques that improve output quality all consume more tokens.

Retrieval improves grounding by supplying more context, and context is input tokens. Reasoning improves accuracy on difficult problems by generating intermediate steps, and those steps are output tokens, sometimes hidden ones[1]. Agentic decomposition improves reliability on multi-step work by making several calls where one was made before. Longer conversation history improves coherence and grows the input on every turn.

Every quality lever available to a firm is a consumption lever. That is the uncomfortable structure: the improvements a firm makes in response to the accuracy concerns this publication has documented are the same improvements that raise cost per task.

Two consequences follow for a Canadian firm.

Cost and quality are coupled in a way the pricing conversation obscures, so a decision to improve grounding or add verification steps is a costing decision, and it should be made with the cost visible rather than discovered later.

And a falling headline price does not translate into a falling cost per task unless consumption per task is held constant, which nothing in a normal improvement cycle does.

Three Orders Of Magnitude

The spread, which is the reason routing matters.

One source reports that API pricing spans three orders of magnitude, with budget tiers around 0.06 to 0.30 dollars per million tokens, mid-tier around 0.55 to 15 dollars per million, and frontier models around 15 to 75 dollars per million[4]. Another gives frontier models at 2 to 15 dollars per million input tokens and 10 to 75 per million output[3].

On the direction of travel, one source states that as of March 2026 achieving a particular earlier frontier level of performance cost approximately 0.40 to 0.80 dollars per million tokens using competitive alternatives, against 2 to 15 dollars per million for the original variants, representing deflation from late 2022 when equivalent performance cost over 20 dollars per million[2].

We report these as stated. Prices in this market change frequently, several sources are published by vendors of related services, and any figure here should be verified before use in a model.

The durable observation is the spread rather than any point on it. A thousandfold range between the cheapest and most expensive options means the model selection decision dominates most other cost decisions, and that a firm using one model for everything is almost certainly overpaying on the easy work or underperforming on the hard work.

Output Costs More Than Input

An asymmetry with a direct design implication.

One source notes that output tokens are typically four to five times more expensive than input tokens, because generation requires more compute per token than reading[3].

The implication for professional workflows is that verbosity is expensive in a way that context is not, at least at the same volume.

That has a practical consequence most firms get backwards. There is a natural instinct to economise on how much context is supplied, because supplying documents feels wasteful. On this pricing, supplying more input to get a shorter, better-targeted output may cost less than supplying less input and receiving a long, hedged response.

It also means output length is a controllable cost variable. A workflow that returns structured fields costs materially less than one returning prose that says the same thing, and the structured version is generally more useful downstream.

And it bears on the explanation question from the oversight article in this series. Asking a system to narrate its reasoning generates output tokens at the expensive rate, and the evidence there suggested narrative rationales increase reviewer deference rather than scrutiny. On both counts, requesting a criteria-and-evidence structure rather than an explanatory essay is the better choice.

Inference Is Cost Of Sales

The accounting point, and the one we consider most important for this publication's readers.

One source states that inference spend is now a variable cost of sales line and a variable line in gross margin, and that teams treating it as such find substantial savings available[5]. Another describes inference cost as the operational cost that determines application unit economics and the cost that scales with usage, separate from one-time training cost[3].

Most Canadian firms are not booking it that way. An AI capability arrives as a subscription or an API account, is coded to software or technology expense, and sits in overhead alongside the accounting system and the office suite.

That classification is defensible for a fixed licence and wrong for consumption-based inference attached to client delivery, and the difference is not cosmetic.

A cost in overhead is absorbed across the business and reviewed annually against budget. A cost of sales varies with delivery volume, belongs in gross margin, and should be visible in the profitability of individual engagements.

Our recommendation is that where inference is consumed in delivering client work, it should be treated as a direct cost of that work and allocated accordingly. That single change surfaces the fixed-fee exposure described below, which is otherwise invisible because the cost sits in a different part of the statement from the revenue it supports.

What That Does To Gross Margin

The structural consequence, reported with a note about internal inconsistency in the source.

One source states that gross margins for AI applications are tighter than traditional software, giving 40 to 70 percent against 70 to 90 percent, attributing the difference to inference cost as cost of sales. Elsewhere in the same piece it describes founders being surprised when gross margins are 30 to 50 percent instead of a software standard of 70 to 80 percent[3]. It adds that as inference costs decline, margins improve[3].

The two margin ranges in that source are not identical and we report both rather than selecting one. The consistent claim is a material gap against software norms.

The prescription it offers is worth recording: track inference cost monthly, optimise via smaller models, caching and batching, and design pricing for the economics[3].

For a Canadian professional services firm the translation is not about software margins, since the firm is not selling software. It is that the delivery of professional work now has a marginal cost component that did not previously exist, alongside labour.

Labour was always the variable cost, and firms are extremely good at managing it, with time recording, realisation analysis, utilisation targets and write-off reporting all built for the purpose. The new variable cost has none of that apparatus around it, which is the gap the remaining sections address.

The Fixed Fee Problem

The exposure specific to professional firms, and it is our own analysis.

A great deal of Canadian professional work is priced on a fixed or capped basis: an annual compliance engagement, a monthly bookkeeping retainer, a defined-scope advisory piece. The firm bears the risk that the work takes longer than expected.

That risk has always been managed against a variable cost the firm controls and observes. Hours are recorded, budgets are set, overruns are visible in realisation, and a partner can decide to stop.

Inference cost has none of those properties as normally deployed. It is not recorded against the engagement, it is not budgeted per file, it does not appear in realisation, and no one is watching it while the work proceeds.

The exposure is that a fixed price now covers two variable costs, one instrumented and one not. And the uninstrumented one scales with the same driver as the instrumented one, being the difficulty and length of the work, so the two move together in the same adverse direction.

The remedy is not exotic. Inference consumption should be attributed to the engagement in the same way time is, so that an engagement's profitability includes it. Where that is not technically possible today, an estimated allocation is better than an omission, because an omission asserts the cost is zero.

It Spikes Where Margin Is Already Worst

The compounding that makes this worse than a proportional cost, and it follows from earlier articles in this series.

The straight-through processing article established that raising the automation rate concentrates difficulty in the residual, because each increment absorbs the most tractable cases. The exceptions that remain are, by construction, the hard ones.

Now consider what consumes tokens. Difficult cases involve more retrieved context, more intermediate turns, more reasoning and more retries, all of which are the cost drivers listed above[1].

So inference cost per task is highest on exactly the files that already consume the most staff time, already have the worst realisation, and already generate the exceptions the team handles manually.

Three costs therefore correlate: staff hours, inference spend and error risk. A firm looking at averages will see none of this, because averages are dominated by the many easy files.

The practical instruction is to examine cost per task by difficulty band rather than in aggregate, which is the same distributional argument this publication has made about productivity measurement and exception composition. In all three cases the mean conceals the population that matters.

The Four Levers

What can actually be done, with the claimed magnitudes and appropriate scepticism.

One source states that caching, batching, model routing and quantisation can cut managed API spend by 50 to 90 percent on typical production workloads without touching model quality[5]. Another gives per-technique figures: quantisation two to four times, response caching for repeated queries three to ten times, prompt optimisation one and a half to three times, model routing two to five times, and batch processing one and a third to two times, adding that these compound when combined[2].

A third notes that batch endpoints can offer bulk inference at roughly half of real-time token costs, and that caching prevents repeated processing of static components such as system prompts or repeated context blocks[6].

We flag that all three sources sell related services, that savings ranges of this width are marketing-adjacent, and that the phrase without touching model quality is an assertion rather than a demonstrated result, particularly for quantisation, which reduces numerical precision.

The techniques themselves are real and well established. What a Canadian firm should take from the numbers is direction rather than magnitude: material savings are available, and the specific figure for a given workload has to be measured rather than assumed.

For a firm consuming a managed API rather than running its own infrastructure, caching, routing and batching are accessible. Quantisation generally is not, since it concerns how a model is served.

Sequencing Matters More Than Selection

A practical point that is easy to miss and cheap to act on.

One source observes that the challenge is sequencing, and that most teams reach for quantisation or routing first because those feel like the engineering levers, when prompt caching on a high-reuse workload returns more savings[5].

The reasoning is straightforward once stated. A workflow with a long system prompt sent identically on every request is paying repeatedly for the same input, and prefix caching addresses that with no change to model, output or quality.

One source notes that reusing the same system prompt across requests can cut input token costs significantly where a provider supports prefix caching[7], and another records that at least one provider prices cache writes and cache reads separately with hits cheaper[1].

The diagnostic for a Canadian firm is the reuse rate: how much of what is sent on each request is identical to the previous one. In a professional workflow with a detailed system prompt, a fixed set of instructions and a stable schema, that proportion is often large.

Caching is also the lever with the least effect on anything else. Routing changes which model answers, which changes quality. Quantisation changes precision. Caching changes only what is paid for content already sent.

Routing And The Non-Linearity

The second lever, and the observation that makes it defensible.

One source gives a worked routing example, sending roughly sixty percent of requests to a small model, thirty percent to a mid-tier model and ten percent to a large one based on complexity, and reports that average cost per request drops 40 to 50 percent compared with routing everything to the highest-capability model. It advises mapping task complexity to model tiers with budget-priority flags to override toward cheaper models when margins matter[7].

Its more interesting observation is that moving to a model roughly four times the price does not deliver four times the quality, because quality improvements often do not scale linearly, and that benchmarking a specific task against models reveals sweet spots where cost and performance align[7].

The non-linearity is the whole argument for routing, and it has a corollary this publication has already established from another direction. The benchmark contamination article argued that published scores are unreliable evidence and that a firm needs its own evaluation set built from its own closed files.

That evaluation set is exactly the instrument required here. Establishing which model is sufficient for which task class is a measurement question, and the answer for a Canadian tax or bookkeeping workflow is not derivable from any published leaderboard.

So the same private evaluation set serves three purposes across this series: procurement evidence, drift detection, and now cost routing. That is a strong argument for building it.

The Budget Is A Control

The convergence that ties this article to the control design group.

One source recommends setting a maximum number of turns, a maximum tool budget, a maximum output budget and a hard dollar budget per task, with a kill switch that stops a run when the agent repeats the same tool call, grows its context unexpectedly or exceeds a latency threshold. It describes the budget as the economic version of the same boundary that control layers provide[1].

That last phrase is exactly right and worth stating in this publication's own terms.

The segregation of duties article argued that a control expressed as an instruction to the model is a request, and that enforcement must sit outside the model. The prompt injection article argued that since the attack cannot be prevented, the variable a firm controls is what a compromised system is permitted to do.

A hard dollar cap per task is precisely such a control. It is deterministic, it sits outside the model, it does not depend on the model behaving as intended, and it bounds the consequence of any failure mode that manifests as unbounded work.

It also happens to be the single most effective protection against the runaway-loop failure, in which an agent repeats a tool call indefinitely. The cost cap stops it whether the cause is a bug, a difficult input or an injected instruction.

Our recommendation is that a Canadian firm deploying any agentic workflow implement a per-task cost ceiling before deploying it, and treat the ceiling as a control in its framework rather than as a finance measure.

Budget By Workload Class

The method, which is more disciplined than most firms will expect.

One source advises building a budget from workload classes rather than from a single requests-per-month number, recording for each class the requests, tokens per request, cache hit rate, output length, turns, tools, retries, model mix and target quality, then calculating median, ninety-fifth percentile and worst-case caps. It recommends a dashboard whose first view is cost per request, on the basis that this catches sudden prompt growth[1].

Two features of that method deserve emphasis.

The percentile framing matters because this cost distribution is not symmetric. A workflow whose median task costs a few cents may have a ninety-fifth percentile several multiples higher, driven by long documents, many turns and retries. Budgeting on the median understates by whatever the tail contributes, and the tail is where the difficult files sit.

And cost per request as the primary monitored metric is a good choice because of what it detects. A prompt template that grew, a retrieval configuration returning more passages, or a system prompt someone extended will show up as a step change in cost per request while total spend still looks explicable as volume growth.

That is the same diagnostic logic the drift article applied to error rates: watch the per-unit measure over time, because a step change identifies both the timing and, by elimination, the cause.

The Lines Everyone Omits

The costs outside the token bill, and one of them settles an argument from earlier in this series.

The same source advises adding a separate line for embeddings, reranking, web search, storage, observability and human review[1].

The first five are infrastructure and are frequently forgotten. Embedding a document corpus is a cost, re-embedding it after a change is another, and storage of vectors and logs persists.

The sixth is the significant one. Human review appears as a line in the unit cost of an AI task, in a source concerned purely with economics rather than with control design.

The function allocation article in this series argued that business cases count the work automation removes and omit the work it creates, and that this is a sufficient explanation for gains falling short of projections. The productivity article reported a randomised trial in which the measured slowdown was attributed largely to the overhead of reviewing and integrating generated output.

Here is a cost playbook independently reaching the same conclusion: review is part of the unit cost of the task, not an overhead absorbed elsewhere.

For a Canadian firm the implication is that a cost per task excluding review time is not the cost of the task. It is the cost of the machine's contribution to the task, which is a different and considerably less useful number.

When Self-Hosting Makes Sense

The question a firm will eventually be asked, with the answer stated plainly.

One source sets out the conditions under which owned infrastructure wins: steady, predictable, high-volume load where committed hardware would stay near saturation through the night and the trough, or hard data-residency and compliance constraints where regulated workloads cannot leave the organisation's own environment. It notes that cost per token is essentially the hardware hourly price divided by tokens actually produced in that hour, which makes utilisation the dominant variable, and reports that public list rates for a current generation accelerator spanned 3.49 to 14.24 dollars per hour across clouds in April 2026[8].

Its decisive caveat is about staffing. It records a three to four times throughput gap between stock and tuned deployments and observes that closing it yourself means staffing for kernels, batching and capacity management permanently[8]. Related guidance warns that scaling on hardware utilisation alone overprovisions and wastes spend, and that queue size and batch size align capacity with real load[4].

For essentially every Canadian mid-market business and professional firm the answer is that self-hosting is not the right choice, and the reason is the permanent specialist staffing rather than the hardware price.

The utilisation point makes it clearer. A firm whose load follows business hours in one time zone cannot keep committed hardware saturated overnight, so it pays for capacity it does not use, which is the opposite of the condition under which owned serving wins.

The residency exception is the one that could apply. A firm with a contractual or regulatory constraint requiring data to stay within a defined perimeter may face this question for reasons that are not economic, and should evaluate it as a compliance cost rather than a saving.

A Worked Case: The Fixed-Fee Engagement

A Canadian firm delivering a fixed-fee compliance engagement with AI assistance. The reconstruction illustrates the mechanics rather than reporting specific figures.

The pilot was run on straightforward files. Cost per file was small, the estimate was built from it, and the capability was approved as a modest technology expense.

In production the population includes difficult files. Those files retrieve more context, require more turns, generate more reasoning and produce more retries[1], so their cost per task is a multiple of the pilot figure. The pilot did not measure the ninety-fifth percentile because the pilot population had no tail.

The firm improves grounding in response to accuracy concerns, which increases retrieved context and therefore input tokens on every request. Quality improves and cost per task rises, and nobody connects the two because the cost sits in overhead and the quality decision was made by a different person.

Because the fee is fixed and the cost is not attributed to the engagement, the erosion is invisible in engagement profitability. It appears as a technology expense variance at the firm level, twelve months later, described as higher than budgeted usage.

The remedies available were all cheap and all prospective: attribute consumption to the engagement, budget by workload class with percentiles rather than a median[1], monitor cost per request to catch prompt growth[1], set a per-task ceiling[1], and check the cache reuse rate before doing anything more elaborate[5].

What To Do

Price the task, not the token. Include system prompt, retrieved context, history, tool schemas, turns, reasoning and retries, over completed tasks rather than attempts.

Reclassify inference as a cost of sales where it supports delivery. Sitting in overhead, it is invisible in engagement profitability, which is exactly where the exposure lives.

Attribute consumption to engagements. A fixed fee now covers two variable costs and only one of them is instrumented.

Budget by workload class with percentiles. The distribution is skewed and the median understates by whatever the tail contributes.

Monitor cost per request as the primary metric. It catches prompt growth and configuration change that total spend conceals as volume.

Set a hard per-task cost ceiling with a kill switch. This is a control, not a finance measure, and it bounds runaway loops whatever their cause.

Check the cache reuse rate first. Sequencing matters, and prefix caching on a high-reuse workload returns more than the levers that feel more technical.

Route by task class, using your own evaluation set. Quality does not scale linearly with price, and the sufficient model for your work is not derivable from a published leaderboard.

Include human review in the unit cost. A cost per task excluding review is the cost of the machine's contribution, not of the task.

Do not self-host. Unless load is steady enough to saturate committed hardware around the clock, or residency requires it, and then treat it as a compliance cost rather than a saving.

The Limits Of This Analysis

Several caveats matter. Every source here is a commercial publication: model hosting providers, infrastructure vendors, consultancies selling AI transformation engagements, and a startup lexicon. All have an interest in the conclusions they present, and the savings ranges reported, including 50 to 90 percent reductions and the per-technique multiples, are marketing-adjacent and were not independently verified; the claim that these leave model quality untouched is an assertion rather than a demonstrated result. Prices in this market change frequently and every figure quoted should be verified before use in any model. The cost paradox ratios of tenfold price decline against hundredfold consumption growth are reported as stated for certain workloads, without access to underlying data. One source gives two different gross margin ranges in the same piece and we have reported both rather than selecting. Hardware pricing and throughput figures are point-in-time and jurisdiction-agnostic. The classification of inference as cost of sales, the fixed-fee exposure argument, the compounding of cost with file difficulty, the coupling of quality levers to consumption levers, and the worked case are our own analysis rather than findings in the cited material. This article does not address total cost of ownership beyond inference, vendor contracting, licensing structures, Canadian tax treatment of software and cloud expenditure, or transfer pricing where services cross borders, several of which this publication addresses separately. Nothing here is accounting or tax advice, and classification decisions should be taken with reference to the applicable reporting framework.

Related Reading

AI & Automation In Finance The Residual Is The Job Why the files that cost the most to process are the ones automation leaves behind. AI & Automation In Finance The Exam Was In The Textbook The private evaluation set that also tells you which model is cheap enough for which task. AI & Automation In Finance Pricing Your Ambiguity Vendors understate total cost because they sell licences. Consultancies overstate it because they sell integration. Between two opposed biases sits a...

Frequently Asked Questions

Why is our bill higher than the pricing page suggested?

Because the page prices tokens and you consume tasks. A production request carries the system prompt, retrieved documents, tool schemas, conversation history, cached prefixes, intermediate turns, sometimes hidden reasoning tokens and retries. The right comparison is cost per completed task, where the denominator excludes attempts that failed and had to be repeated.

Aren't prices falling anyway?

Per token, yes, substantially. But one source describes a paradox in which per-token pricing dropped roughly tenfold while consumption rose a hundredfold on certain workloads. Every quality lever available, being retrieval, reasoning, agentic decomposition and longer history, is also a consumption lever, so a falling price does not produce a falling cost per task unless consumption is held constant.

How should we account for it?

Where inference supports client delivery it behaves as a variable cost of sales rather than a fixed subscription, and practitioner sources now describe it as a variable line in gross margin. Booking it to technology overhead makes it invisible in engagement profitability, which is precisely where the exposure sits. Classification should be taken with reference to your reporting framework.

Why does this matter more for fixed fees?

Because a fixed price now covers two variable costs and only one is instrumented. Hours are recorded, budgeted and visible in realisation. Inference is typically none of those, and it scales with the same driver, being the difficulty and length of the work, so both move adversely together on the same files.

Which cost lever should we pull first?

Check your cache reuse rate. One source notes that teams reach for quantisation or routing first because those feel like engineering levers, when prompt caching on a high-reuse workload returns more. Caching is also the lever that changes nothing else: routing changes which model answers, quantisation changes precision, caching changes only what you pay for content already sent.

Should we consider running our own infrastructure?

Almost certainly not. Owned serving wins when committed hardware stays near saturation around the clock, and the decisive constraint is not hardware price but permanent staffing for kernels, batching and capacity management to close a reported three to four times gap between stock and tuned deployments. The exception is a hard data-residency constraint, which is a compliance cost rather than a saving.

References

1. Decode the Future. LLM Inference Cost Comparison 2026: API Pricing Guide, on cost being more than headline per-token pricing and comprising input, cached reads and writes, output, reasoning and intermediate turns, tool fees and retries; the recommendation to compare cost per completed task; the production additions of system prompts, retrieved documents, tool schemas, history, cached prefixes, structured outputs, retries and hidden reasoning tokens; separate cache-write and cache-read pricing; maximum turns, tool budget, output budget and hard dollar budget per task with a kill switch; budgeting by workload class with median, ninety-fifth percentile and worst-case caps; the separate line for embeddings, reranking, web search, storage, observability and human review; and cost per request as the primary dashboard view. Note: a commercial publication. decodethefuture.org/en/llm-inference-cost-comparison-2026
2. AI Superior. (2026, March 16). LLM Inference Cost 2026: Complete Pricing Guide, on the cost paradox of tenfold per-token price decline against hundredfold consumption growth for certain workloads, the illustration of a monthly subscription generating comparable inference cost during heavy reasoning, provider responses of capping reasoning tokens and tiered pricing, the five cost-reduction strategies with their claimed multiples, and the March 2026 comparison of achieving a prior frontier performance level at a fraction of the original price. Note: a commercial publication; ratios reported without access to underlying data. aisuperior.com/llm-token-cost
3. Startups.com. (2026, June 10). Inference Cost, lexicon entry, on inference as the operational cost determining application unit economics and scaling with usage, output tokens being four to five times more expensive than input, frontier price ranges, gross margins for AI applications against traditional software norms with two differing ranges given, the reported decline trajectory, and the discipline of tracking monthly and designing pricing for the economics. Note: a commercial lexicon; the two margin ranges are inconsistent within the source. startups.com/lexicon/inference-cost
4. Mirantis. (2026, July 13). Optimizing Inference Costs, on the reported three orders of magnitude spread across budget, mid-tier and frontier pricing bands attributed to a unit-economics guide, and on infrastructure guidance that autoscaling on hardware utilisation alone overprovisions while queue size and batch size align capacity with real load. Note: published by an infrastructure vendor; the pricing bands are reported at second hand. mirantis.com/blog/inference-costs
5. Digital Applied. (2026, May 26). AI Inference Cost Optimization: FinOps Playbook 2026, on inference spend as a variable cost of sales line in gross margin, the claim that caching, batching, routing and quantisation can cut managed API spend by 50 to 90 percent without touching quality, and the sequencing observation that teams reach for quantisation or routing first when prompt caching on a high-reuse workload returns more. Note: published by a consultancy marketing AI transformation engagements. digitalapplied.com/blog/ai-inference-cost-optimization-finops-playbook-2026
6. Silicon Data. (2026, January 22). Understanding LLM Cost Per Token, on batching reducing overhead and increasing utilisation with batch endpoints offered at roughly half of real-time token costs, and on caching preventing repeated processing of static components such as system prompts and repeated context blocks. Note: published by a compute data company. silicondata.com/blog/llm-cost-per-token
7. Featherless. LLM API Pricing Comparison 2026, on the worked routing example distributing requests across three model tiers by complexity with a reported 40 to 50 percent reduction in average cost per request, the observation that quality improvements often do not scale linearly with price, benchmarking specific tasks to find sweet spots, prefix caching of reused system prompts, and quantised models costing less with claimed minimal quality loss. Note: published by a model hosting provider that also markets an alternative pricing structure. featherless.ai/blog/llm-api-pricing-comparison-2026-complete-guide-inference-costs
8. Inworld AI. (2026, July 7). LLM Inference Cost at Scale, on the conditions favouring self-hosting including steady saturation and data residency, cost per token as hardware hourly price divided by tokens actually produced making utilisation dominant, the reported April 2026 hourly list rate range for a current accelerator, continuous batching as the single biggest lever, and the reported three to four times throughput gap between stock and tuned deployments requiring permanent specialist staffing. Note: published by an AI infrastructure company. inworld.ai/resources/llm-inference-cost-at-scale

This article discusses inference pricing and unit economics and is provided for general informational purposes. Every source is a commercial publication with an interest in its conclusions, savings figures are marketing-adjacent and unverified, and prices in this market change frequently. Nothing here is accounting or tax advice, and cost classification should be determined with reference to the applicable reporting framework.