Fusion Claw Is Arriving in 26D. Here Is What We Are Doing Before "Turning it On".

Fusion Claw Is Arriving in 26D. Here Is Why We Are Not Turning It On Just Yet.

Visible is not the same as approved. The governance conversation to have before your first Claw run.

Oracle associated Fusion Claw with 26D. Customers in the early access cohort should see it first, and everyone else gets it with their cohort's release.

One practical detail: Oracle told us some of the capability did not make the initial general availability build, so an environment on 26D may still need a weekly CWB update. Oracle offered to look at our environment with us and confirm whether the required build is present. I would recommend asking for the same.

The model question

Fusion Claw requires frontier models. Oracle told us plainly that GPT-OSS, the model it hosts at a zero multiplier, is not capable enough for it. And if you use it, it will call a frontier model hosted by OpenAI.

If your organization approved Fusion AI on the basis of Oracle-hosted models, Fusion Claw is a new conversation, not a footnote to the old one.

There was a useful nuance here that I suspect many people have not considered. Even GPT-OSS runs outside your Fusion tenancy. Oracle hosts it in OCI data centers in Chicago and Frankfurt, and Fusion calls out to it. So the real question was never inside the tenancy versus outside it. It is Oracle-operated versus third-party operated.

For many organizations, there is precedent. Plenty of us already use frontier models hosted by third parties through other tools. Precedent makes the review easier. It does not make it unnecessary.

Oracle has documentation describing how data flows to LLMs and told us it has used it to help other customers, including defense and government customers, work through the same concerns. Get it into your review early.

What you can point to in that review

The good news is that Oracle has given security and architecture teams quite a lot to work with. Based on what was described to us:

·        User-token enforcement. All data access and actions use the invoking user's token and functional rights.

·        Layered roles. Users need the role for each agent and for the agentic app. App access does not grant missing agent access.

·        Capability scoping. Authors decide which agents and capabilities a Claw can use.

·        No credential custody. The Claw plans and orchestrates. Agents execute.

·        Private runtime. Generated code runs in a private container hosted by Oracle in OCI.

·        Configurable retention. Session state is kept for up to 90 days, and you can set that period.

·        Tenant-specific learning. Self-learning stays within your tenant and is tied to the specific outcome.

·        Budgets and a kill switch. Agent Studio in 26D supports budgets at environment, app, and agent level, plus a kill-all control.

What we are still asking

We sent Oracle a written list of follow-up questions. The ones I expect any review board to ask:

·        Can an administrator disable Claw outcomes at the tenant, environment, or role level, rather than relying on instruction alone?

·        How is the user's identity handled across sessions that run for hours or days, and what happens if their roles change mid-run?

·        What does the Outcome Receipt described in the announcement contain, how long is it kept, and can it be exported for audit?

·        Is code generated by the Claw logged and reviewable?

·        Where is business data retrieved into the container held, how is it encrypted, and how is it purged?

·        Which models are available, and can a specific model and version be pinned?

I will share what we learn.

Where to experiment instead

One of our architects asked whether we could get a separate Fusion demo environment for this kind of work. It has historically been difficult to get one. Oracle told us there is now a SKU for it.

That matters more than it sounds. Even an internal sandbox with elevated access is still constrained by your own data and your own approvals. For a capability like this, a greenfield environment is the right place to learn how it behaves before it ever touches yours.

The sequence we landed on

1.      Confirm with Oracle whether your environment has the required build, and treat visibility as information rather than permission.

2.      Get Oracle's LLM data-flow documentation in front of your security and architecture reviewers.

3.      Decide who is allowed to author outcomes and who is allowed to run them, and design the roles to match.

4.      Set budgets in Agent Studio before the first run.

5.      Experiment in a separate demo environment.

6.      Only then move toward a pilot with your own data.

If you are heading to Oracle AI World in Las Vegas, October 25 to 28, Oracle pointed us to the keynotes, a roadmap session from the product team, and the Fusion Claw Meet the Experts session. We will be there with a lot of questions.

Based on a working session between our team and Oracle's Fusion AI product management group in October 2026, combined with Oracle's public announcement of Fusion Claw on September 29, 2026 and Oracle's public documentation. Statements about availability, hosting, and controls reflect that conversation and are not a substitute for Oracle's published guidance. Confirm specifics against your own environment and your Oracle account team. Views are my own.

Fusion Claw and AI Units: A New Rate Card, and Your Agents Still Bill Separately

