Designing Credit Pricing for Fine-Tuned and Custom AI Models

A finance lead who fine-tunes a model expects one bill. What arrives instead is two bills with different shapes, arriving on different schedules, and nothing in standard token pricing warns them this is coming. That gap between what teams budget for and what they actually owe is the subject of this piece, and the cause sits in the pricing architecture itself, not in any provider's bad faith.

Why fine-tuned models break standard token pricing

Per-token pricing was built for a simple transaction: a customer calls an endpoint, tokens get counted, a rate gets applied. One meter, one rhythm, one invoice that looks roughly like the last one. Fine-tuning breaks that rhythm into two separate events, and they behave nothing alike. The first is training: a one-time charge, billed per token of training data, scaled by model size and method. The second is inference: a charge that starts the moment the model goes live and continues for as long as the model stays in production, with no natural endpoint.

A team that fine-tunes a model on a cloud platform pays one bill to build it and a structurally different, ongoing bill to run it, and those two bills often don't even share a meter. Training gets billed per token of training data processed. Inference on the resulting model can carry a premium over base-model rates, as some providers charge, or stay flat for older models while carrying a premium for newer ones, as Google does for Gemini 3 and later on Vertex AI, or skip token billing entirely in favor of a dedicated GPU-hour meter, as Together AI does for fine-tuned model hosting. Three providers, three different answers to the same question, and none of them map cleanly onto a single per-token rate card.

The training invoice tells a buyer almost nothing about what the model will cost to operate. A low training bill can sit in front of a high and climbing inference bill, and a buyer who reads only the first number is misjudging what the model will actually cost to run. Industry cost guidance on fine-tuned deployment backs this up directly: for teams running real production traffic, inference spend overtakes training spend within weeks of launch, not months. The cost of fine-tuning is a curve that keeps climbing after the invoice that announced it has already been paid.

The multi-dimensional complexity that compounds the two-event problem

The two-event split is only the first layer of the problem. Inside each event sit several more variables that move independently of each other, and no single token rate can hold all of them without flattening information a buyer needs in order to plan.

Training cost swings on at least three axes that have nothing to do with each other. Model size and architecture matter first: training a small model and training a much larger one on the identical dataset produce wildly different bills, even before any other variable changes. Method matters just as much. Supervised fine-tuning, LoRA and QLoRA (parameter-efficient approaches that train a small adapter rather than touching the full set of weights), and reinforcement-learning methods like GRPO all carry different compute demands and different prices as a result. LoRA cuts training cost sharply compared to full fine-tuning, and some providers price DPO, another reinforcement-learning method, at a multiple of standard SFT rates. Epoch count adds a third axis: training cost scales with how many times the model passes over the full dataset, and most real jobs run several epochs, so the training price functions as a multiplier rather than a flat number.

Inference carries its own spread. The gap between a provider's cheapest and most expensive model tier can be large on its own, and when a fine-tuned model sits on top of a premium base model, the inference premium stacks on top of that gap rather than replacing it. Deployment mode cuts across all of this as a separate dimension. Serverless inference, paid per token with no reserved capacity, and dedicated GPU-hour billing, paid for the instance whether it's busy or idle, are two different cost structures applied to the same underlying model. Together AI runs its fine-tuned models on dedicated endpoints billed by the GPU-hour rather than by the token. The same model can carry two entirely different cost logics depending on where it's hosted. Agent workloads compound the problem further still: a single user task can fan out into hundreds of downstream model calls, so even a clean per-token rate stops functioning as a usable planning number once agents start making decisions on a customer's behalf.

A buyer trying to answer a simple question, what will this model cost per month, has to multiply across model tier, method, epoch count, inference premium, deployment mode, and task volume at once; the answer shifts the moment any single variable moves. Per-token pricing is precise enough to measure every one of these variables but too fragmented to communicate, budget against, or package into an enterprise contract. That's the gap a different kind of pricing layer has to close.

What credit pricing does architecturally that token pricing cannot

Credits are not a payment wrapper placed on top of token billing. They function as a pricing abstraction that re-encodes all of that dimensionality into one unit with a stable, predictable exchange rate, shifting complexity onto the provider's side of the ledger so the buyer faces consistency instead of variability.

The architectural shift is a transfer of risk. Per-token pricing hands cost risk straight to the customer: spend tracks usage exactly, and usage swings with every one of the variables described above. Credit pricing moves exchange-rate risk onto the vendor instead: the vendor sets the credit-to-compute mapping and absorbs whatever internal cost shifts happen beneath it. A credit, in its simplest form, is a unit of prepaid value tied to some amount of compute consumption. But building that mapping well takes more than a prepaid balance and a deduction script. A working credit system sits at the intersection of three separate systems: the pricing logic that decides what one credit costs, the metering layer that decides what consumption one credit actually represents, and the financial ledger that decides how unused credits get recognized as revenue.

For fine-tuned models, this structure gives training and inference a clean, separate home. Training credits can be defined as a one-time charge, scoped to the specific model size and method, consumed once at the point a job runs. You can define inference credits as a recurring burn rate: scoped to model tier and deployment mode, it gets consumed on every request the deployed model handles. The buyer sees two line items on a statement instead of a scattered set of per-token rates spread across two billing events that may not even share a platform.

Credits absorb model-tier complexity the same way. Where the internal cost spread between a provider's cheapest and most expensive model is wide, the credit-to-cost mapping sets the exchange rate, and the buyer sees a burn rate per tier rather than the raw compute differential sitting behind it. Because a credit can represent a token, an image, a minute of audio, or an outcome such as a document classified or a support ticket resolved, the same unit can carry value-based or outcome-based pricing in a way a token rate structurally cannot. That flexibility is also the trap. Teams that treat credits as nothing more than a column in Postgres, a cron job, and a finance team reconciling spreadsheets every month tend to discover at scale that they've built a billing system by accident. A credit system built on purpose, with metering and billing infrastructure designed for exactly this kind of multi-event, multi-dimensional pricing, treats the credit layer as a pricing architecture decision and a software architecture decision at the same time, because it is both.

Designing the credit schema: mapping training and inference to distinct credit mechanics

A workable credit schema for custom models takes deliberate decisions about how credits get granted, how they burn across two structurally different event types, and what rules apply at the edges. When fine-tuned model complexity enters the picture, defaults carried over from subscription billing or simple API metering tend to fail.

Grant mechanics come first: how credits enter a customer's wallet. Prepaid packs work well for training events, since the cost is knowable in advance. Model size, dataset size in tokens, and epoch count combine into a fairly deterministic estimate before the job ever runs. Promotional or free credits, granted for onboarding, trials, or volume commitments, need clear expiry rules and a defined consumption order, so a provider decides up front whether promotional credits burn before prepaid ones or after. Committed credit pools suit enterprise contracts that pre-purchase a volume of credits at a negotiated rate and draw down against a single pool across both training and inference events.

Burn mechanics differ sharply between the two event types. Training is a discrete, bounded job, so its credit cost should be calculated and reserved at the moment a job gets submitted, not deducted piece by piece as the job runs. That reservation protects both sides: the customer doesn't run out of credits mid-training, and the provider doesn't absorb a compute cost it can never recover. The credit cost of that job has to encode method (LoRA against full fine-tuning against GRPO), model size, and epoch count, since those are the variables actually driving compute cost. If a flat training credit ignores method, it produces margin surprises once volume scales up.

Inference runs on the opposite logic: a continuous, unbounded burn that deducts per request or per token batch, with a rate that has to reflect whichever model tier the custom model is running on. If a provider charges an inference premium for fine-tuned models above base-model rates, that premium belongs inside a higher credit burn rate per token rather than as a separate line, so the customer looks at one balance instead of several. Dedicated GPU-hour deployment, relevant for high-volume fine-tuned serving, can be expressed as a fixed credit burn per hour no matter the utilization, so the customer gets a predictable daily cost even under uneven traffic.

Edge cases need explicit rules rather than inherited defaults. A wallet that hits zero needs a defined response: does inference stop outright, does it continue with a metered overage bill, or does it trigger a top-up prompt before anything breaks? Unused training credits from a job that was planned but never run need a stated fate: expiry, rollover, or conversion into inference credits. If a tiered burn rate charges less for batch or offline inference than for real-time inference, customers get a lever to shift non-urgent workloads onto cheaper execution paths, and building that lever into the schema up front means you avoid reworking the whole pricing model later. The schema also doubles as the interface between pricing and finance: unused prepaid credits sit as deferred revenue until consumed, and any contract change, a new model tier, a revised burn rate, has to be tracked against which credits were granted under which terms.

Credit-tier design at production scale: the Microsoft Copilot migration

Microsoft's shift to usage-based, credit-metered billing across Copilot Studio, Microsoft Foundry, and Copilot Cowork, effective July 1, 2026, shows these design decisions playing out at enterprise scale, along with the tensions that come with them.

The schema encodes model-tier complexity directly into the credit system: Microsoft's documentation describes a substantial gap in credit consumption between basic and premium AI tools within the same product family, so a customer's burn rate depends on which model tier a given workload happens to land on. The billing structure for reasoning-capable models makes the compounding explicit rather than hiding it. Microsoft's own billing documentation states that when an agent uses a reasoning-capable language model, Copilot Studio bills through two separate meters at once, a feature rate and a premium token rate for text and generative AI tools. That double charge is a deliberate schema decision meant to surface the real compound cost of advanced inference.

The lesson for schema design is direct. Model-tier differentiation has to live inside the credit burn rate itself rather than hide behind a single blended rate, because a unified rate against a wide cost spread produces serious margin distortion. Compound events, a feature call paired with a token call, need compound burn rules defined before the fact, not worked out case by case at invoice time. And enterprise customers living through this migration had to reforecast their AI spend from a fixed monthly seat cost to a variable credit burn, a shift where metering transparency and migration tooling determined whether the change produced churn or acceptance.

A parallel pressure arrived from a different direction. OpenAI announced a wind-down of its fine-tuning platform on May 7, 2026, with new job creation ending January 6, 2027, and organizations with no recent fine-tuned inference activity blocked starting July 2, 2026. If teams built on proprietary fine-tuned models without access to their own weights or adapters, they have nothing portable to carry forward. Their only path is to rebuild from their original training data on an open-weight platform before the underlying base model gets deprecated. Teams that instead kept open-model fine-tuning pipelines, running LoRA on Llama, Qwen, or Mistral through providers like Together AI or Fireworks, kept their models portable through the same transition.

The pricing consequence runs straight back into schema design. The durable path for custom models now points toward open-model LoRA served on provider infrastructure or self-hosted, so the credit schema built for that path has to account for dedicated GPU-hour billing rather than per-token inference, and that changes the underlying burn mechanics substantially. If a credit schema ties too tightly to one proprietary provider's billing model, it carries the same lock-in risk that the OpenAI wind-down just exposed.

Hybrid pricing structures that sit underneath the credit layer

Credits solve dimensionality, but they don't by themselves guarantee a buyer can plan spend with confidence. Buyers of custom AI models need a committed base that caps downside risk, so credits in production almost always sit inside a hybrid structure that combines a fixed component with variable credit drawdown.

The tension is straightforward: pure credit billing gives a provider cash up front and gives a buyer cost predictability per unit consumed, but it gives the buyer no ceiling on total spend and no floor guaranteeing the model stays available. Enterprise procurement generally needs both of those guarantees at once, not one or the other. The structure that has become standard pairs committed seats or tiers, or an enterprise credit pool priced at a negotiated rate, as the fixed base, with metered usage credits covering consumption above or outside that committed volume.

For fine-tuned model products, that pairing maps onto the two-event structure directly. A committed component, a model hosting fee or a reserved GPU-hour commitment, guarantees the custom model stays deployed and available no matter how traffic moves week to week; it functions as the dedicated floor underneath a variable credit layer that handles everything above it. That floor is what turns a credit schema from a clever metering trick into something an enterprise buyer can actually sign a contract around, because it tells the buyer what the deployment will cost, reliably, every month, no matter how the workload moves.