DEV Community: Anton Shubin

How to hire a developer to take over your AI-built app

Anton Shubin — Fri, 06 Nov 2026 11:56:50 +0000

If you built your MVP with Lovable, Bolt, Cursor or Claude, you probably got further than anyone expected, and now you need a person to take it on. This post is for you: how to tell a senior developer from a pasted proposal, and how to hand over the keys without handing over the house. There is a checklist inside to score the proposals you already have.

TL;DR

You are not hiring someone to write code: the AI already did that. You are hiring someone who can read code they didn't write and tell you what is unsafe.
Pass on a proposal with two or more red flags, such as a leftover placeholder, a wrong name, a diagnosis that fits any app or an offer of free work.
Shortlist the ones with proof: a live app on your stack, one specific insight, an honest gap and a dated, priced first step.
Start with a small paid audit and read-only access, keep every account in your name, and keep the right to stop any week.

To hire a developer to take over your AI-built app, look for someone who can
read code they didn't write, not someone who promises to write more of it. Skip
the proposals that could have been sent to anyone. Shortlist the ones that show
a live app on your stack and one specific insight about yours. Then start with a
small paid audit before you hand over production.

This post is for a founder who built an MVP with Lovable, Bolt, Cursor or Claude
and now needs a senior developer to continue. I am one of those developers: I
take over apps like yours, and I sell the audit this post recommends. I'll say
where that matters, and every check below works on me too.

What are you really hiring for?

The AI wrote your code fast. What it rarely does on its own is decide what is
safe, test it, and plan for the day something breaks. That is the job you are
hiring for.

AI-built apps tend to break in the same few places:

Database access rules. On Supabase these are Row Level Security policies. A table with only a read policy looks fine in a demo. Then updates and deletes can quietly change zero rows, and inserts fail with an error the generated code often never checks. The user sees "Saved!", and nothing was saved.
Secret keys in the browser. A key meant for the server ends up in the code every visitor downloads.
Payments the browser decides. The page marks an order as paid, instead of your server hearing it from Stripe.
No safety net. No staging copy, no backups you have restored once, no tests.

So the person you want reads first, judges second and writes third. They keep
what works, which is most of it. A developer whose first idea is "let's rewrite
it from scratch" is offering to throw away the one thing you have that already
works, and to bill you for the privilege.

If you are still deciding whether you need a person at all, I wrote about
when an AI subscription is enough and when it isn't.

What are the red flags in a proposal?

Wherever you post the job (Upwork, LinkedIn, a founder community, a friend of a
friend), proposals arrive fast and often look the same. A lot of them are
written by AI too, which is a little funny for a job about cleaning up after AI.

Here is what should make you close a proposal before the second paragraph:

A template placeholder is still in it. A [client name] or a [your project] that nobody filled in. If they didn't read their own message, they won't read your code.
Your name is wrong, or someone else signed it. It was pasted from the last job, and the one before that.
It opens by feeling your pain. "I understand how frustrating it is when your app…" That is everyone's opening now. It costs nothing and tells you nothing.
The diagnosis fits any app. "Your app needs refactoring, a better architecture and performance work." They haven't seen your app. I haven't either, and that sentence is still true of it. It's true of mine too.
It reads like generated text. Bold headings in a two-paragraph message, emoji bullets, every paragraph the same length, a "Week 1 / Week 2" plan for code they haven't opened. Someone who lets a model write even the hello will let it write your review.
The rate is far below a senior rate. A senior job at a junior price means the person is not senior, or will not stay. You pay the difference later, in rework.
It offers free work or a discount. "I'll fix the first bug for free", or a special price just for you. It reads as need, not confidence. And free work comes without a contract, so nothing says the code is yours.
An agency writes as one person. "I" in the first paragraph, "our team" in the third. Agencies are fine. Hiding who will do the work is not, so ask who writes the code and talk to that person.
A video link is the whole reply. A short video about your project can be great. A video instead of a written answer means you can't skim it, compare it or forward it to a technical friend.

What do green flags look like?

Good proposals are usually shorter. They show you something instead of telling
you something:

A live app on your stack. A link in the first lines that you can open, built on what you use: Supabase, Next.js, Stripe, whatever yours is. One or two that work beat a list of twenty.
One specific insight from real work. A sentence a chatbot would not write from your job post. "Check your security rules" is generic. "Your table probably has a read policy and no update policy, so edits do nothing and no error shows" is someone who has been bitten by it.
An honest gap. "I haven't worked in Lovable itself, but what it exports is React and Supabase, which I know well." A person who admits one gap is easier to believe about everything else.
A dated, priced first step. "A written audit by Friday, for a fixed price. Read-only access first. Nothing reaches production without staging. You can stop any week." The risk sits on their side of the table, not yours.
One question only an expert would ask. Everyone asks how many users you have. "Does your Stripe webhook mark an order as paid, or does the page?" or "Do your admins and your customers share one users table?" shows they are already looking at the parts that break.

Score the proposal you received

Count the flags, then:

Two or more red flags: pass, however good the price looks.
One red flag: ask about it before you pay for anything.
No red flags and three or more green ones: offer this candidate a paid first step.
No red flags, but little proof yet: ask the three questions below.

It's a rule of thumb, not a court ruling. A tired senior can send a clumsy
message, and a polished one can come from someone who has never shipped. But the
flags are cheap to check, and they sort a long list fast.

The red and green flags above also work as a checklist you can tick for a proposal you received.

Try it on antonshubin.com: https://antonshubin.com/blog/hire-developer-take-over-ai-built-app?utm_source=devto&utm_medium=blog&utm_campaign=hire-developer-take-over-ai-built-app#proposal-checklist

Which three questions should you ask every candidate?

A short call or a written reply is enough for these. Listen for specifics.

"What would you check first in my app, and why?" A good answer names the things that hurt users: data access rules, secret keys, payments, backups. Features and styling come later. "I'd refactor the components" is a weak answer, and "I'd rewrite it" is a red flag with a clock on it.
"Show me something you shipped that still runs. What broke in it?" You want a live link and a real failure story. Someone who has never broken production has never run one. I have a whole blog category for my own scars, so I can't pretend otherwise.
"If we stop after the first week, what do I keep?" The right answer is "everything": the code in your repository, the accounts in your name, and the notes written down. Anyone who hesitates here is planning to be hard to leave.

Why does a paid audit beat a free call?

A free call is good for one thing: checking that you can talk to each other. I
offer one myself, and I'd keep it for exactly that. But nobody on a free call
has read your code, so everything said there is a guess wrapped in a pitch.

A small paid audit is different:

They read your code. The advice is about your app, not apps in general.
You get a written report you keep. It lists what is solid, what is risky and what to fix first. You can hand it to any developer, including a cheaper one than the person who wrote it.
You see how they work before the big contract. Did it arrive on the date they named? Is it in plain words? Did the risky things come first, or the easy ones?

It costs a little, and it is the cheapest way to find out what you are actually
buying. Yes, this is the part where I mention that I sell one: my
code and security audit has a fixed price,
quoted before any work starts, and gives you a written report and a call to walk
you through it. If you hire someone else, ask them for the same shape of first
step.

How do you run the first week safely?

You don't need to be technical for any of this. You need to be the person who
holds the keys.

Keep every account in your name. The repository, the hosting, the database, Stripe, the domain, the email. Invite the developer as a member; never share your password. When the work ends, you remove one member and there is nothing to recover.
Give read-only access first. An audit needs to read the code and the database settings, not change them. Write access comes after you have read the report.
Make your own backup before anything changes. Export the database and keep a copy of the code somewhere the developer can't delete it. It is the cheapest insurance you will ever buy.
Staging before production. A second copy of the app, with test data, where every change lands first. If you don't have one, building it is a fine first task.
Pay in small steps, and keep the right to stop any week. Ask for a short written update every week: what changed, what's next, what is risky. A week with nothing you can see is a reason to stop.
Change the keys when someone leaves. Any secret key the developer saw gets replaced. It's not distrust; it's how you close the door.

