The line on the invoice read 1,110 US dollars, in a month the team had barely run a prompt. Nobody had done anything wrong. That is the watsonx.ai Standard plan doing exactly what it says, and it is the first thing to understand before you commit a budget: the fixed fee is charged whether or not you touch the compute it buys you. Get the plan wrong and you either pay a fee you are not using, or you build on pay as you go and watch the compute bill drift past what a flat fee would have cost. This part is about reading the two meters watsonx.ai runs, so you can put a real number against the deployment choice you made in Part 4.

We have been building toward this. Part 1 mapped the stack, Part 3 picked a model and read its license, and Part 4 mentioned CUH and RU in passing and promised to take them apart here. Every figure below is from the IBM watsonx.ai pricing page and the Runtime service plans documentation as of this writing. Prices move and vary by country, so treat the shapes as durable and the exact dollars as a snapshot to reconfirm before you sign anything.

Two meters on one invoice

The single biggest source of bill confusion on watsonx.ai is that one platform bills two different things two different ways, and they land on the same invoice. Separate them once and the rest of pricing falls into place. The first meter is the Capacity Unit Hour. A CUH measures the compute time of watsonx.ai Runtime work, the jobs that run on a compute environment: tuning experiments, AutoAI, machine learning model scoring, batch pipelines. If you kept a GPU or CPU environment busy for an hour, you spent capacity, and CUH is how that capacity is counted. The rate depends on the environment you chose and the plan you are on.

The second meter is the Resource Unit. An RU measures foundation model inference by tokens, and one RU is 1,000 tokens counting both what you send and what the model returns. When your application calls Granite to answer a question, you pay in RU, not CUH. This split trips people up because both feel like the model doing work, but watsonx.ai draws the line at what kind of work it is: serving a prompt is inference and bills in RU, while tuning that same model or scoring an ML pipeline is compute and bills in CUH. A third case sits beside them, custom foundation models and on demand model hosting, which bill by the hour against the GPU configuration you reserve. Keep those three buckets straight and no invoice will surprise you.

flowchart TD
  A[Billable activity] --> B{Foundation model inference}
  B -->|Yes| RU[Resource Units, 1000 tokens each]
  B -->|No| C{Runtime compute}
  C -->|Tuning, AutoAI, scoring, pipelines| CUH[Capacity Unit Hours]
  C -->|Custom model hosting| HR[Hourly by GPU config]

What a Capacity Unit Hour measures

A Capacity Unit Hour is watsonx.ai Runtime, the service that used to be called Watson Machine Learning, charging you for compute you held. The exact CUH you burn depends on the environment behind the job, because a small CPU environment and a large GPU environment consume capacity at different rates per wall clock hour. That is why IBM notes CUH pricing depends on the environment and tools used within a billing month. The plan you are on sets the price of a CUH. On Essentials a Capacity Unit Hour is 0.55 US dollars. On Standard it is 0.45 US dollars, and the Standard fee comes with a block of 2,500 of them already paid for.

Notice what that difference does. Standard charges less per CUH than Essentials, 0.45 against 0.55, and hands you 2,500 of them inside the monthly fee. Divide the 1,110 US dollar fee by 2,500 and each included CUH costs about 0.44 US dollars, right at the Standard overage rate. So the fee is not a markup on the block, it is the block priced at the Standard rate up front. The whole plan decision, which I get to below, comes down to whether you will actually use enough of that included compute to make the flat fee cheaper than paying 0.55 a CUH as you go. Lite, the free plan, gives you 20 CUH a month, which is enough to try a small tuning job and nothing more.

Resource Units and the token bill

Inference is the meter most teams watch, because it scales with traffic. One RU is 1,000 tokens, input and output added together, so a call that sends 900 tokens and gets back 100 is exactly 1 RU. The price of an RU is the price of the model, and models range widely. A small Granite model costs a fraction of a large third party one for the same token count, which is the lever you pull when an inference bill runs hot. IBM publishes model prices per million tokens, so dividing by 1,000 gives the per RU figure your capacity math needs. The table below converts a few current models so you can see the spread.

Newer models price input and output separately, as granite-4-h-small does at 0.06 US dollars input and 0.25 output per million tokens, so read the model card for the split. Rates are indicative and change; confirm on the IBM pricing page. Embedding models are a flat 0.106 US dollars per million tokens.

One point I made in Part 3 is worth repeating in cost terms. The RU rate is set by the model, not by the plan. Whether you sit on Essentials or Standard, granite-3-8b-instruct costs the same 0.0002 US dollars an RU. Plans change the price of compute and the limits around you, not the price of a token. So the model you pick controls your inference bill, and the plan you pick controls your compute bill. Two decisions, two meters, and they do not overlap.

Four plans, and what each fee buys

watsonx.ai Runtime sells four SaaS plans, and you choose one per instance. Lite is the free tier for evaluation, capped at 20 CUH and 300,000 tokens a month with a 2 request per second rate limit, and it cannot run a foundation model tuning experiment. Essentials is pay as you go with no fixed fee, an 8 request per second limit, and it is where most pilots belong. Standard is the enterprise plan at 1,110 US dollars a month with 2,500 CUH included, the same 8 requests per second, and it is the plan that unlocks LoRA fine tuning and custom foundation models. HIPAA-Ready is Standard with a compliance wrapper at 1,800 US dollars a month, available only in the Dallas region and only after you sign a Business Associate Addendum with IBM.

Foundation model inference is billed in Resource Units on every plan. The Standard instance fee is charged even in a month where you consume no CUH. Confirm current terms on the IBM watsonx.ai pricing page.

