Kate Mead

by Kate Mead

Head of Oracle Centre of Excellence, Version 1

Contents:

Why Oracle introduced a new pricing model
What is included in every Fusion subscription
How AI units work in practice
Purchasing additional AI units 
Non-production environments: A frequently misunderstood area
Agentic applications: A separate production licensing model 
Release 26C and 26D: When billing activates and controls arrive
Things to consider before you commit
A final thought

I’ve been having a lot of conversations with customers about Oracle AI recently, and the same question keeps coming up. Everyone knows AI is the big topic right now, but once you get past the excitement about what agents and agentic applications could do inside Fusion, most people want to know something much more practical: what does it actually cost? 

That question has become more urgent with Release 26C approaching, because that’s the point at which Oracle’s AI pricing model starts billing in earnest. Before 26C, consumption isn’t metered. From 26C onwards, AI Unit usage counts against each customer’s included allocation, and anything beyond that means buying additional units. If you haven’t started thinking about governance and cost management yet, now is the right time. 

This post covers how Oracle’s current pricing model works, what’s included in a standard Fusion subscription, where extra charges can start to appear, and what I think customers should be asking before they commit to agentic AI at scale. 

Laptop on a desk with a glowing euro (€) symbol overlaid in a futuristic interface, surrounded by digital dashboards and analytics graphics, representing AI-driven pricing models, cost optimisation, and automated financial decision-making in a modern tech environment.

Why Oracle introduced a new pricing model

In my view, Oracle had to change the pricing model because the old ways of charging weren’t going to stand up to this next wave of AI. Charging per agent or per token sounds straightforward on paper, but it doesn’t really reflect what happens in practice. Agents work across shared tools, models, and data, and the cost of an interaction can vary quite a bit depending on what you ask them to do. 

So, Oracle has landed on a single consumption measure: the AI Unit. Personally, I think that’s the sensible part. One model across Fusion is easier for customers to get their heads around than a patchwork of different charging rules depending on which product area or type of agent they happen to be using. It also removes the confusion around whether modifications to an agent will make it chargeable. 

What is included in every Fusion subscription

The good news is that Oracle hasn’t put all of this behind a paywall. There’s a baseline level of capability included in a standard Fusion subscription, which gives customers a chance to explore what is possible before making bigger commercial decisions.

That included allocation gives customers a useful starting point, and I think that’s a good thing. It lets teams start experimenting without feeling like they need to sign up to a major commercial commitment on day one. The thing I would caution, though, is that 20,000 AI Units can disappear quickly once teams move beyond light exploration and start using premium models more seriously. And because they don’t roll over, there’s no value in treating them as something to bank for later.

Icon showing a person on a computer as if on a call

Access to pre-built Oracle and partner agents, including those available through the AI Agent Marketplace

Cog icon

20,000 AI Units per month

Icon Enterprise Applications

Oracle AI Agent Studio for building, testing, and publishing agents

Icon of magnifying glass

Built-in observability and analytics

How AI units work in practice

 An AI Unit represents approximately one US cent of AI consumption value, and units are consumed per action or request. In practice, the real cost conversation is less about whether you’re using an Oracle-delivered agent or a custom one, and more about what model sits behind it and how heavy the workload is. 

  • Basic LLM usage: no AI Unit consumption, effectively free 
  • Premium LLM usage: approximately 5 AI Units per action, equating to roughly $0.03 to $0.05 per query 
  • Higher data volume interactions, such as document processing, consume more units per document or page 

This is one of the most important points in the whole model. There is no pricing distinction between seeded Oracle agents, custom-built agents, and marketplace agents. So if you’re trying to estimate cost, I wouldn’t spend too much time focusing on where the agent came from. The bigger question is which LLM you’re using and how complex the work is that you’re asking it to do. 

 If you take one thing from the table below, it should be this: the cost driver isn’t whether the agent is Oracle-seeded, modified, custom, or from the marketplace. It’s the model choice sitting underneath it. 

A comparison table titled “Cost for an agent to perform a general action @ baseline 5 AUs” with four columns: Oracle Seeded, Modified Seeded, Fully Custom, and Marketplace 3rd Party. Two rows are shown. The first row, “LLM Model – Basic LLM (e.g. GPT‑oss),” lists “no charge” under all four columns. The second row, “LLM Model – Premium LLM (e.g. GPT‑5mini),” shows a cost of “5 AUs” under each column.

Purchasing additional AI units

Once you move beyond the included monthly allocation, the conversation shifts from exploration to cost management. That doesn’t mean the model becomes unworkable, but it does mean customers need to treat usage as something to actively monitor rather than something to assume will take care of itself. 

  • Units are sold in $1,000 increments 
  • Units are pooled across the entire contract, not allocated per environment or per module 
  • Purchased units can be consumed at any point during the contract term, providing flexibility for variable or unpredictable demand 

