One loop. 5,304 lines.
Routing, planning, editing, deploying — all in one function.
One prompt builds an online clothing store. Kernel 1 then tests the checkout end to end on the live preview, walks through the store admin, generates the hero image, and recalls a detail from eight prompts earlier.
The launch film
1:24 · Sound on
Music throughout; there is no narration. Everything the film says is on screen, and it is all below.
On a light canvas: “Describe the app you want. Kernel builds it.” The prompt “Build an online store for everyday clothing” is typed into the Swarmz composer and sent.
The view pulls back to the editor. Kernel creates the files and the Northbound Goods storefront assembles in the live preview. On screen: “It doesn’t just build your app. It uses it.”
“QA test this app for me.” The Swarmz cursor takes over the preview: it opens the Brushed Fleece Hoodie, picks a size, adds it to the cart and checks out, then lands on Orders in the store admin. Kernel replies: “Placed a test order end to end — it works. Product page → cart → checkout: no errors. Free shipping applied over $75. Order #1044 landed in Orders.”
“Navigate me through the ecom admin.” The cursor opens Products, then Discounts. Kernel sums it up: Orders — 15 orders, test order #1044 on top. Products — 7 products, 1 still a draft. Discounts — 5 active, including free shipping over $75.
“Generate a hero image for the store — warm fabric, soft light.” On screen: “It makes the images, too.” The generated image lands at the top of the storefront, fills the screen and fades to dark.
In a dark editor, one detail is said once: “FYI: we ship from Oakland — 2 to 3 business days anywhere in the US.” Eight more prompts follow: a hoodie size guide, a sticky mobile header, product reviews, a low-stock badge, a newsletter signup, a German storefront, gift-card checkout and faster product images. Then: “What did I say our shipping time was?” Kernel answers: “2 to 3 business days, shipped from Oakland to anywhere in the US.” On screen: “Bulletproof memory.”
“2.2× faster.” A typical build: 2 min 33 s → 1 min 08 s. Then “A fraction of the credits”, before Kernel and with Kernel 1: a first build from 6.9 to 1.2 credits, a follow-up from 2.0 to 0.3 credits.
Light returns. “Kernel plugs into your” — Google Drive, Outlook, Slack, Notion, GitHub and more in quick succession — “and 76 more services.” Then “Everything else, built in.”: Go live — publish to your own domain. Backend built in — every sign-up saved instantly. Analytics built in. Measured — a score for every build. Undo anything — every change saved, one click back.
End card: “Kernel 1. Default on every build, today.” swarmz · swarmz.net/kernel
Routing, planning, editing, deploying — all in one function.
Files fell out of context after eight turns.
New runtime. Typed tools. State that survives a crash.
272K governed tokens. 24 messages kept verbatim.
Median provider cost per run: 29.6 cents on Pipeline, 2.2 cents on Kernel 1.
Median completed run: 2m33s on Pipeline, 1m08s on Kernel 1.
Against 75% on Pipeline V5. Five times fewer runs fail outright.
Held deliberately under OpenAI's repricing cliff, so a long build never silently doubles in price.
05 · The descent
01 · Memory
When it compacts, the last 24 messages survive word for word.
02 · Reach
The catalogue left the prompt: 144,132 characters down to 925.
03 · Proof
Seven checks on your diff, and two attempts to fix what fails.
04 · Core
Memory
It compacts once, at 258,400 tokens, and keeps the last 24 messages word for word when it does.
Benchmark · Pipeline V5 → Kernel 1
Not a benchmark — the two engines’ own limits, side by side. The left-hand column is what you were shipping on last week.
156×
less catalogue pasted into every single turn
Pipeline pasted the entire 89-service catalogue into one tool description, on every single turn — about 36,000 tokens before the model read a word of your code. Kernel ships three tool definitions and searches the catalogue instead.
| Pipeline V5 | 144,132 characters |
|---|---|
| Kernel 1 | 925 characters |
3 → 1
governors that can cut your build short
Pipeline compacted at half its window, ran a second pass that nibbled recent work, and force-finished any build that consumed 300K uncached input. Kernel has one line at 258,400 and no cap that cuts a run short.
| Pipeline V5 | Three |
|---|---|
| Kernel 1 | One |
2×
more past conversations carried into this one
How many previous conversations it carries in. The whole digest sits inside the cached prefix, so depth costs almost nothing.
| Pipeline V5 | 3 runs |
|---|---|
| Kernel 1 | 6 runs |
14
files still in hand when you ask for one more change
Ask for a two-line change and it still has the surrounding code open. No re-reading tax.
| Pipeline V5 | 6 files |
|---|---|
| Kernel 1 | 14 files |
3×
more of your code handed over whole
An excerpt of your own code is a rumour about it.
| Pipeline V5 | 2 files |
|---|---|
| Kernel 1 | 6 files |
24
messages that survive compaction unparaphrased
Plus the live goal, every unresolved error, and a receipt for every side effect already committed. Nothing is paraphrased.
| Pipeline V5 | — |
|---|---|
| Kernel 1 | 24 |
7
checks it has to pass before it claims success
Changes, lint, types, app health, runtime errors and route nesting. A failure buys exactly two bounded repair attempts, then the run reports honestly instead of claiming success.
| Pipeline V5 | — |
|---|---|
| Kernel 1 | 7 |
120
real clicks, types and scrolls on your live preview
Pipeline could screenshot a page. Kernel opens a real browser session on your live preview and uses it — 30 ordered actions per call, across desktop, tablet and mobile.
| Pipeline V5 | 0 |
|---|---|
| Kernel 1 | 120 |
89services
connected services, reachable without a catalogue in the prompt
Pipeline pasted all 89 services into a tool description on every turn — 144,132 characters of catalogue before the model read a line of your code. Kernel ships a 925-character search tool and looks things up when it needs them.
| Services in the registry | 89 |
|---|---|
| Typed operations | 772 |
| Operations that need your approval | 381 |
In the product
Every file it opens, every line it changes, and every click it makes on your own preview — as it happens.
A reproduction of the Swarmz editor. On the left, the activity panel lists the files the engine read, a search it ran, a file it edited with two lines added and one removed, and the expanded diff of that edit. On the right, the live preview with the engine’s cursor pressing the Save enquiry button.
Not a mock-up of the interface — the interface. Every rule, chip, diff tint and cursor above is the shipping component’s own markup, rendered against the same design tokens the editor uses.
Resilience
Failure is a state Kernel 1 passes through, not a place it stops.
Reach the ceiling and it summarises, keeps the last 24 messages verbatim, and carries on. You never see it happen.
Silently — unless output already reached you. Then it refuses rather than repeat itself.
The moment it touches something outside the sandbox, every retry path closes. An uncertain outcome is reported, never replayed.
It checkpoints the tool call it was inside, against a fenced write that refuses to land twice. Come back tomorrow.
What it can do
Two of these ship in the old engine too, and the rows say which. The numbers on the right are the limits the engine actually enforces — they are the reason it can be trusted with any of it.
It opens a real browser session on your live preview and uses it — clicking, typing, scrolling, switching viewport — then reads the page back as structured text with a reference for every interactive element. Not a screenshot it squints at: a session it is holding.
Before it tells you a build is done, seven named checks run against the files it changed. A failure is reduced to a fingerprint, and the same fingerprint twice is a block — so it cannot loop on a fix that never worked, and it cannot quietly call a broken build finished.
Work that suits another model gets handed to one — and handed a leash. A delegated task is given an exact list of files it may read and an exact list it may write. Stray outside it and the whole batch is rejected before a single write lands.
Before it starts unfamiliar work it searches for a vetted procedure and loads it. Skill text is treated as untrusted instructions: it can tell the engine how to do something, and it can never grant a tool or a permission.
It remembers decisions across runs — but only ones it can prove. Every entry needs either the shortest exact quote from what you said, or the id of a tool call that actually succeeded. Never both, never neither, and never its own inference.
Platform questions get looked up instead of guessed at, and the ranking is deterministic rather than a similarity score — an exact slug always beats an exact capability, which always beats a full-text match.
Kernel reaches the same 89 services the legacy loop reached — it just stopped carrying the catalogue. Pipeline pasted all 89 manifests into a tool description on every turn. Kernel ships a search tool and looks a service up when it needs one.
The same tool both engines have, pointed differently. On a Kernel run the instructions ask for a complete planned family of assets — transparent cut-outs, consistent lighting, one scene’s worth in one pass — rather than one image at a time.
Every figure above is a constant in the engine, not a target. Hover a row’s limits to see the file it was read from.
Median completed run. The old engine’s median was 153 seconds — and it only finished three runs in four.
kernel-1 · luna · 142 runs measured
Seven named checks green against the files it changed.
A failure buys exactly two repairs. The same failure twice blocks.
Run against your diff, not the whole project. Every result is named.
It starts from the files it has open. No warm-up, no re-read.
In the same week, one Pipeline run in four never finished at all.
25% failed · 5% on kernel 1 · 7 days to 22 September 2026
Containment
Every turn is swept before it is stored, every tool is capability-classed, and anything that leaves the sandbox stops for your approval the first time it tries.
The lineup
You never pick one. It routes the work, and both share the same memory, the same governed window and the same tools.
The default
Every build starts here. Cheap enough per token that Kernel can afford to keep your codebase in the room instead of re-reading it.
Heavier work
Same runtime, same 272K discipline, ten times the input price. Reserved for work where being right is worth the tokens.
Reach
It searches the catalogue instead of carrying it around.
services in the registry
typed operations
integration tools