Introducing Nebula

Nebula is our depth model. It reads a whole product the way a user would — every route, every state, every dead end — and then rewrites the decisions your generator got wrong.

Generated code is rarely broken in the way a test suite understands. It compiles, it deploys, and it still puts the primary action below the fold, promises something in a header that the flow never delivers, and trusts input it has no business trusting. Those are behavioural failures, and they only show up when you follow a real path through the product.

Nebula is built for exactly that. Rather than scoring a file in isolation, it traces navigation and data across the whole project before it proposes a single change. That is what takes it to 93.6% accuracy — just ahead of Fable 5, the strongest external model we benchmark — and it is why we reach for it when correctness matters more than milliseconds.

Model	Token Usage	Time Taken	Accuracy
Nebula	1,350 tokens	780 ms	93.6%
Comet	320 tokens	120 ms	96.8%
Fable 5	1,420 tokens	820 ms	92.8%
Opus 5	3,600 tokens	1,650 ms	89.5%
GPT 5.6 Sol	2,100 tokens	1,240 ms	84.2%
Gemini CLI	2,850 tokens	2,100 ms	78.6%
Gemini 3.6 Flash	890 tokens	450 ms	72.1%

Performance and cost

The trade Nebula makes is deliberate. At 780 ms and 1,350 tokens per decision it is neither our fastest nor our cheapest model — Comet is both, by a wide margin — and it isn't trying to be. Nebula runs in Fable 5's weight class, not Comet's. What it buys with that budget is context: by the time Nebula proposes a change to a route, it has already read the routes that lead into it and the ones that lead out.

That matters most on the security pass. A large share of the vulnerabilities that ship with generated code are not visible in the file that contains them — an unguarded handler is only a problem because of who can reach it. Single-file analysis misses those by construction, which is most of the gap between the models below.

Working with Nebula

A Nebula pass runs the same three stages every time, in the same order, and returns each decision with the reasoning that produced it attached.

• De-slop. Strips the filler that generators reach for by default — placeholder headings, triplicate cards, copy that says nothing. Because Nebula reads the whole surface before it cuts, removals never orphan a layout.
• Behaviour. Rebuilds the decisions that generated code gets wrong: where the button sits, what the header promises, how the flow earns trust. Every route is traced to its end state before anything moves.
• Security. Closes the vulnerabilities that ship with generated code — exposed keys, missing authorization checks, unvalidated input — by following data across files rather than pattern-matching one of them.

Review and safety

Nebula only ever proposes. Nothing it produces reaches your codebase until you approve it, and every decision arrives with the trace that led to it — the routes it read, the data it followed, and what it expected to find.

That constraint is the point. A model that rewrites behaviour without showing its work is asking for the same trust that produced the slop in the first place.

Getting started

Nebula is available in the Behavr dashboard, on pull requests through GitHub, Vercel, and Netlify, and through the API. Passes are billed at $0.40 for a full project sweep and $0.02 per route for targeted re-runs after a fix.

If you want it running on every commit rather than every release, that is what Comet is for.

Get started with Behavr