Fusion Claw and AI Units: A New Rate Card, and Your Agents Still Bill Separately

What changes in the cost model when a Claw runs, what does not, and the budget controls you can use today.

In August I wrote about making sense of Oracle AI units. The insight that cleared things up for me then was simple: models Oracle hosts carry a zero multiplier, and models Oracle has to call out to are where charging happens.

Fusion Claw adds a new wrinkle to that picture, and one of our team members asked about it during our session with Oracle's Fusion AI product management team. Here is what we learned.

Same meter, new rate

The meter does not change. An AI unit still represents the tokens processed combined with the complexity of the type of action. Today, nearly everything is a general action, which is the cheapest category.

What is changing is the set of rates. Oracle is publishing new rates for new capabilities: one for document generation, one for audio and video generation, and a new rate card it calls Frontier for Claw work.

The Frontier multiplier was not confirmed in our session, so I am not going to guess at one here. Watch for it on the rate card.

What the Frontier rate covers

For a Claw, consumption is mostly the orchestration work: the frontier model doing the planning and reasoning. It is based on the tokens processed, and it is independent of the agents.

Your agents still bill

This is the part worth getting right in a forecast.

When a Claw asks an agent to execute something, that agent is still doing its own work, using its own model, under the rate for the type of action it performs. The Claw does not absorb or replace that consumption.

So the cost of a Claw run is two things added together: the Claw's own orchestration at the Frontier rate, plus whatever each underlying agent consumes along the way.

That is consistent with what Oracle told us in August about agentic apps: same meter, more moving parts. A Claw is one more moving part, on a different rate.

Why the hosted model escape hatch does not apply

In my earlier post I suggested starting any Fusion AI cost model by working out which use cases genuinely need a premium model, and assuming the rest can run on Oracle-hosted inference at no incremental cost.

That framing still works for agents. It does not work for the Claw itself. Oracle told us that GPT-OSS, the hosted model with the zero multiplier, is not capable enough for Fusion Claw, and that frontier models are required.

Fusion Claw is inherently premium. The question shifts from which model a Claw should use to whether a given outcome justifies a Claw at all, or whether a standard agentic app interaction will do.

What you need to have

Fusion Claw is accessed through agentic apps, so you need the agentic app SKU. That SKU includes an allotment of AI unit credits, and if your usage grows beyond it, you buy additional AI units for that consumption.

As before, I am deliberately not quoting figures. Have that conversation with your account team early.

Budget controls you can use in 26D

One of our architects asked the question every platform owner is thinking: what happens when someone kicks off something ambitious and it runs for nine hours straight?

The answer was partial but useful. In Agent Studio in 26D you can set AI unit budgets at three levels:

·        An entire environment

·        An individual agentic app, which includes its Claw usage

·        An individual agent

You can also tell it what to do when a budget is reached: stop execution, or let the current work finish. And there is a kill-all button. As it was put to us, kill -9 for the Unix users.

What is not there yet:

·        User-level budgets. You can see what individual users are consuming, but you cannot set a budget per user.

·        Events or APIs for budgets. These controls live in Agent Studio today.

Oracle described work in progress on both fronts: exposing operational observability data through something like an OpenTelemetry stream so you can monitor it in your own systems, and APIs to set budgets, stop agents, and manage user access from the outside. Until those land, budget management happens in Agent Studio.

What I would do

Set budgets before the first Claw run, not after the first surprise. At minimum, put an app-level budget on every Claw-powered agentic app you enable, and an environment-level budget on anything that is not production.

And apply the same discipline I argued for in August, one level up. Before reaching for a Claw, be clear on why the outcome needs long-running, frontier-model reasoning rather than a point-in-time agentic app interaction.

What I am still watching

·        The published Frontier multiplier.

·        Whether a single Claw run can be broken down into its Frontier consumption and its underlying agent consumption, which is what a finance conversation will ask for.

·        Whether the ROI dashboard in Agent Studio reports on Claw outcomes the way it does for agents.

Based on a working session between our team and Oracle's Fusion AI product management group in October 2026, combined with Oracle's public announcement of Fusion Claw on September 29, 2026 and Oracle's public documentation. I am reporting a conversation, not a contract. Product details and pricing mechanics change between releases. Confirm specifics against your own environment, rate card, and Oracle account team. Views are my own.

What Actually Happens When a Fusion Claw Runs

What Actually Happens When a Fusion Claw Runs

The harness, the models, the private container, the memory, and the boundaries that hold it all in.