Which plan fits which workload?

Here is the only calculation that decides Essentials against Standard, and it is about compute, not tokens. Essentials charges 0.55 US dollars a CUH with no fee. Standard charges a flat 1,110 US dollars that covers the first 2,500 CUH, then 0.45 a CUH beyond. Below the break-even, Essentials is cheaper because you skip the fee. Find the break-even by asking how many CUH at 0.55 equal the 1,110 fee: 1,110 divided by 0.55 is about 2,018. So at roughly 2,020 CUH a month the two plans cost the same on compute, and above it Standard pulls ahead, both because the fee is now worth it and because every extra CUH is 0.45 instead of 0.55.

That 2,020 CUH figure is the number to carry out of this part. It is not a token count and it is not about traffic; a chatbot that serves millions of prompts but never tunes a model may sit on Essentials forever, because inference bills in RU and RU is priced the same on both plans. Standard earns its fee when your Runtime compute, the tuning runs, the AutoAI jobs, the batch scoring, climbs past that block. The chart plots both plans so you can see where the lines cross.

Put a real number on it before you commit

You do not have to do that arithmetic by hand every time. The snippet below takes your monthly token volume and your monthly CUH, applies the published rates, and prints the total for each plan plus which one to pick. Change the two input numbers to your own forecast and run it. It is the same math as the worked example, so it should agree.

# watsonx.ai SaaS monthly cost: Essentials vs Standard
# Rates from the IBM watsonx.ai pricing page; reconfirm before you budget.
STD_FEE = 1110.0            # Standard monthly instance fee (USD)
STD_INCLUDED_CUH = 2500     # CUH included in the Standard fee
CUH_ESSENTIALS = 0.55       # USD per CUH on Essentials
CUH_STANDARD = 0.45         # USD per CUH on Standard, above the block
MODEL_RATE_PER_1K = 0.0002  # granite-3-8b-instruct, USD per 1000 tokens (1 RU)

monthly_tokens = 2_000_000_000   # 2 billion tokens of inference
monthly_cuh = 3000               # tuning, scoring, pipelines

ru = monthly_tokens / 1000
inference = ru * MODEL_RATE_PER_1K            # equal on both plans
essentials = inference + monthly_cuh * CUH_ESSENTIALS
overage = max(0, monthly_cuh - STD_INCLUDED_CUH)
standard = inference + STD_FEE + overage * CUH_STANDARD
pick = 'Standard' if standard < essentials else 'Essentials'

print('Inference RU:', round(ru))
print('Inference USD:', round(inference, 2), '(same on both plans)')
print('Essentials total USD:', round(essentials, 2))
print('Standard total USD:', round(standard, 2))
print('Pick:', pick)

Expected output: Inference RU: 2000000, Inference USD: 400.0 (same on both plans), Essentials total USD: 2050.0, Standard total USD: 1735.0, Pick: Standard. Failure modes: if you swap in a model that prices input and output separately, one flat MODEL_RATE_PER_1K understates the bill, so split the token counts and rates; if your CUH rate differs by environment, the two constants here are the plan floor, not a guarantee, so pull your real rate from the invoice; and remember this ignores support add ons and text extraction, which bill on their own lines.

Where the pricing quietly bites

A few edges catch teams after the invoice, not before. The Standard fee is charged in full even in a month where you run zero CUH, so an instance you provisioned for a project that slipped is still 1,110 US dollars a month until you cancel it. Moving up is a one way door: once you upgrade an instance from Essentials to Standard you cannot revert it, you have to create a new instance on the lower plan and migrate. And two capabilities are simply gated. LoRA fine tuning and custom foundation models do not exist on Essentials at all, so if your roadmap includes tuning your own weights, Standard is not a cost optimization, it is a prerequisite.

HIPAA-Ready has its own fences. It lives only in the Dallas region, it needs a signed Business Associate Addendum before the plan even appears in your catalog, and it drops some features that Standard has, so read the supported feature list before you assume parity. None of this is hidden, but all of it sits in documentation you only find after you have committed, which is exactly when it costs the most to learn. For how another cloud structures the same on demand against reserved trade off, the AWS take in Amazon Bedrock pricing across on-demand, provisioned, and batch is worth a read alongside this.

How I would pick a plan, and the number that decides it

My rule is short. Start every project on Essentials, unless a compliance rule forces HIPAA-Ready or your roadmap needs LoRA tuning on day one, in which case go straight to Standard because those features do not exist below it. Then watch one number, your monthly CUH. The month it crosses about 2,020 and looks like it will stay there, move to Standard and take the lower 0.45 rate and the included block. Do not move for a single spiky month, because the upgrade is one way and a fee you cannot escape is worse than a slightly high pay as you go bill.

Keep the two meters separate in your head and the whole model stays simple. Your model choice sets the RU bill and scales with traffic. Your plan choice sets the CUH bill and scales with tuning and pipelines. Optimize each on its own axis, do not let a big inference bill push you toward a plan change that only affects compute, and do not let the flat fee tempt you before your compute earns it. That is the discipline that keeps a watsonx.ai bill boring, which is the only kind of bill you want.

Do one thing before Part 6. Open your instance, read last month's CUH from the usage view, and write it next to the 2,020 break-even. That single comparison tells you whether you are on the right plan today. Part 6 leaves SaaS pricing behind and gets into GPUs and running watsonx.ai on OpenShift, where the meter is your own hardware and the sizing is the bill.

References

IBM watsonx.ai pricing
IBM docs: watsonx.ai Runtime service plans
IBM docs: billing details for generative AI assets
IBM docs: billing details for machine learning assets

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts