A 9B Fine-Tune Beat Opus 4.5. Who Holds the Weights?

The Short Answer

Coinbase post-trained Alibaba's open-weight Qwen3.5-9B on its own Onramp fraud data and it beat Claude Opus 4.5 on all four metrics of Coinbase's internal benchmark, with 55% lower serving latency and under $100 of training compute. The result belongs to whoever holds the weights afterwards, which is why on ibl.ai you own all the code and the data.

The version of this story circulating as "small model beats frontier model" is true in a narrow, carefully-measured sense and misleading in every wider one.

What Coinbase actually demonstrated is that a task-specific model trained on proprietary outcomes beats a general model that has never seen them, on one task, on one private benchmark. That is a claim about data, not about parameter counts.

That open weights have caught up in general capability is not news here — we argued it in The Model Is a Commodity. The Operating System Is the Moat in August.

What is new is a named company publishing a measured production result, and the question nobody asked afterwards: who ends up owning weights trained on your proprietary data.

What exactly did Coinbase do, and which model did it fine-tune?

Coinbase published a three-part engineering series titled Owning Intelligence on 7–8 October 2026, covering how it built, evaluated and post-trained a fraud agent for Onramp, its fiat-to-crypto purchase flow: Part 1, Part 2 and Part 3, which covers the post-training, on the same blog.

A disclosure about sourcing, since the whole point of this post is taking numbers seriously. Coinbase's blog returns HTTP 403 to automated fetchers, and an invented slug returns the same 403.

So the status code says nothing about whether a page exists, and we have not read the originals ourselves. Every figure below is corroborated from coverage we did load, and attributed as such.

The base model is Alibaba's Qwen3.5-9B, an open-weight model at 9 billion parameters. Coinbase post-trained it on its own historical Onramp fraud data.

The method, as reported, was reinforcement learning with verifiable rewards — the reward scored against known historical fraud outcomes — using GRPO and LoRA via SkyRL on Anyscale, then served with Ray Serve LLM and vLLM.

Training ran on a single NVIDIA RTX PRO 6000 96GB GPU for under $100, according to Crypto Briefing's write-up.

One structural detail gets dropped from almost every retelling, and it matters more than the benchmark. The agent did not replace Coinbase's existing defences. It was layered on top of Onramp's existing machine-learning model and rules engine.

In a 50% traffic A/B experiment, the arm with the agent enabled saw 30% fewer fraudulent transactions and 22% less fraud value, with Coinbase estimating fraud savings at roughly 3× the inference cost.

That is a composition result, not a replacement result. The agent is an additional reviewer inside an existing control, which is also why its errors are survivable.

Did a 9B model really beat a frontier model, or is the comparison unfair?

Both, and the distinction is the whole value of the story. The numbers are real and the comparison is internally consistent; what it does not support is a general ranking of the two models.

Here is what Coinbase reported, as summarized by the outlets that covered it:

Now the caveats, because a buyer who finds one overstated row stops trusting the whole table.

The benchmark is proprietary and cannot be reproduced from outside. Per FourWeekMBA's breakdown, it comprises 16,140 transactions across 7,293 users, including 813 confirmed fraudulent transactions, drawn from nine weeks of pre-rollout production data — and Coinbase itself describes the dataset as proprietary. Primexbt's summary puts the consequence plainly: "The benchmark is proprietary, so outsiders cannot independently verify the results."

The two models were not given the same information. The 9B model had been post-trained on Coinbase's historical fraud outcomes; Opus 4.5 was evaluated as a single-pass decision agent with no such training.

So the honest reading is this: on one company's private eval, a small model that had seen that company's fraud history outperformed a large model that had not.

That is a far more useful finding than a leaderboard win, and it is also not transferable to your organization by reading about it.

Dollar-weighted recall is the row to look at twice. A +35.4-point gap there, against +12.0 on plain recall, says the fine-tune was catching the expensive frauds disproportionately — which is what the business was optimizing for, and what no public benchmark measures.

Why did Coinbase's newer frontier models score worse than the older ones?

This is Part 2 of the series, it got a fraction of the attention, and it is the finding most enterprises should act on this quarter.

Coinbase compared successive frontier releases on that same internal benchmark and found the newer version scoring lower on recall, F1 and dollar-weighted recall in all three families it tested. As mpost reported:

• Sonnet 5's recall fell 22.2 percentage points relative to Sonnet 4.6, with dollar-weighted recall down 22.9 points.
• GPT-5.6 gained 11.5 points of precision and lost 20.7 points of recall against GPT-5.4 — a tradeoff, not a regression, but one that silently changes how much fraud gets through.
• Opus 5 declined 0.8 points on recall against Opus 4.5.

FourWeekMBA's breakdown reports the finding in Coinbase's own words: "Newer LLMs are not necessarily better at domain-specific tasks."

Read that against the public record of the same releases, where headline capability moved up. The conclusion is not that frontier labs are getting worse. It is that a general capability gain and a gain on your domain are different events, and only one of them is announced.

This is also the strongest version of the ownership argument, and it is sharper than "small model beats big model."

A frontier upgrade is a change you do not schedule, do not stage and cannot decline indefinitely. If it regresses the one task your business measures, the weights you control are the only component of the system that did not move.

The operational consequence is concrete.

If a production risk control calls a hosted model by a moving version pointer, and the organization has no domain evaluation of its own, then a routine model upgrade is an uncontrolled change to a fraud control — detectable only in the loss numbers, months later.

That is the argument for owning your evaluation harness before you argue about which model to use. We made the same case from a different direction in Scaffold Effects: AI Accuracy Is Architecture, Not Model Choice.

Nubank reached it by yet another route — replacing GPT-5.2 with an open-weight Qwen3.5 configuration after simulating conversations against its own traffic, covered in Nubank Tested Agents on Simulated Conversations Before Production.

If you fine-tune on your own data, who owns the resulting weights?

This is the question the Coinbase story raises and almost no coverage asked, and it has documented answers that vary by route rather than a single rule.

To be explicit about whose argument this is: Coinbase's stated motives were accuracy, latency and cost. Sovereignty and ownership are not reasons it gave, it is not an ibl.ai customer, and nothing below should be read as Coinbase endorsing a position. The ownership consequence is ours to argue.

A fine-tune's value is exactly the part the vendor does not have: your labelled outcomes. Once it is encoded into weights, those weights are an asset — and the terms that govern them differ sharply depending on where the training ran.

What the published documentation actually says, as of 14 October 2026:

Note what that table does not claim. It does not say a hosted vendor cannot let you export a fine-tune — enterprise agreements vary, and the correct move is to read your own contract rather than an argument from architecture.

What it does say is that the default, as published, is asymmetric.

On the open-weight route the trained artifact is a file you hold; on the managed routes it is an entitlement inside someone else's service, with a lifetime bounded by their deprecation schedule and, in Bedrock's documented case, a monthly storage charge.

So the three questions to put in writing before any fine-tuning project starts.

Can we export the resulting weights or adapter? What happens to the artifact at renewal, at price change, or at exit? If the base model is deprecated, do we retrain from our data or lose the capability?

Those are procurement questions with contractual answers, not technical mysteries.

They are also the reason we argue that the durable asset is the platform rather than the model, as in Open Weights Tied Grok 4.7. What That Does to Procurement and Why Model-Agnostic Architecture Is No Longer Optional.

The hardware end of the same question is worked out in Mistral Large 4 (Le Chonk): The Infrastructure Math, which sizes a 1.05T open-weight model against a 78B one.

Coinbase's result sits at the opposite extreme of that range — a 9B model and a LoRA adapter on a single GPU — and the planning question is the same either way.

How does the cost shape of a task-specific model differ from per-seat AI?

It differs in what the bill is indexed to, and that is a bigger difference than the unit price.

Coinbase's fraud work prices against transactions and outcomes: under $100 of training compute, inference per decision, and a reported return of roughly 3× the inference cost in fraud avoided. Every term in that sentence scales with work actually done.

Per-seat enterprise AI prices against headcount. The bill moves when you hire, not when the system is used, which means a 5,000-person organization pays 5,000 units whether 300 people or 4,000 use the thing in a given month.

For a workload like fraud review that is the wrong shape, not merely the wrong price. There is no seat to attach the cost to — the consumer is a transaction flow, and nobody logs in.

A per-seat line item for a system with no users is a category error that happens to also be expensive.

This is why ibl.ai bills usage against a cap you set, with no per-seat pricing, and why we have written the headcount-multiplied arithmetic out in full in The True Math of Per-Seat AI Cost.

Should your organization post-train a small open-weight model on its own data?

Only where three conditions hold, and Coinbase's write-up is unusually clear about all three.

You need a verifiable reward. Coinbase could score candidate outputs against known historical fraud outcomes. A task with no ground-truth label — summarization, drafting, advice — has nothing to reinforce against, and no amount of GPU time fixes that.

You need a domain benchmark first. The Part 2 regression finding is only visible to an organization that built an eval on its own nine weeks of production data. Without one, you cannot tell a fine-tune's win from noise, and you cannot tell a model upgrade from a silent downgrade.

You need somewhere to put the result. A LoRA adapter trained for under $100 still needs serving, routing, identity, logging, cost attribution and a rollback path. Coinbase had that platform. The $100 figure is the cheapest line in the project.

And the honest limit on the generality of the result: it holds for the task the proprietary data covers. The same model, asked to do anything else, is a 9B model.

That narrowness is the actual lesson, and it points at infrastructure rather than at model shopping.

The capability came from data Coinbase owned, the durability comes from weights Coinbase can keep, and the thing that has to exist underneath both is a platform that can run whatever model wins this quarter and the next one — including a model you trained yourself.

Agents that touch money have a further requirement that no amount of model accuracy satisfies, which we covered separately in AI Agents That Move Money Need Row-Level Permissions. Coinbase's design anticipated it: the agent recommends, the existing control decides.

What ibl.ai does with this

ibl.ai is the agentic AI platform where you own all the code and the data.

You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM — including an open-weight model you post-trained yourself — and pay by usage with no per-seat pricing, so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.

That matters specifically here. A fine-tune encodes your proprietary outcomes, so the platform serving it should not be the one place in your stack you cannot leave.

ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.

Sources

Coinbase's Owning Intelligence series (Parts 1–3, 7–8 October 2026) is the origin; because coinbase.com returns 403 to automated fetchers, the figures above come from coverage we loaded.

Crypto Briefing for the 7.5–35.4-point range of the benchmark deltas, the latency and the training cost; it publishes the range rather than the per-metric assignment.

The row-level figures — +7.5 precision, +12.0 recall, +9.6 F1, +35.4 dollar-weighted recall — are from mpost, which carries the per-metric breakdown.

Primexbt corroborates the same figures, though it credits Crypto Briefing and so is not an independent check.

mpost and FourWeekMBA for the Part 2 version-over-version regression figures and the benchmark's composition.

Vendor terms are quoted from the primary documentation: OpenAI's model-optimization guide and Amazon Bedrock's model customization documentation.