Got a proposal in your inbox right now? Run it through the
checklist above and ask the three questions. And if you'd
like me to be one of the candidates, my
code and security audit is the first step I'd
offer you: a written report of what is solid, what is risky and what to fix
first, before anyone touches production. If you'd rather talk it through first,
book a one-hour strategy session.

First published on antonshubin.com.

Deno's development is ending, so I moved my SaaS starter to Node and Bun

Anton Shubin — Thu, 05 Nov 2026 17:51:04 +0000

Deno's team is joining Cloudflare, and the runtime's development ends after one more year of fixes. Seed, my SaaS starter, ran on Deno and Fresh, so I moved it to run on Deno, Node and Bun. This post is the honest account: what was hard, what wasn't, and the slowdown I shipped on the way.

TL;DR

The Deno.* calls were not the hard part. Serving files, Deno types in public signatures and Fresh's internals were.
I replaced Fresh by copying its API: 419 of 423 responses came out identical, and every page shipped less JavaScript.
My first release of that layer made the slider post block input for 119 ms against Fresh's 51.5 ms. CI missed it: none of its pages has an island.
Don't rewrite. Put each Deno.* behind a small adapter, run the build on Node and Bun in CI, and diff every response before and after.

Seed: Live: Open the live demo · Code: github.com/spy4x/seed

To migrate from Deno to Node and Bun, you don't rewrite your app. You keep it on
web standards (fetch, Request, Response), put every Deno.* call behind a
small adapter, and replace what only runs on Deno, such as Fresh. I did exactly
that for Seed, the SaaS starter every new project of
mine starts from. The pull requests that finished it merged on 4 November 2026.

This post is for a developer or a tech lead with a Deno codebase who read the
news and now has to decide: stay, fork or move. Short version of the worry "my
code is full of Deno.*": those calls were the easy part. It shows what was
really tied to Deno in a tested codebase, what replaced each piece, and the
mistake I shipped on the way.

What happened to Deno?

On 9 October 2026, Ryan Dahl wrote that
Deno is joining Cloudflare. The runtime gets
another year of monthly releases with bug fixes and security updates, and then:
"After that year we will end our development of the Deno runtime." Deno stays
open source, and others are welcome to continue it.

The same post says Deno Deploy keeps running for six months and then shuts down,
and JSR keeps running on Cloudflare's infrastructure.
Cloudflare's own post says
the team will merge Deno's celld into Cloudflare's workerd runtime. Neither
post says what happens to Fresh, Deno's web framework.

So nothing breaks tomorrow. Your app runs the same today as it did yesterday.
What changes is the future: a bug or a security hole found after that year may
never be fixed.

Why move a starter that worked?

Seed is not one app. It is the starting point of every product I build, client
MVPs included. A runtime that stops getting fixes under it would sit under all
of them.

So the goal was not "leave Deno". It was "run unchanged on Deno, Node and Bun".
Deno stays both a runtime Seed supports and its toolchain: deno fmt,
deno lint and deno test still run every check. If Deno finds a new home,
nothing is lost. If it doesn't, the switch is a start file, not a rewrite.

"But my code is full of `Deno.*`"

That is the usual worry, and it was mine too. Here is the honest answer: the
Deno.* calls were the easy part.

