The first watsonx invoice that surprises a team is almost never the token line. It is a charge of 1,110 dollars for a Standard plan instance fee nobody remembers switching on, parked right next to a few dollars of real inference. The tokens were cheap. The plan was not.
Cost governance on watsonx is mostly about knowing which of three meters is running, and when. Get that wrong and you either overpay for a plan you do not use, or you let idle deployments quietly bleed compute for weeks. This part is the FinOps map: what each meter measures, how to turn a token count into a dollar figure, and where I put the guardrails before a project scales.
Key takeaways
watsonx.ai Runtime meters three separate things: tokens as Resource Units, where 1,000 tokens is 1 RU; compute as Capacity Unit Hours (CUH); and a flat monthly instance fee on some plans. For light inference on small Granite models, the instance fee is far larger than the token cost, so the Essentials pay as you go plan usually wins. Standard earns its 1,110 dollar fee only when you actually consume its 2,500 included CUH on tuning, batch scoring, and always on deployments. Tag every project, cap RU and CUH per deployment space, and set an alert before month end, not after.
How watsonx charges you, in three meters
Every dollar on a watsonx.ai bill comes from one of three meters, and they do not measure the same thing. Confusing them is how budgets blow up.
Resource Units (RU) measure foundation model inference. One RU is 1,000 tokens, counting input and output at the same rate. IBM rounds your monthly token total up to the nearest 1,000, divides by 1,000 to get RUs, then multiplies by the model price. The base RU price is 0.0001 dollars, and every model is priced as a multiple of that base. A small Granite model sits near the bottom of the range at roughly 0.60 dollars per million tokens; the largest third party models on the catalog reach about 20 dollars per million. That is a 33 times spread on the exact same token count.
Capacity Unit Hours (CUH) measure compute time, not tokens. You spend CUH when you train an AutoAI model, run a machine learning model, score a deployment, or run a tuning experiment in a GPU environment. CUH is where the cost of keeping things running lives, and it is easy to miss because it accrues by the hour whether or not anyone is calling the endpoint.
The instance fee is a flat monthly charge that some plans carry regardless of usage. The Standard plan is 1,110 dollars per month and includes a block of 2,500 CUH. The HIPAA-Ready plan is 1,800 dollars per month and is offered in the Dallas region only. IBM is explicit that the instance fee is billed even if you consume nothing but a handful of RUs, and it is pro rated if you cancel mid month. If you have read Part 5 on pricing and plan tiers, this is the same machinery seen through a FinOps lens.
flowchart LR Tokens[Prompt tokens] --> RU[Resource Units] RU --> Bill[Monthly bill] Deploy[Online deployment] --> CUH[Capacity Unit Hours] Tune[Tuning run in GPU env] --> CUH CUH --> Bill Plan[Plan instance fee] --> Bill
Which plan actually costs less?
There are four watsonx.ai Runtime plans, and the right one depends almost entirely on how much CUH you burn, not how many tokens you push. Here is what each includes.
| Plan | Instance fee | Included CUH | Free tokens | Rate limit |
|---|---|---|---|---|
| Lite | Free | 20 CUH per month | 300,000 per month | 2 req per sec |
| Essentials | None | Pay per CUH used | Billed in RU | 8 req per sec |
| Standard | 1,110 dollars per month | 2,500 CUH included | Billed in RU | 8 req per sec |
| HIPAA-Ready | 1,800 dollars per month | Pay per CUH, Standard rate | Billed in RU | 8 req per sec |
The decision splits cleanly. Lite is for evaluation and small proofs of concept, and it caps you at 300,000 tokens and 20 CUH a month, with no tuning. Essentials is pure pay as you go with no floor, so a project that only does inference pays for exactly what it uses. Standard is a commitment: you pay 1,110 dollars whether you use it or not, and in return you get 2,500 CUH bundled in and a place to run custom foundation models billed hourly.
My rule is simple. If your workload is inference only on small Granite models, stay on Essentials until something forces you off it. The Standard instance fee alone would buy you well over a billion tokens of small Granite inference, so paying it before you have heavy CUH usage is money set on fire. The moment you start tuning, running always on deployments, or scoring large batches, the CUH block flips the math and Standard starts paying for itself.
Turn a token count into a monthly number
The RU calculation is short enough to do in your head, and doing it early saves arguments later. Round tokens up to the nearest 1,000, divide by 1,000 for RUs, multiply by the model price. That is the whole formula.
Worked example
A support assistant handles 60 million tokens a month on a small Granite model priced at 0.60 dollars per million, which is 0.0006 dollars per RU. That is 60,000 RU. The token bill is 60,000 times 0.0006, or 36 dollars.
On Essentials the total is 36 dollars plus whatever CUH the deployment consumed. On Standard the same 36 dollars of inference sits under a 1,110 dollar instance fee, so the bill is 1,146 dollars. Same tokens, same model, a 31 times difference driven entirely by the plan. For this workload Essentials is the obvious choice until CUH heavy work arrives.
If you want this baked into a planning script rather than a napkin, here is a small estimator. It has no external calls, so you can run it as is and it will print the crossover between Essentials and Standard for a small Granite model.
# watsonx RU cost estimator, pure python, no api calls
import math
BASE_RU_USD = 0.0001 # one resource unit is 1000 tokens
GRANITE_SMALL_MULT = 6 # small granite approx 6x base, 0.0006 per RU
STANDARD_FEE = 1110.0 # flat monthly instance fee
def ru_cost(tokens, price_per_ru):
rus = math.ceil(tokens / 1000) # round up to nearest 1000 tokens
return rus * price_per_ru
def monthly_bill(tokens, price_per_ru, plan):
inference = ru_cost(tokens, price_per_ru)
fee = STANDARD_FEE if plan == 'standard' else 0.0
return round(fee + inference, 2)
price = BASE_RU_USD * GRANITE_SMALL_MULT
for millions in (10, 100, 1000):
tok = millions * 1_000_000
ess = monthly_bill(tok, price, 'essentials')
std = monthly_bill(tok, price, 'standard')
print(millions, 'M tokens essentials', ess, ' standard', std)100 M tokens essentials 60.0 standard 1170.0
1000 M tokens essentials 600.0 standard 1710.0
The failure mode to watch: if you paste in a large model multiplier, say 200 for a 0.02 dollar per RU model, Essentials at a billion tokens jumps to 20,000 dollars and the plan fee stops mattering at all. At that point model choice, not plan choice, owns your budget. That is the next section.
Pick the model by its RU price
Token cost scales linearly with the model multiplier, so a single model choice can swing a bill by more than an order of magnitude. The chart below holds volume fixed at 100 million tokens a month and varies only the model price across IBM stated band, from small Granite near 0.60 dollars per million to the top of the catalog near 20 dollars per million.
The practical read: default to the smallest Granite model that clears your quality bar, and only reach for a premium model on the requests that genuinely need it. Routing cheap traffic to a small model and hard traffic to a large one is the single biggest RU saving most teams have available, and it costs nothing but a router. The Granite licensing part covers which models carry IBM indemnification, which matters when you are choosing what to standardise on.
Where CUH quietly leaks
Token cost is visible because it tracks traffic. CUH is the meter that surprises people, because it runs on wall clock time. Three things burn it, and two of them do so even when no one is using your app.
This is why the plan choice hinges on CUH and not tokens. If your team tunes Granite models regularly, or keeps several always on endpoints, the 2,500 CUH bundled into Standard can be cheaper than metering every hour on Essentials. If you do neither, that bundle is a bill for capacity you never touch. Look at your last three months of CUH consumption before you commit; the usage dashboard has the number.
| Workload | Main meter | Monthly cost driver | Cheaper plan |
|---|---|---|---|
| Inference only assistant, 60M tokens small Granite | RU | About 36 dollars in tokens | Essentials |
| RAG service, 120M tokens mid model, one endpoint | RU plus CUH | Tokens plus deployment hours | Essentials, usually |
| Regular tuning plus several always on endpoints | CUH | GPU tuning hours plus idle deployment CUH | Standard |
Tag, budget, and alert before you scale
Cost governance is not a monthly spreadsheet, it is a few controls you set once so the bill cannot surprise you. Four of them do most of the work on watsonx.
Tag by project and environment. Put every watsonx instance and deployment space behind IBM Cloud resource tags so you can split the bill by team and by dev versus prod. Without tags, a shared account is one undifferentiated number and no one owns it.
Separate the meters per space. Keep tuning and batch work in their own deployment space, away from the inference endpoints. When RU and CUH are mixed in one space you cannot tell a token spike from a compute leak, and the alert you set fires on the wrong signal.
Set spending notifications in IBM Cloud billing. A budget alert at a chosen threshold turns a month end shock into a mid month heads up. Set it below your expected total, not at it, so you have room to react.
Review deployments weekly. The single cheapest habit is a Friday sweep that deletes stale endpoints. Governance and evaluation are workloads too, as Part 19 on watsonx.governance showed, so fold their CUH into the same review.
watsonx.data and watsonx.governance bill separately
One trap in watsonx budgeting is treating watsonx.ai Runtime as the whole bill. It is one line of three. A real RAG stack also runs watsonx.data, the lakehouse and Milvus vector store that holds your embeddings and answers retrieval queries, and that service carries its own charges for the compute it runs, largely metered in Resource Units of its own. If you push governance into production, watsonx.governance is a separate billable service too, with its own metering for the monitoring and factsheet work covered in Part 19.
The FinOps consequence is that platform total cost of ownership is the sum of those services, not the inference line alone. When I size a governed RAG application I budget three buckets: watsonx.ai for inference and any tuning, watsonx.data for the vector store and query engine that Part 9 built, and watsonx.governance for the monitoring layer. Miss one and your forecast is low before you start. Exact watsonx.data and watsonx.governance rates depend on the plan and region you provision, so pull them from the IBM Cloud catalog for your own account rather than assuming they match the watsonx.ai rates.
Where I cap watsonx spend first
Start every new watsonx workload on Essentials. Pay as you go removes the single most common waste, a 1,110 dollar fee against a project that only does inference. Route traffic to the smallest Granite model that clears quality, and keep a premium model in reserve for the requests that earn it. Those two moves cover most of the bill before you have written a governance policy.
Move to Standard only when a real CUH pattern shows up: repeated tuning, batch scoring, or several endpoints you cannot let idle. Let the last three months of CUH usage make that call, not a forecast. And put the four controls in on day one, because tags you add after the fact never cover the month you actually needed them for.
Next in the series builds on this: Part 21 on responsible AI and EU AI Act readiness turns the governed, budgeted platform into one you can defend to an auditor. For a cross cloud view of the same discipline, compare this with Amazon Bedrock cost governance. Your action this week: pull your last three months of CUH from the IBM Cloud usage dashboard and check whether your plan matches your pattern.
References
- watsonx.ai Runtime service plans, IBM Documentation
- Billing details for generative AI assets, IBM Documentation
- IBM watsonx.ai pricing
About The Author
DrJha