This is where customers need to be careful. Going over the included allocation won’t stop anything running, but spend can creep up if nobody is watching it. In my experience, that’s what catches organisations out: everything appears fine until finance starts asking why consumption has increased. 

AI security concept showing a digital globe with circuit patterns and “AI” interface overlay on a laptop keyboard, representing cybersecurity and data protection.

Non-production environments: A frequently misunderstood area

This is probably the area customers are most likely to overlook. It may sound like a detail, but it can have a real impact on delivery planning, testing cycles, and cost forecasting.

AI Units are consumed across all environments, including development, test, and UAT. There’s no free pass for non-production usage. If a premium LLM is being used during testing or regression, those interactions draw from the same pool as production activity.

The one exception is the Agentic Applications platform fee. That production licensing cost doesn’t apply in non-production, which allows teams to test and validate agentic applications before committing to production rollout. But the underlying AI Unit consumption within those environments is still metered and chargeable.

The takeaway is simple: non-production activity isn’t something you can ignore in your estimates. If you’re using premium LLM-backed functionality during build, test, or UAT, that needs to be treated as part of the commercial picture from the start.

Agentic applications: A separate production licensing model

 This is the part I’d encourage customers to look at very carefully. Beyond the standard AI Unit model, Oracle has introduced a separate subscription for Fusion Agentic Applications. That makes sense if you’re planning to build and run broader, outcome-driven applications in production, but it’s a different level of commercial commitment and it should be tied to a clear business case.

  • 30 million AI Units per year, in addition to the 20,000 monthly units in the base Fusion subscription 
  • The right to publish agentic applications to production environments 
  • Access to the Agentic Applications Builder, a low-code environment that allows users to describe a desired outcome in natural language and have the platform construct the agent workflow 

 Oracle currently offers 22 pre-built agentic applications across ERP, SCM, HCM, and CX, released as part of 26B. These cover use cases including finance operations, logistics, hiring processes, HR help desk, and sales support. 

 AI Agent Studio and the underlying agent tools remain included within the standard Fusion subscription. The Agentic Applications SKU is specifically for production deployment of the broader agentic application layer. 

 In my view, this only makes sense where there’s a clear plan to build and deploy end-to-end agentic applications in production. If you’re mainly looking at embedded agents inside standard Fusion workflows, you may not need to go there straight away. 

Release 26C and 26D: When billing activates and controls arrive

Release 26C is the point at which Oracle’s AI pricing model starts to bite commercially. Organisations currently testing agentic functionality in non-production environments ahead of their 26C upgrade are not yet accumulating billable consumption. That window won’t stay open indefinitely, and governance design ahead of that release boundary is strongly advisable. 

Release 26D introduces budget and cap controls, which is exactly the kind of governance most customers will want before they scale usage. Oracle has also indicated that a usage estimator tool is planned, which should help organisations forecast consumption more confidently. Until those controls are in place, I’d advise customers to be deliberate about how far and how fast they expand premium AI usage.

Things to consider before you commit

The AI Unit model isn’t hard to understand, but it does need some upfront thought. A few things I’d focus on:

Callander Icon

Start with visibility

Understand your current AI Unit consumption, look at which LLMs are in use, and identify where premium models are being selected. That’s the biggest day-to-day cost lever in the model. If you don’t know where premium usage sits, you don’t really know what your future spend could look like.

Icon

Make non-production part of the cost conversation

Testing, UAT, and regression cycles that use premium LLM-backed agents still consume AI Units. They need to be planned and costed as part of delivery, not treated as an afterthought.

Icon Computer Search

Be honest about whether the Agentic Applications SKU is actually needed

It’s a significant investment. If your roadmap is mainly about embedded agents inside standard Fusion workflows, you may not need it yet.

briefcase icon

Get governance in place before 26C, not after it

Once usage is metered, things can move quickly, especially if multiple teams start experimenting at the same time. Until fuller budget controls arrive in 26D, it’s worth putting guardrails in place around premium model use and keeping a close eye on consumption through AI Agent Studio dashboards.

Icon of a hand holding a euro

Include REST and API integrations in your estimates

Programmatic use of Fusion AI capabilities counts as actions and contributes to overall AI Unit usage.

A final thought

My honest view is that this pricing model is manageable once you understand it. The bigger risk isn’t the model itself – it’s organisations moving into agentic AI because the market noise is so loud, without properly understanding what’s being metered, when billing starts, and what guardrails they need to stay in control.

The real challenge is not whether the technology is compelling – it clearly is. It’s how to adopt it in a way that stays commercially sensible, properly governed, and focused on business outcomes. 

If you’re trying to make sense of what Release 26C means for your organisation, estimate likely AI Unit consumption, or decide whether the Agentic Applications SKU genuinely belongs on your roadmap, these are exactly the conversations we’re having with customers now.  Contact us today to help you work through it. 

Further reading