Reading an environment variable, serving a request, opening a file: each has an
obvious twin on Node, and Bun implements Node's node:fs and node:net
(Bun's compatibility list). So one
small adapter covers both. This is the start file that runs Seed's website on
Node and Bun, trimmed of its port check. Deno runs the same built server with
deno serve:

import { serve, type ServeHandler } from "@spy4x/platform/server/serve"
import { shutdownSignal } from "@spy4x/platform/server/shutdown-signal"
import { exitProcess, processEnv } from "@spy4x/platform/server/process"

const hostname = processEnv.get(`MPA_HOST`) || `0.0.0.0`
const port = Number(processEnv.get(`MPA_PORT`) || 8000)

const built: { default: { fetch: ServeHandler } } = await import(
  new URL(`./server.js`, import.meta.url).href
)

const server = await serve(built.default.fetch, {
  hostname,
  port,
  signal: shutdownSignal(),
})
await server.finished
exitProcess(0)

processEnv reads Deno.env on Deno and process.env on Node and Bun.
The built server is a plain fetch handler: a Request in, a Response out. That is the web standard doing the heavy lifting.
serve() listens on whichever runtime it finds itself on.
shutdownSignal() is an AbortSignal that fires on SIGINT or SIGTERM, so requests in flight finish before the process exits.

Even the Redis client needed nothing. It already talked over a connectTcp
adapter in my shared library: Deno.connect on Deno, node:net on Node and
Bun. I tested it on Valkey 8.1, Node 26.13 and Bun 1.4.4.

So what was hard?

Four things, and only one of them is a function call:

Default arguments that call Deno.*. A function with a default like fs = denoFs looks harmless until Node imports it, and there is no Deno to call. The defaults now pick the running runtime's version.
Deno types in exported signatures. Deno.Signal sat in public types, so a Node project could not even type-check my library. It became OsSignal, a list of the same 36 names, with a type test in both directions so the two can never drift apart.
Error classes. Deno throws Deno.errors.IsADirectory; Node throws an error with code: "EISDIR". One fsError and isFsError pair maps both. The Node adapter is imported lazily, so deno check doesn't pull in Node's types.
Serving files. Range requests and ETags took the most care. A test caught bytes=10- on a 10-byte file returning 200 instead of 416: a range that starts past the end of the file asks for nothing, and the right answer is "Range Not Satisfiable". A reviewer caught that a weak ETag must never satisfy If-Range, because the HTTP standard compares it with the strong comparison only.

The final check was blunt: deno bundle of the 77 @spy4x/* imports Seed uses
produced one .mjs file, and it ran directly on Node and Bun, with no
package.json. All of that shipped as release 1.116.0 of my shared library.

How do you replace Fresh without rewriting every route?

Fresh was the real tie. It is
Deno's own framework, built by the same
company, and I had built Seed's public website on it. That is the mistake I own
here: I put a framework owned by the runtime's company under the one project
everything else starts from.

I didn't rewrite the routes. I wrote a small layer that copies Fresh 2's API:
App, ctx.render, createDefine, fsRoutes. It renders with Preact, builds
with Vite and runs on web standards. It is
@spy4x/preact-server,
1,459 lines of source and 919 lines of tests, part of my open-source component
library. Because the API matched, Seed's route files barely changed. Seed's side
of the switch, spy4x/seed#815, touched
128 files and deleted more than it added: +562, −908.

Did anything change for the visitor?

To find out, I requested every route on both builds and compared the answers
(spy4x/seed#623). 419 of 423
responses were identical. Two of the four differences were one video's
modification time and ETag. The other two were the malformed path /%E0%A4%A:
Fresh answered with a bare 500, the new layer answers with the site's 404 page.

The pages also got lighter. Gzipped JavaScript per page, Lighthouse mobile, 22
pages, median of 3 runs:

Page	New layer	Fresh
Home	24.0 KB	32.1 KB
A blog post with island	29.9 KB	38.0 KB
Docs	8.6 KB	19.4 KB

Every page scored 98–100 on both builds. Of the 112 end-to-end tests, 110 passed
on the first run. The two that failed tested Fresh's internals: an island's file
name and the CSP nonce.

What's better, and what's missing?

Two things got better:

No nonce in the CSP. The layer puts island props in a JSON block, not an inline script, so the Content-Security-Policy needs no nonce. This very site still runs on Fresh, and its CSP code reads Fresh's private nonce. That is exactly the kind of internal I don't want to depend on.
Safer redirects. ctx.redirect() keeps /\host and /<tab>/host on the site (the test). Fresh lets both through to another host.

And four things Fresh has that the layer doesn't: csrf() middleware (a
same-origin check from my shared library does the job), _404 and _500
routes, its own dev server (Vite runs development instead), and a per-route
opt-out of the modulepreload header.

The scar: my replacement made the slider post slower than Fresh

Seed's blog has a post with an interactive slider,
the welcome post. On the
first release of my layer, 13.11.0, that page blocked input for 119 ms. Fresh
blocked it for 51.5 ms. That is Lighthouse 12.8.2, mobile, 6 alternating runs
each. The page shipped less JavaScript and still blocked input more than twice
as long.

The cause: loading and hydrating every island ran as one long task. The browser
could not answer a tap until the last island was awake.

The fix, in 13.11.1
(#1193), gives the
browser a turn before each island:

function yieldToMain(): Promise<void> {
  const scheduler = (globalThis as {
    scheduler?: { yield?: () => Promise<void> }
  }).scheduler
  return scheduler?.yield
    ? scheduler.yield()
    : new Promise((resolve) => setTimeout(resolve, 0))
}

It uses
scheduler.yield()
where the browser has it and falls back to setTimeout(0). The blocking time
dropped to 2 ms. The design reviewer re-checked it over 7 runs: 5 ms against
Fresh's 48 ms, and a Lighthouse score of 97 against 96.

Why didn't CI catch it? Seed's CI does run a Lighthouse speed check. But none of
the pages it measures has an island
(spy4x/seed#816). A speed check only
guards the pages you give it. If your most expensive page isn't in the list, its
regression ships green.

Measure the page with the heaviest island, not the page that's easiest to
measure.

The trap: one line in `package.json` broke the tests

The last pull request, spy4x/seed#817,
added the Node and Bun start files, their Docker images and a CI smoke test that
builds the site and runs it on all three runtimes. 27 files, +768, −212.

Two surprises came with it. Adding "type": "module" to the root package.json
broke Playwright under Deno. The fix was to leave the field out: that file only
hands npm run and bun run over to deno task. And in CI, the new smoke test
and the browser tests raced each other on vapid.json and the build folders.
The fix: the smoke test now runs in its own copy of the checkout.

How did AI agents split the work?

I didn't type most of this code. One coordinator session, an AI agent, started
separate sessions for each lane: my shared library, the website layer in my
component library, the Seed port, and landing the move off Fresh. Each worked in
its own git worktree with its own pull request.

An independent reviewer agent gated every merge. On changes a visitor can see, a
design reviewer gated it too, in a real browser. They earned their place: the
weak-ETag If-Range bug was a reviewer's find, and the 13.11.0 slowdown was the
design reviewer's measurement.

One honest lesson. When a session stopped halfway, the coordinator first only
passed its report on to me instead of carrying the work on. I had to point that
out. Now a coordinator continues a stopped session's work itself.

An agent also drafted this post. Every number in it comes from a merged pull
request or from the measurements in
spy4x/seed#623.

How tied to Deno is your project?

Here is every tie I found, and what replaced it in Seed. The first eleven were
Seed's; the last three Seed never had:

Your project uses	What replaced it in Seed
`Deno.serve` or `deno serve`	The servers export a standard `fetch` handler. Deno still runs it with `deno serve`; on Node and Bun a start file hands it to `serve()` from `@spy4x/platform`.
`Deno.env`	`processEnv` from `@spy4x/platform`: `Deno.env` on Deno, `process.env` on Node and Bun.
File APIs: `Deno.readFile`, `Deno.stat`, `Deno.open`	A small file interface with two versions: `Deno.*` on Deno, `node:fs/promises` on Node and Bun.
Deno's error classes, such as `Deno.errors.NotFound`	One `fsError` and `isFsError` pair that also knows Node's `code: "EISDIR"`.
`Deno.Signal` or other `Deno` types in exported signatures	`OsSignal`, a list of the same 36 names, with a type test in both directions.
Default arguments that call `Deno.*`	Defaults that pick the running runtime's version.
`Deno.connect`, such as a Redis client	Nothing: the client already ran over a `connectTcp` adapter, `Deno.connect` on Deno and `node:net` on Node and Bun.
Fresh	`@spy4x/preact-server`, a new layer that copies Fresh 2's API.
`jsr:` imports	`deno bundle` builds them into the server file, so Node and Bun never see a `jsr:` import.
`Deno.Command`	Nothing: only the dev, deploy and media scripts use it, and they stay on Deno.
`deno test`, `deno fmt`, `deno lint`	Nothing: the toolchain stays Deno. `npm run` and `bun run` call the same `deno task`s.
Deno KV	Never used: the data lives in Postgres and Valkey.
Deno Deploy	Never used: Seed runs in Docker Compose on any Linux host.
`deno compile`	Never used: Seed ships Docker images.

If you ticked Deno Deploy, start there: it has six months, not a year. If you
ship single binaries with deno compile, as I do for
my MCP servers, that is a decision of
its own. Tick your own project's ties below:

The table above also works as a checklist you can tick for your own project.

Try it on antonshubin.com: https://antonshubin.com/blog/migrate-from-deno-to-node-and-bun?utm_source=devto&utm_medium=blog&utm_campaign=migrate-from-deno-to-node-and-bun#deno-ties

Should you stay, fork or move?

My answer: don't panic, and don't rewrite. You have a year of fixes. Use it to
make the switch cheap, then decide when you have to:

Count your ties. The table above is a start. Look hardest at your public types and your default arguments: that is where Deno hides.
Put each Deno.* behind a small adapter. One function per need, with a Deno version and a Node version. Bun takes the Node one.
Run the build on Node and Bun in CI. A smoke test that starts the server on each runtime and requests a page catches the rest.
Replace the framework last, by copying its API. Then diff every response before and after, so "it works" is a number, not a feeling.
Measure your heaviest page. The one with the most islands, not the one that's easiest to measure.

If your product runs on Deno and you'd like a calm plan instead of a panicked
rewrite, that is what my
code and security audit is for: three days,
from $1,500. It covers architecture, security and performance, and for a Deno
codebase that includes every tie to Deno, ranked by risk, with what to move
first and what to leave alone.

And if you've already started your own move, tell me what bit you. I'd like to
know if it was the Deno.* calls or, like me, everything around them.

First published on antonshubin.com.

My app's tab kept jumping to the front: passkey autofill and Bitwarden

Anton Shubin — Sun, 01 Nov 2026 12:46:00 +0000

A friend told me my app's tab kept jumping to the front by itself, and a few days later it did it to me in the middle of a YouTube video. This post is the hunt, from the wrong first guess to the timer in my own sign-in page, and the two lines in Bitwarden's code it kept triggering. It is for anyone who ships passkey sign-in, or who ever wondered whether a web page can switch your tab.

TL;DR

A sign-in page with passkey autofill restarted its waiting request every 4.5 minutes. With Bitwarden installed, every restart pulled the tab, and its window, to the front.
Bitwarden's code (version 2026.10.0) switches to the tab and focuses its window when any passkey request it handles ends, a cancel included.
The fix: start and renew passkey autofill only while document.hasFocus() is true. A renewal that falls due in the background waits for the focus event.
My first guess, the "new version" banner, was wrong. The timer was the clue.

Seed: Live: Open the live demo · Code: github.com/spy4x/seed

If your web app's tab keeps switching to the front by itself, look at your
passkey autofill. Bitwarden's extension switches to the tab and focuses its
window whenever a passkey request it handles ends, a cancel included, so a
conditional request that restarts on a timer steals focus on every restart. The
fix: start and renew passkey autofill only while document.hasFocus() is true.
Together, a timer and Bitwarden made the sign-in page of Seed, my
SaaS starter, jump to the front every four and a half minutes, no matter what
the person was doing in other tabs.

This is a post in my Scars series: things I got wrong, and what I changed
after. It's for anyone who ships passkey sign-in, and for anyone who wondered
whether a web page can steal your focus.

What happened?

A friend sent me a message: the Seed demo had been open in a background tab, and
it switched to itself, showing the "New version available" banner. "Forced focus
is too much," he wrote. I agreed it would be too much, but I wasn't sure a page
could even do that.

The next day I was browsing Google Maps in Brave, and the Seed tab jumped to the
front. Twice in ten minutes. Then I put on a YouTube video, and it kept
happening, about every five minutes. Now I believed him.

Can a web page switch your tab by itself?

Not on its own. Modern browsers don't let an ordinary tab bring itself to the
front with window.focus(). A service worker can focus a tab, but only while it
handles a click on one of its notifications.

I asked my coding agent to check what Seed actually ships: the live JavaScript
bundle, the service worker and the web app manifest. None of them called
focus() on a window, opened one, or focused a tab outside a notification
click. So the agent's first answer was "not our code". That was true of focus
calls, and it was not the whole answer.

Was it the "New version available" banner?

Since my friend saw the "New version available" banner, the banner was the first
suspect. It lives in a screen-reader live region, so new text in it is
announced. Maybe the browser or the desktop raised the tab on that announcement?

I ran the test: a blank tab, the same live region, the same text after 15
seconds, while I sat on another tab. Nothing moved. And when it happened to me
again there was no new version at all. Wrong guess.

Every five minutes, with no new version, is not an event. It's a timer.

What runs every 4.5 minutes?

So I asked the agent to search the app and its shared libraries for timers. It
found one:

/** How long an autofill passkey request waits before it starts again with a fresh challenge. */
const PASSKEY_AUTOFILL_RENEW_MS = 4.5 * 60_000

Seed's sign-in page offers your passkeys right in the login field's autofill. To
do that, it keeps a request waiting in the background:
navigator.credentials.get() with mediation: "conditional". The request
carries a challenge from the server, and the challenge expires after five
minutes. So every four and a half minutes the page cancelled the waiting request
and started a new one with a fresh challenge.

And my friend's tab? Its address was /sign-in.

Who actually switched the tab?

Before fixing anything, I told the agent to prove it. It ran a clean Brave
profile with a probe page that cancels and restarts a conditional passkey
request every 8 seconds, while another tab is active. The probe tab stayed in
the background. So neither Brave nor the request itself does it.

The difference was my real profile, and in it, the Bitwarden extension. With its
passkey setting on, which is the default, Bitwarden handles passkeys on web
pages in place of the browser. Here are the two calls its background script
(version 2026.10.0) makes, with its helpers inlined. They run in a finally
after every passkey request it handles:

chrome.tabs.update(tabId, { active: true, highlighted: true })
chrome.windows.update(windowId, { focused: true })

"Every request" includes one the page cancels. So every 4.5 minutes Seed
cancelled its waiting request, Bitwarden finished handling it, switched to the
tab and focused the window. If Brave sits behind another app, the whole window
can come up.

Bitwarden didn't run in the test profile: it only steps in with a signed-in
vault, and I wasn't going to sign a test script into mine. So this step is read
from Bitwarden's code, not reproduced. The code reads plainly, and it matches
the timing.

How do you stop passkey autofill stealing focus?

Start and renew the conditional passkey request only while document.hasFocus()
is true, and catch up on the focus event. That was my mistake: Seed restarted
a request in a tab nobody was looking at. Seed can't change Bitwarden, but it
can stop poking it while you're away. The sign-in page now starts and renews the
autofill request only while the page has focus. A renewal that falls due in the
background waits, and runs the moment you come back, before you can pick a
passkey with an expired challenge:

const waitForAutofill = () => {
  renewal.current()
  if (!document.hasFocus()) {
    const resume = () => waitForAutofill()
    globalThis.addEventListener("focus", resume, { once: true })
    renewal.current = () => globalThis.removeEventListener("focus", resume)
    return
  }
  waiting.current?.abort()
  // ...start a new request, and renew it again in 4.5 minutes
}

Three tests drive the real sign-in view with a fake passkey browser and a fake
clock. They check that the request renews on time with focus, stays untouched in
the background, and starts in a tab opened in the background only once it gets
focus. The fix is in
Seed's pull request #610.

What to take from it

A timer in a background tab is not invisible. Anything you start, cancel or restart there can reach extensions you never heard of. If it doesn't need to run while the person is away, don't run it.
Renew passkey autofill only while the page has focus. If you use conditional mediation with a short-lived challenge, check document.hasFocus() before you cancel and restart, and catch up on the focus event.
"Every five minutes" is the best clue you can get. My first guess chased an event that happened to be on screen. The period pointed straight at the cause.

If you use Bitwarden and a site of yours renews passkey autofill on a timer,
sign in to your vault, open the site in a background tab and wait one renewal
period. If the tab jumps to the front, add the focus check.

First published on antonshubin.com.

I tried SKILL.state in my coding agents and stopped after four days

Anton Shubin — Fri, 30 Oct 2026 12:20:40 +0000

A friend sent me the SKILL.state paper and later asked how it worked out. This is the answer: what I built from it, the four tasks I ran, and why I stopped. It is for anyone who runs coding agents on long tasks and wonders whether an explicit state file is worth it.

TL;DR

SKILL.state swaps an agent's growing chat history for a state file and a fresh step each time. I ran my own version of it on real tasks and stopped after four days.
The briefs were clean, but every run needed hand fixes, such as patches that failed the schema, invented timestamps, and a state folder that broke the linter.
The problem it solves, context that grows until it is compacted, mostly went away when I moved to Opus 5.5: 2 of 48 units of work were compacted.
The part worth keeping, a fresh agent per step with a self-contained brief, I already use without the state file.

In late September I read a paper that promised to fix the thing that bothered me
most about long agent tasks: the conversation grows until the agent forgets what
it was doing. I built my own version of it into my coding-agent setup, ran it on
real tasks, and switched it off four days later.

This is a post in my Scars series: things I tried or got wrong, and what I
changed after. If you run AI coding agents on long tasks and wonder whether an
explicit state file is worth it, it's for you.

What is SKILL.state?

SKILL.state (Badhe, Tiwari and Chung, 2026)
is a runtime design for long agent tasks. Most agents keep everything in one
growing chat: every observation, action and piece of reasoning is appended to
the history. Over a long task that gets slow, and old, wrong details "poison"
later steps.

SKILL.state replaces that history with an explicit, mutable execution state. At
each step the model gets only three things: the skill it follows, the current
state, and the latest observation. Its reasoning is thrown away once it has
produced a valid state update. The paper reports better accuracy with much lower
token use.

How I tried it

My agents run in Claude Code, which always keeps the full chat history. I can't
build every prompt myself the way the paper's runtime does, so I approximated
the idea with a skill:

A state file per task. The lead agent kept the task in a JSON file inside the worktree: the objective, the phase (spec, design, issue, implementation, review, merge), the decisions, the reviewer's findings and the next action.
Changes only through a small CLI. Every update was a patch the CLI checked against a schema before applying it, so a step could not leave the state broken.
A fresh subagent per step. Each step's work went to a new subagent whose whole brief was the skill, the current state and the latest observation. No conversation.

The plan was a fair comparison. My task flow alternated: one task with the
skill, the next without. Once each side had enough tasks, I would compare how
often the first review passed, how often I had to correct the agent, and the
minutes per task. The skill would become the default if it was at least as
reliable and not much slower.

What happened

I stopped after four tasks: three with the skill, one without.

Task	Flow	Review rounds	Minutes
1	SKILL.state	1	22
2	SKILL.state	2	122
3	normal	2	25
4	SKILL.state	3	53

I didn't have to correct the agent in any of them, and none of the four
conversations was compacted. Four tasks prove nothing on their own. What made me
stop was what I saw inside them.

What helped

The briefs were good. Each subagent got a small, self-contained frame and needed
no history. The reviewer needed no extra context. When a review asked for fixes,
a fresh implementer picked them up from the state alone.

What got in the way

Every run with the skill hit several of these, and the lead agent fixed them by
hand:

Patches that failed the schema. Subagents wrote state updates the CLI rejected, and the lead had to write some of them itself.
Invented timestamps. The schema wanted a time on every finding. The subagents made them up, hours away from the real time, and the lead replaced them.
A state folder that broke the checks. deno fmt and deno lint scanned the state folder, so it had to be moved out of the way before every check.

In one task a subagent also ignored an instruction not to push, and the lead had
to rewrite a public commit message. That one isn't the skill's fault, but more
handoffs meant more places for an instruction to get lost.

Why I stopped

The problem went away on its own. In the middle of the experiment, I moved my
agents to Opus 5.5
(the numbers behind that switch).
After that, the median peak context was 162K tokens, and only 2 of 48 units of
work were compacted at all. The skill fought a problem I barely had anymore, and
it added bookkeeping to every task.

The comparison was also too slow to finish. At my pace, enough tasks on each
side would have taken weeks.

A fix for a problem you no longer have is just overhead.

What I kept

The best part of the idea didn't need the state file: a fresh agent for each
step, with a brief that holds everything it needs. That's already how my agents
work. A lead splits the work into lanes, each implementer starts clean with its
own brief, and a separate reviewer checks every diff. Later I removed the skill
from my setup.

My test was not the paper's setup. I approximated the idea inside a tool that
keeps the whole conversation, on a model with plenty of room. With a smaller
context window, a weaker model, or a runtime that builds every prompt itself,
I'd expect SKILL.state to do better than it did for me.

My agent rules and skills are public in my dotfiles, if you
want to see how the lanes and briefs work.

Have you tried an explicit state file with your agents, and did it pay off?
Email me at hi@antonshubin.com. It comes straight
to me.

First published on antonshubin.com.

I tested Trail-code on my Claude Code agents. They ignored the map.

Anton Shubin — Thu, 22 Oct 2026 05:56:48 +0000

Trail-code promises cheaper, faster coding agents by giving them a map of your code. I replayed 10 merged PRs with and without it, in both of its modes, and reviewed every result blind. This post is what I found and how I tested it, so you can run the same test on the next tool that makes this promise.

TL;DR

Trail-code's code map changed nothing for my Opus 5.5 agents over 10 tasks: 7 map calls in one mode, none in the other.
Its prompt hook matched only 2 of 10 issue-sized briefs, so in most runs nothing was pushed to the agent.
The same task's cost moved by about 13% from run to run. At that noise, 10 tasks can't prove a saving smaller than about 13%.
Test a tool on your own work: replay merged PRs from the commit before, with and without it, review blind, and measure the noise first.

Seed: Live: Open the live demo · Code: github.com/spy4x/seed

Trail-code says it makes Claude Code, Cursor and Codex faster and cheaper by
giving them a map of your code. Its README shows 32% lower cost and 60% less
time. It was trending, and my agents' bill is a number I watch every week, so I
tested it on my own work: 10 real tasks, two modes, blind reviews.

My agents barely touched the map. That is the short version. The longer version
is how I tested it, which you can reuse for the next tool that promises the same
thing.

What Trail-code is

Trail-code (formerly graft) has two parts:

The code map. It parses your repo with tree-sitter into a graph of every file, function and caller. No model and no network: on my Seed repo, 885 files took about 23 seconds. Agents query it for "where is X" and "who calls Y" instead of grepping.
Learnings. Agents save what they worked out from your conversations into files in the repo, so the next session starts from them.

I tested only the map. My agents work under written rules, and a decision only
lands in those rules after I approve it. Notes that agents write into the repo
on their own don't fit that.

How I tested it

My agents work in waves: an implementer writes the code for one GitHub issue, a
separate reviewer checks it, and nothing merges until the reviewer passes it. I
wrote about the setup and its costs in
Opus 5.5 vs Sonnet 5.

Comparing two different weeks of work tells you nothing, because the tasks
differ. So I replayed work that was already done:

I picked 10 PRs that had already merged in Seed, my SaaS starter: auth and billing fixes, a refactor, infrastructure, caching, structured data, tests.
For each one I made a fresh clone at the commit before the PR, one commit deep, so the answer was nowhere in its history.
An Opus 5.5 implementer got the original issue as its brief and built it with the map and without it. The runs of a task went in parallel, so they saw the same machine load.
A reviewer checked every result blind, on a clean copy under a random letter, with the merged PR as a reference answer.
Afterwards I scanned every tool call to check that no agent peeked at the real repo or the real PR.

Trail-code gives an agent the map in two ways, so I tested both.

Round 1: the map as tools ("pull")

The agent gets MCP tools like trail_find_code and trail_trace_calls, and
calls them when it wants to. I added one line to the brief: use the map before
grepping.

Over 10 tasks the agents made 7 map calls. Everything else was grep and
sed through Bash, exactly as without the map. On the 9 comparable tasks, the
runs with the map cost 3.9% less in total, and the per-task change swung from
18% cheaper to 26% dearer.

Cost per task, round 1, the map as tools

Task	Without the map	With the map	Change	Map calls
IPv6 sign-up budget per /48	$0.68	$1.24	not compared: different judgment; the run without the map stopped, thinking a library release was needed	1
One day constant	$1.38	$1.36	−1.4%	1
Connection pooling	$3.90	$3.67	−5.9%	3
Tests for uncovered behaviour	$3.77	$3.41	−9.5%	0
Init task and Traefik in dev	$2.33	$2.02	−13.3%	1
Author line in page hero	$2.29	$2.26	−1.3%	0
Cache static assets	$1.92	$2.42	+26%	0
One product in structured data	$1.87	$1.53	−18.2%	1
Clear browser data on sign-out	$2.55	$2.27	−11%	0
Cancel dialog after the grace period	$2.28	$2.48	+8.8%	0
All 9 comparable tasks	$22.29	$21.42	−3.9%	7

3.9% cheaper in total on 9 comparable tasks, inside the −13% to +13% noise, so it proves nothing. 7 map calls in 10 tasks.

Try it on antonshubin.com: https://antonshubin.com/blog/trail-code-claude-code-test?utm_source=devto&utm_medium=blog&utm_campaign=trail-code-claude-code-test#cost-pull

One task is left out. On the auth fix, the run without the map decided the fix
needed a new release of my shared library first, and stopped. The run with the
map searched the library, found the option was already released, and finished
the job. Its one map call had nothing to do with that. It was a different
judgment call on the same evidence.

Round 2: the map pushed into the prompt ("push")

Trail-code's own benchmark found the bigger saving in "push" mode, where the
matching code reaches the agent without being asked for. In Claude Code, its
setup does this with hooks that run at session start, on every prompt and after
every edit, plus a skill that tells the agent to use trail.

I used exactly those hooks, taken from a real trail init, and gave them to
each run through its own settings file, so my global config stayed untouched.
This time the brief said nothing about the map: the hooks are the product.

The agents made zero map calls. Then I looked at what the hooks actually sent:

At session start: about 3 KB of instructions to use trail.
On the brief: "no strong match for this prompt" on 8 of the 10 briefs.
After edits and searches: nothing.

So I fed the prompt hook by hand. The bare issue text of the refactor, which
names the exact file and the exact constant, got no match. One-line questions
did better, but not well: 2 of 7 returned the right files. "Where is the IPv6
sign-up rate limit?" worked. "Which file defines JOB_AGGREGATE_ID?" returned
nothing.

The prompt matching is built for a short chat message. My agents get issue-sized
briefs, so push mode mostly pushed nothing.

Cost per task, round 2, the map pushed into the prompt

Task	Without the map	With the map	Change
IPv6 sign-up budget per /48	$1.18	$1.09	−7.6%
One day constant	$1.22	$1.28	+4.9%
Connection pooling	$3.63	$2.64	−27.3%
Tests for uncovered behaviour	$3.42	$3.18	−7%
Init task and Traefik in dev	$2.33	$2.58	+10.7%
Author line in page hero	$2.29	$1.70	−25.8%
Cache static assets	$1.92	$2.04	+6.3%
One product in structured data	$1.87	$1.78	−4.8%
Clear browser data on sign-out	$2.55	$2.08	−18.4%
Cancel dialog after the grace period	$2.28	$1.93	−15.4%
All 10 comparable tasks	$22.69	$20.30	−10.5%

10.5% cheaper in total on 10 comparable tasks, inside the −13% to +13% noise, so it proves nothing. 0 map calls in 10 tasks.

Try it on antonshubin.com: https://antonshubin.com/blog/trail-code-claude-code-test?utm_source=devto&utm_medium=blog&utm_campaign=trail-code-claude-code-test#cost-push

The push runs cost 10.5% less in total and took 8% less time. They also got the
worse reviews: 6 of 10 passed, against 8 of 10 without the map. And the saving
doesn't line up with the map: on the two briefs where the hook did send code,
one run got 11% dearer and the other 15% cheaper.

The number that decides it: noise

A 10% saving when nothing reached the agent in 8 tasks out of 10? That can't be
the tool.

On the first four tasks I ran the baseline twice. On the three where both runs
did the job, two identical runs, same model, same brief, differed by 7–12% in
cost. Across the compared tasks, the cost change with the map has a spread of
about 13% from task to task, in both modes. That spread is the noise any
saving has to beat.

If two identical runs differ by 10%, a tool that saves 10% looks exactly like
no tool at all.

That's the main thing I took away. Before you believe a saving, from a vendor or
from your own test, measure the noise. At 13% noise, 10 tasks can only show a
saving of about 13% or more. Neither mode got there, and the push mode's 10%
comes with worse reviews. Trail-code's 32% would have shown up clearly, and it
didn't.

How many tasks would you need? Set your own noise, then the saving a vendor
promised you.

Tasks needed, at 95% confidence and 80% power:

Runs differ by	5% saving	10% saving	20% saving	40% saving
7%	18	6	3	3
10%	34	10	4	3
12%	48	14	5	3

n = ⌈(2.8 × noise ÷ saving)² + 2⌉, never below 3.

Try it on antonshubin.com: https://antonshubin.com/blog/trail-code-claude-code-test?utm_source=devto&utm_medium=blog&utm_campaign=trail-code-claude-code-test#how-many-tasks

Why their benchmark and my test disagree

I don't think Trail-code's numbers are wrong. They measure something else:

Their headline numbers come from questions about code, answered by Sonnet 5. Mine were full implementations: read the issue, change the code, write tests, run checks.
Their agents started cold. Mine read a repo with a detailed AGENTS.md, and Opus 5.5 navigates with grep quickly and cheaply. A map saves little when finding the file was never the expensive part.
Their prompts are short. Push mode matches on the prompt, and a lane brief isn't a chat message.

If you use Cursor on a large repo you don't know, with short questions, your
result may well be different. That's the point: the only benchmark that answers
your question is your work.

What it cost

Everything together, 34 implementer runs and 33 blind reviews: about $101 at API
list prices. That's cheap compared with a month of a tool that adds hooks to
every session and does nothing for it.

Try this on the next tool

Pick merged PRs of different kinds. Ten is a good start.
Clone each at the commit before it, one commit deep.
Run the same agent with and without the tool, in parallel.
Review blind, with the merged PR as the reference answer.
Run the baseline twice, so you know your noise before you read any saving, and check with the calculator above whether your task count can show it.

Deciding whether an AI tool is worth it for your team? In a
60-minute strategy session we can plan this test for
your own agents and repo.

Which tool should I put through this next? Reply to the newsletter or write to
me. And if you want the next test in your inbox, subscribe below.

First published on antonshubin.com.

preact-components: a Preact component library without shadcn or Radix

Anton Shubin — Wed, 30 Sep 2026 16:42:52 +0000

TL;DR

preact-components is my open-source Preact component library: ten JSR packages, rendered on the server, with roles, keyboard handling and focus written by hand.
I own my components instead of using shadcn, Radix or MUI, because working around their styling, upgrades and limits cost me more than owning them.
Owning components means owning accessibility, so headless Chromium checks the keyboard handling on every pull request.
It is beta: no screen reader has been run against it, only Deno is tested, and it is Preact and Tailwind only. Try any component in the live guide first.

preact-components: Live: Open the live UI guide · Code: github.com/spy4x/preact-components

Every new app I start needs the same things: a button, a table, a dialog, a form
field, a chart, a signed-in layout. I kept rebuilding them, or pulling in a
component library and then working around it.

preact-components is where that stopped. It is an open-source Preact component
library: ten packages on JSR, every component rendered on the server and
hydrated in the browser, with roles, labels, keyboard handling and focus written
by hand. No shadcn, Radix, Headless UI or Material underneath.

This post is for developers who build with Preact and Tailwind and wonder
whether owning the UI layer is worth it. I'll show why I decided it is, what is
in the ten packages, how to try it in a minute, and what is not done yet.

The dashboard above is on the guide's first page. Every part of it is a
component from these packages, running on local state: you can filter and sort
the projects, run the checks for a toast, and add a project in the dialog.

Why not shadcn, Radix or MUI?

Two of my earlier apps used shadcn, Radix and bits-ui. Over time those libraries
cost me more to work around than it would have cost to own the components, in
three ways:

Styling opinions. A library ships a look. I already had design tokens. Either I fight its defaults on every component, or I slowly give up my tokens. The second one wins, quietly.
Upgrade breakage. A component library changes its API and its rendered markup. Every upgrade reopens components that already worked, for no product reason.
Extension limits. The component I need is never quite the one it ships. The workaround is often more code than the component, and it inherits the library's constraints on top.

So the repository has a written rule: every component is written there. No
third-party component library is a dependency, and a copy of one pasted into the
tree counts as one too. The old apps are still useful, but only as a reference
for design intent: I read how they compose a dialog and write my own.

Port the markup and the behaviour. Never the dependency.

That doesn't mean I write everything. My rule is "own the small, keep the huge".
Preact, signals, Tailwind, arktype, wouter and Leaflet stay: they are large,
well-solved problems, and none of them is a component library. A button, a
dialog or a combobox is small enough to own, and opinionated enough that I'd
fight someone else's defaults.

The real price: accessibility

Owning components means owning everything a library used to hide. The repository
names it plainly, so nobody pretends it is free:

focus traps: moving focus into a dialog, keeping it there, returning it on close;
dismissal: an outside click, Escape, and the difference between dismissing and closing on purpose;
ARIA wiring: which role, aria-expanded or aria-labelledby goes on which element;
keyboard navigation: arrow keys, Home and End, typeahead;
positioning: anchoring a popup to its trigger and flipping it when it would overflow.

Where the platform already has an answer, I use it: native <dialog>,
<details>, <button> and forms that post before any script has run. A native
element ships its semantics for free.

The Combobox above is a good example. Every one renders a single role="status"
live region, already in the server HTML and empty until the field is used, so
the answers it announces have a stable place to go.

How do I know the keyboard handling works? The packages that need a hydrated
page have browser checks in pages/checks/. On every pull request, headless
Chromium presses the keys, moves focus, opens dialogs and toasts, and asserts
what happens, instead of trusting the markup. The repository also has 139 test
files (counted with find . -name "*.test.ts*").

Rendered on the server, then hydrated

A component touches window or document only inside an effect or an event
handler. So every one renders complete HTML on the server and hydrates in the
browser. The live guide itself is served that way, and it reads with JavaScript
off.

This matters more than it sounds. A page that shows its content before the
JavaScript arrives is faster for the visitor and easier for a search engine. And
a component that only works after hydration usually hides a bug that shows up on
a slow phone.

Colours, radii and fonts are CSS custom properties, so an app restyles
everything by setting variables instead of forking the CSS. Layout goes through
Page, Section, Stack, Cluster and Grid, and no component carries an
outer margin. The guide's header switches between light and dark and changes the
accent colour live, so you can see the tokens at work.

What is in the ten packages

Every package is published on JSR under @spy4x/preact-*, all at the same
version, so a caret range always resolves to a set that was published together.

Package	What it holds
`@spy4x/preact-ui`	the component set: layout, buttons, tables, dialogs, forms
`@spy4x/preact-theme`	design tokens, the Tailwind preset and the classes
`@spy4x/preact-icons`	the merged icon set, one component per glyph
`@spy4x/preact-charts`	server-rendered charts with tooltips
`@spy4x/preact-system`	app-level pieces: auth form, calendar, shells, SEO head
`@spy4x/preact-crud`	a list and editor scaffold for one collection
`@spy4x/preact-map`	a map on Leaflet
`@spy4x/preact-signals`	stores and state helpers; no components
`@spy4x/preact-cn`	class-name join with Tailwind conflict resolution
`@spy4x/preact-ui-guide`	the live component catalogue, mounted in one line

The guide's overview counts 81 components and 120 icons across them today.

Where it came from

The components were extracted from real products, so I stop rebuilding the same
pieces for the next one. My SaaS template
already builds its signed-in layout on Shell from @spy4x/preact-system and
its styles on @spy4x/preact-theme. This site is next: it still has its own
components, and replacing them with the library is an open issue.

The design is not mine. The design system, the component styling and the
original markup are by Eirene
(isorokina.com). She designed it and built the
original pages the components were first extracted from. What I added is the
JavaScript: the Preact and signals implementation, the interactivity, server
rendering, tests, packaging and documentation.

Helpers with no UI, like dates and validation, come from my other library,
ts-libs, under the same @spy4x scope on JSR.

Try it in a minute

Open the live guide. Every
component runs there with its code one click away, so you can try one before you
install anything.

When one looks right, add the package:

deno add jsr:@spy4x/preact-ui

And render it:

import { Badge } from "@spy4x/preact-ui/badge";

<Badge text="Active" color="green" />;

One honest catch: the components render Tailwind classes against the compiled
stylesheet from @spy4x/preact-theme, and JSR cannot export a CSS file. So the
stylesheet takes a short build script instead of a plain @import. The theme
package's README has the recipe, one short TypeScript file.

The repository also has an llms.txt, so a coding agent can read the whole
component surface in one file.

What is not done yet

I mark it beta on my site, and here is why. The version is 1.2.0 and it follows
semantic versioning since 1.0.0, so a breaking change bumps the major number.
But:

No screen reader has been run against it yet. The browser checks prove the markup and the order in which the page changes, not what a screen reader actually speaks. That work is an open issue.
Only Deno is tested. The packages are standard ES modules with no Deno-only API, and a Vite app can use them through @deno/vite-plugin. Running them under Node or Bun has not been tried.
It is Preact and Tailwind only. If your app is React, or you don't use Tailwind, skip it.
Some components are deliberately not built. Carousel, Accordion, Drawer, a rich-text editor and a tree view were considered and turned down: nothing I run needs them, and some would need a large third-party piece I don't want. The reasons are written down in the repository.
Nothing in CI enforces the no-library rule. A pull request could add Radix and every check would pass. Review holds the rule, and the repository says so instead of pretending a check exists.

What next?

Open the live guide, press Tab
through a dialog, and see if it behaves the way you expect. If something is
missing or broken, open an issue on
GitHub. And if the library looks
useful, a star helps other Preact developers find it.

Building a product and want its UI layer owned like this, instead of rented from
a library? That's my day job: see
how I build a SaaS MVP.

First published on antonshubin.com.

Opus 5.5 vs Sonnet 5: the pricier model wrote my code for about half the cost

Anton Shubin — Sat, 26 Sep 2026 05:54:16 +0000

Opus 5.5 lists at twice the price of Sonnet 5. In my coding agents it cost about
half as much per line of code. It also replaced Fable 5.1 as my code reviewer,
at about a third of the price.

This post is the data behind that switch: five days of my own Claude Code
transcripts, priced at API list prices, with the parts that are proven kept
apart from the parts that are only likely.

How I run agents

I work in waves. A lead model reads a list of GitHub issues and splits them into
lanes that touch different files. Each lane gets an implementer agent that
writes the code in its own git worktree and opens a PR. A separate reviewer
agent then checks every PR: it runs the tests, breaks the code on purpose to see
whether a test goes red, and checks the PR description's claims. Nothing merges
until a reviewer passes it. A failed review ("needs-fix") goes back to the
implementer for another round.

Between September 20 and 25 that produced 203 implementer PRs and 411 reviewer
agents across four models. I pay a flat subscription, so the dollars below are
API list prices, used as a measure of how much of my usage limit each agent
burned.

Model	Input $/M	Output $/M	Cached read $/M
Sonnet 5	2	10	0.20
Opus 5	5	25	0.50
Opus 5.5	4	20	0.20
Fable 5.1	10	50	0.25

The last column is the one that matters, and the next section shows why.

Where the money actually goes

An agent doesn't pay for its work once. Every step is a new API call that sends
the whole conversation again: the brief, every file it read, every test log.
Most of that comes from the prompt cache, so each call is cheap, but an agent
makes hundreds of them.

In one six-hour window on September 24, my agents used about $593 at list
prices. 68% of that was cached reads, 22% cache writes and 10% output.
Across 57 agents, cost tracked "number of calls × average context size" almost
perfectly (correlation 0.99). The worst offenders were Sonnet implementers that
ran 400–600 calls while their context grew to 600–970K tokens, because nothing
compacted it before about 967K. Every one of those calls re-read the whole
thing.

So the price per token matters less than you'd think. What matters is how many
steps an agent takes and how much it carries through each one.

Cached reads cost the same $0.20 per million tokens on Opus 5.5 and Sonnet 5.
Only input, output and cache writes cost twice as much on Opus. For my Sonnet
implementers, cached reads were about three quarters of the bill (the median
lane), so the same call costs only about 25% more on Opus 5.5, not twice as
much.

Implementers: fewer steps beat a cheaper token

Opus 5 only ran on September 20–21 and Opus 5.5 only on September 23–25, so each
is compared with Sonnet 5 on the same days:

Days	Model	Cost per 100 changed lines	API calls per 100 lines
Sep 20–21	Sonnet 5	$1.57	30
Sep 20–21	Opus 5	$2.45	15
Sep 23–25	Sonnet 5	$2.13	38
Sep 23–25	Opus 5.5	$0.39	6

"Changed lines" is additions plus deletions in the PR. The median PR was the
same size for Sonnet 5 and Opus 5.5 (484 and 504 lines), so Opus isn't winning
by writing more lines. Over all five days, per 100 changed lines, Opus 5.5 made
6 times fewer calls than Sonnet, read 10 times less context and wrote 3 times
less output.

Opus 5 was not wasteful; its price was. Its prices are exactly 2.5 times
Sonnet's on every kind of token, so at Sonnet's prices it would have cost $0.98
per 100 lines against Sonnet's $1.57. Opus 5.5 keeps that efficiency and drops
the price.

The raw gap overstates it

The table says Opus 5.5 cost a fifth of Sonnet. That isn't a fair comparison,
because I chose which tasks went to Opus, and I gave it mostly authentication
and crypto work. So I compared units of work of the same size and kind, in the
same repository and the same session. Measured that way, Opus 5.5 cost about
0.45 times what Sonnet did (plausible range 0.29–0.71).

That's still a big saving, and the more interesting part is where it comes from.

The first draft costs about the same. Up to the first review verdict, Opus
5.5 cost about 0.77 times Sonnet, and that range includes equal cost. Opus did
bundle its work into fewer, longer shell commands: a median of 31 calls before
the first review, against Sonnet's 97.

The saving is in the fix rounds. In the September 24 window, fix rounds were
about 71% of implementer spend. A Sonnet implementer that had already grown a
900K context paid $5.60–6.40 for a small last-round fix, because it re-read
everything to make it. Opus carried a smaller context (a median peak of 170K
against Sonnet's 246K), and in the 5 Opus lanes of the fair split I describe at
the end it needed a median of 2 review rounds against Sonnet's 3.

Most PRs fail their first review

On ordinary code, most PRs from every model failed their first review. Sonnet 5
and Opus 5 passed 12–20% of the time. In one six-hour window on September 24,
all 20 PRs that changed production code failed their first review.

Opus 5.5's raw first-review pass rate looks great: 10 of 18. But almost all of
those passes were auth work that I had routed to Opus and that Fable reviewed.
On other code, Opus 5.5 passed 1 of 7, which is too few to say anything. Look at
why PRs fail, and the model matters less: at least 7 of those 20 failures were
tests that stayed green on broken code, or a PR description that claimed
something untrue. I don't expect a smarter model to fix that, so I changed the
process instead; it's too early to know whether that worked.

More reasoning effort cost more and bought nothing

Until this week, my implementers ran at whatever effort their lead used, so the
past lanes cover several levels:

Implementer	Effort	Cost per 100 changed lines	Passed first review
Sonnet 5	medium	$1.72	8 of 64 (12%)
Sonnet 5	high	$2.52	9 of 53 (17%)
Sonnet 5	xhigh	$2.56	1 of 13 (8%)
Opus 5.5	medium	$0.39	9 of 16

Sonnet at high effort cost 35–51% more per line than at medium, with no clear
gain in review results. Opus 5.5 did its auth and crypto work at medium. This is
observational (repositories ran at different efforts), so it's a signal, not
proof. It was enough to stop me guessing effort up front.

Reviewers: Opus 5.5 against Fable 5.1

On the same kind of PR in the same days, with both priced at Opus 5.5's rates, a
review round cost $1.36 on Opus 5.5 and $1.50 on Fable 5.1: about the same
amount of work. At real list prices, Fable cost about 2.7 times more, and it was
slower (a median of 9 minutes a round against 6.5).

Fable wasn't stricter either. On Sonnet-written code in the same days, it
blocked 17 of 19 first submissions, and Opus 5.5 blocked 74 of 92. That is no
real difference.

On the four PRs that both reviewed at the same time, each caught security bugs
the other missed. One was a delete path that followed symbolic links: Fable
caught it, and the Opus review running in parallel did not. So neither reviewer
is complete on its own. Instead of paying 2.7 times more for a second opinion, I
added that class of bug to the reviewer's checklist.

What I changed

Opus 5.5 implements and reviews every diff. Fable stays paused.
Medium effort by default. Reviews of production code run at xhigh, and reviews of auth, crypto, secrets, money, deploys and data migrations run at max. An implementer only moves up to xhigh for one fix round, when a PR's second failed review names a real behaviour defect.
Compact at 400K tokens instead of about 967K. The single largest saving in the analysis: it caps how much every call has to re-read. Reviewers, which peaked at 277K in the window I measured, never hit it.
A 1-hour cache for reviewers. Re-reviews usually arrive after the default 5-minute cache has expired, so the reviewer paid to rebuild its whole context.
Proof for every test. Each test a PR adds or changes needs a line in the PR body naming the code change that turns it red. A PR without those lines goes back before any reviewer spends a token on it.

What this doesn't prove

It isn't a controlled experiment. I chose which tasks went to Opus, the sample
is small (19 Opus 5.5 PRs), and list prices are a stand-in for subscription
usage. I started a fair split, with every other lane on Opus 5.5 regardless of
the task, and stopped it early: the like-for-like comparison and the token
counts pointed the same way. Opus 5.5 was cheaper, probably around half, and at
worst no more expensive.

One gap favours Opus in these numbers. In at least 3 of the 8 Opus PRs that
failed their first review, the lead agent made the fix itself, so that fix's
cost is missing from Opus's total. That happened in only 1 of 89 Sonnet cases.

The lesson I'd keep even if the model prices change next month: in agent work,
you pay for steps and context, not for tokens. Measure calls and context per
unit of work, and the right model is usually obvious.

DEV Community: Anton Shubin

How to hire a developer to take over your AI-built app

What are you really hiring for?

What are the red flags in a proposal?

What do green flags look like?

Score the proposal you received

Which three questions should you ask every candidate?

Why does a paid audit beat a free call?

How do you run the first week safely?

Deno's development is ending, so I moved my SaaS starter to Node and Bun

What happened to Deno?

Why move a starter that worked?

"But my code is full of Deno.*"

So what was hard?

How do you replace Fresh without rewriting every route?

Did anything change for the visitor?

What's better, and what's missing?

The scar: my replacement made the slider post slower than Fresh

The trap: one line in package.json broke the tests

How did AI agents split the work?

How tied to Deno is your project?

Should you stay, fork or move?

My app's tab kept jumping to the front: passkey autofill and Bitwarden

What happened?

Can a web page switch your tab by itself?

Was it the "New version available" banner?

What runs every 4.5 minutes?

Who actually switched the tab?

How do you stop passkey autofill stealing focus?

What to take from it

I tried SKILL.state in my coding agents and stopped after four days

What is SKILL.state?

How I tried it

What happened

What helped

What got in the way

Why I stopped

What I kept

I tested Trail-code on my Claude Code agents. They ignored the map.

What Trail-code is

How I tested it

Round 1: the map as tools ("pull")

Round 2: the map pushed into the prompt ("push")

The number that decides it: noise

Why their benchmark and my test disagree

What it cost

Try this on the next tool

preact-components: a Preact component library without shadcn or Radix

Why not shadcn, Radix or MUI?

The real price: accessibility

Rendered on the server, then hydrated

What is in the ten packages

Where it came from

Try it in a minute

What is not done yet

What next?

Opus 5.5 vs Sonnet 5: the pricier model wrote my code for about half the cost

How I run agents

Where the money actually goes

Implementers: fewer steps beat a cheaper token

The raw gap overstates it

Most PRs fail their first review

More reasoning effort cost more and bought nothing

Reviewers: Opus 5.5 against Fable 5.1

What I changed

What this doesn't prove

"But my code is full of `Deno.*`"

The trap: one line in `package.json` broke the tests