The word Claw comes with baggage. The open agent harnesses that inspired the name earned a reputation for broad reach: a shell, a file system, a repository, and whatever else you hand them.

So the first thing I wanted to understand about Fusion Claw was not what it can do. It was what it cannot do, and what is actually running underneath it.

Oracle's Fusion AI product management team walked us through it in some detail. Here is the picture as it was described to us.

The runtime

When a Claw runs, Oracle sets up a virtual command line environment and gives the agent harness a controlled set of tools inside it.

·        The primary harness is based on the open source Codex harness.

·        Frontier models from OpenAI provide the planning, analysis, and deep research capability.

·        Skills live inside the virtual file system. Oracle provides some, and authors can add their own to describe how a particular outcome should operate.

Oracle's announcement also names Gemini alongside OpenAI, with support for additional frontier models planned over time. In our session, the discussion centered on OpenAI.

The private container

Each Claw runs in a private virtual container that Oracle hosts in OCI, specifically within its Fusion Spectra service, and that only your company and your users can access.

The lifecycle is sensible:

·        The container is live while the work is running.

·        When the session pauses or completes, Oracle stores the session state and shuts the container down.

·        If you resume, the container is rehydrated from that stored state.

Session information is retained for up to 90 days, and that retention period is something you can set yourself. Keeping it around is what lets you restart a session, continue it after the Claw has finished, or take it down a different path with the same context.

This is also where generated code runs. When a Claw writes code to analyze a large data set, that code executes inside the container, not directly in Fusion.

What it can reach

The Claw's scope is set by the agentic app it belongs to. Authors decide which parts of the app are exposed to the Claw through a capability layer, effectively a subset of the app, along with the skills and guardrails that govern how it pursues the outcome.

Oracle gave two concrete examples of what that means in practice. A Claw will not go set up a REST call outside the domain of its agentic app. And unlike general coding assistants, where you might give the agent access to a Git repository, Fusion Claw does not get that kind of open-ended access. It is limited to the agents and capabilities you make available to that particular outcome.

Whose identity it uses

All data access and all actions happen with the invoking user's token. The Claw only fetches data that user can see, and only takes actions that user has the functional rights to perform.

Combined with the point I made in my previous post, that the Claw plans and orchestrates while the agents execute, this means the Claw itself never holds credentials.

Roles, in layers

One of our architects asked the question every security team will ask: if I can use a Claw, do I inherit access to every agent it can call?

No. Access is layered:

·        A user needs the role for an individual workflow agent to invoke it, or for it to be invoked on their behalf.

·        The agentic app has its own role access, and that is where access to the Claw is set, because the outcome is tied to the app.

·        If a user has access to the app but not to one of its agents, that agent simply does not participate on that user's behalf.

App access does not paper over missing agent access. That is the answer I was hoping for.

Memory and learning

As a Claw works through a long-running session, it keeps notes to manage memory and context. Across runs, it applies what Oracle described as procedural or functional learning, so later runs of the same outcome can make fewer LLM calls, use fewer tokens, and produce better results.

Another of our architects asked where that learning lives. The answer was direct: it is tenant-centric and specific to the Claw outcome. It is not a shared, Oracle-wide learning layer.

Why it took this long

I said on the call that the open Claw concept has been around for a while, and that the real challenge was never the concept. It was constraining it.

Oracle agreed. Their point was that no customer wants a Claw going wild in their environment and picking up permissions it is not supposed to have, and that this is a deliberately constrained implementation built to work within Fusion security. Having heard the details, I believe them.

What we did not cover

A few things I still want to understand, and which are now with Oracle as written follow-up questions:

·        What the Outcome Receipt described in the announcement contains in practice, where it is stored, and whether it can be exported to the systems we already use for audit.

·        Whether code generated by the Claw is logged and reviewable after the fact.

·        How the user's identity is handled across sessions that run for hours or days, including what happens if that user's roles change mid-run.

·        Where business data retrieved into the container is held during the retention period, and how it is purged.

None of those are criticisms. They are the questions an audit or architecture review board will ask, and I would rather have them answered before anyone needs them and I'll report back with what we find!

Based on a working session between our team and Oracle's Fusion AI product management group in October 2026, combined with Oracle's public announcement of Fusion Claw on September 29, 2026 and Oracle's public documentation. Product details and pricing mechanics change between releases. Confirm specifics against your own environment, rate card, and Oracle account team. Views are my own.