# Building Starbridge in four days
2026-10-08 · https://tomvaucourt.com/posts/building-starbridge/
I built [Starbridge](https://github.com/T0mSIlver/starbridge) in four days. The idea came on 4 October around 18:50, and v0.1.0 was tagged on 8 October at 10:21. In between, about 200 Claude Code sessions merged 450 pull requests, and I wrote them 443 prompts.
Starbridge puts a coding agent's question on your phone and in your browser. You answer with one tap, and the waiting session carries on with your answer as its next prompt.
Claude Code asks which model to run an eval on. The question lands on the phone, the tap goes back into the session as its next prompt, and the run's progress shows on the lock screen. I recorded it on my own phone.
## The idea came out of a conversation
I run many coding agent sessions at once, mostly Claude Code, some Codex and opencode. My Mac and my phone buzz all day, and the one notification that matters, an agent stuck on a question, gets lost in the rest.
Starbridge didn't start there. On 4 October I was asking a Claude Code session for an Android app to build for [localvoxtral](https://github.com/T0mSIlver/localvoxtral), my dictation app. Every idea was a way to queue work from the phone, and I didn't want any of them. I dictated this:
> When I'm on the phone, I'm not orchestrating multiple agents, I'm only talking to the orchestrator.
I had it close that issue, then asked the same session whether my workflow gave it an idea for another app. It proposed "an app for supervising your agents from the phone": decisions as notifications, and the quota windows of my AI plans. I dictated 605 words back. Two sentences from them became the product:
> I would love for this app to be the center of the orchestration of all of my agents. So this would be a global `CLAUDE.md` rule: whenever you need me, use this skill that explains how to get the things to me.
The spec was committed 12 minutes later, at 18:57. At 20:28 I typed "starbridge it is", and at 20:40 the orchestrator session started in the new repo.
## I talk to agents a lot
Most of what I tell agents, I say out loud, with localvoxtral. Dictating changes what I say. I give more detail, and I don't second-guess or correct myself: I say things as they come to me, as I understand them. So the agent knows what I'm actually thinking, and it can steer me and show me exactly where I'm wrong.
Agent prompts are full of project names, and speech models don't know them: "VidTech" for [vidtheque](https://github.com/T0mSIlver/vidtheque), "star bridge" for Starbridge, "harder pain" for a herdr pane. A week before Starbridge, I had [given localvoxtral my repo and skill names](https://github.com/T0mSIlver/localvoxtral/issues/1024). On a test built from my own dictations, it got 97% of the 182 names right, against 48% without them.
In four days I sent 443 prompts, about 15,400 words. Half of them are 16 words or fewer: "merge it", "yes", a correction. The long ones carry the ideas. 7% of my prompts are 100 words or more, and they hold 40% of the words.
Two thirds of my prompts went to the orchestrator. I wrote directly to 18 of the 206 sessions, fewer than one in ten.
The rest of what the orchestrator needed from me came as questions, and they need one place of their own. An orchestrator does so much that its chat gets long, and a question asked there gets buried. Before Starbridge, mine put its questions on a [needs-you](https://github.com/T0mSIlver/skills/tree/main/needs-you) page I kept open in the browser. During the build they came to my phone: agents posted 138 questions through `starbridge ask`, 70 of them on 6 October.
On 7 October I dictated how answering from the phone had changed the way I steer agents:
> So it's basically steer, but you're not watching how the agent reacted; you're steering, etc. You just wait for the next notification.
A question card on Android. The recommended answer comes first.
## One orchestrator, about 200 sessions
The orchestrator is one Claude Code session in Claude Desktop, on Opus 5.5 at medium effort, following an orchestration skill I wrote. It doesn't write features. It splits the work into GitHub issues, 383 by launch, and suggests a chip for each, a button in Claude Desktop that I click to start a new session. It suggested 174. Each session gets its own git worktree and branch, and opens one PR.
The sessions and the orchestrator talk through Claude Code's new inter-session messages: the orchestrator sent 702 over the four days. It merged the PRs one at a time, through a queue that waited for each deploy to pass, and archived 241 finished sessions. Two rules from my skill did most of the work. State lives in files, because sessions run out of context and get restarted: a planning repo, the orchestrator's memory, and a handoff on each PR. And a session left idle past its one-hour prompt cache gets archived after its handoff, never woken up, because waking it re-sends its whole context at twice the input price.
This is why I don't use Claude Projects, Anthropic's new feature for the same job, still in preview. Its coordinator only routes work to other sessions, and you can't really see what it does. My orchestrator does a lot: it schedules, briefs, merges and asks me questions, and its context fills so fast that I often compact it. Orchestrating is hard, so mine runs at medium effort, where Projects' coordinator runs at low.
The orchestrator can't be archived, so it has to stay warm, and its context sat around 327,000 tokens. I built a small Claude Code mod for it, orchestrator-cache, and I use it all the time to save my Claude limits. It sends a one-word keepalive after 50 idle minutes. During the build it fired 9 times, mostly the night before launch while I slept. At API prices a keepalive costs about €0.06, and a cold wake-up about €2.30.
## Reviews
Every change got a review from a model by another vendor before merge, through my [cross-review skill](https://github.com/T0mSIlver/skills/tree/main/cross-review). It runs the reviewer headless and read-only on a frozen copy of the change: GLM 5.3 through opencode first, GLM 5.3 on the Mistral API through Vibe next, and Codex last. That made 494 review runs.
Cross-vendor review runs per day, by reviewer. Each run reviews one change, or one round of fixes to it. The number after each bar is the day's total; 11 more runs ended with no review.
The reviews follow the merges: 104, 203, 89 and 30 PRs on those four days. On 5 October Vibe took almost half the reviews, because Z.ai's 5-hour window ran out overnight and again that evening, and Codex's weekly limit was nearly spent. 6 October had the most merges, and Codex reviewed in the late morning until its window ran out at noon. 7 October merged fewer PRs, but that afternoon the orchestrator caught up on reviews after merging: 18 PRs without a GLM review, and 17 on critical paths without a Codex one. 8 October was launch day, behind a code freeze.
Security got its own reviews. On the night of 5 October, Codex ran two audit rounds and found 26 issues for about 0.9 million fresh tokens, which are tokens not read from the cache. All were fixed or deferred to after launch ([#260](https://github.com/T0mSIlver/starbridge/issues/260), [#274](https://github.com/T0mSIlver/starbridge/issues/274)). The next morning, a single Opus 5.5 session found 4 more for 0.25 million ([#302](https://github.com/T0mSIlver/starbridge/issues/302)).
Then I tried the claude-security plugin's scan workflow on the protocol ([#366](https://github.com/T0mSIlver/starbridge/issues/366)). It ran 133 Fable 5.1 agents for 84 minutes and used about 11 million fresh tokens, plus 108 million cache reads. It verified 11 findings out of 27 candidates, and all 11 were real. That is under one real finding per million fresh tokens, against 16 for the single Opus session. Three of its most severe findings came from the auditor reproducing them, not from the agents' vote.
It also ran on borrowed limits. My weekly Claude limit was at 98% the night before, and I spent a rate-limit reset Anthropic had handed out a few weeks earlier. At 18:00 on 6 October the orchestrator started three more scans of the day's changes, and I stopped all three within 20 minutes. The crypto review on 7 October found two real problems, with Codex and one Fable session, for under half a million tokens each ([#811](https://github.com/T0mSIlver/starbridge/pull/811), [#812](https://github.com/T0mSIlver/starbridge/pull/812)).
I don't think multi-agent workflows are worth it, unless your inference is free and unlimited. One session that knows what I want, because I told it at length, plus an adversarial review by another vendor, finds more for each token.
## The tokens
| Harness | Model | Sessions | Tokens | Cache reads | At API prices |
|---|---|---:|---:|---:|---:|
| Claude Code | Opus 5.5, some Sonnet 5.5 and Fable 5.1 | 206 | 8.78 billion | 8.69 billion | €2,419 |
| opencode | GLM 5.3 | 446 | 276 million | 251 million | €104 |
| Vibe | GLM 5.3 | 104 | 83 million | 74 million | €36 |
| Codex | gpt-6.1-sol | 102 | 58 million | 51 million | €20 |
opencode has more than twice as many sessions as Claude Code because a review is a session of its own. Each review starts fresh on a frozen copy of the change, reads the diff, and ends, so it uses 0.6 million tokens on average. An implementation session stays open through CI and fixes, and averages 42 million.
At API prices, the four days would have cost about €2,580 before VAT, and about €3,090 with France's 20%. I paid for plans instead, VAT included: €216 a month for Claude Max, about €23 for ChatGPT Plus, which runs Codex, €18 for Mistral, and a Z.ai Lite plan I bought a year ago for $36 a year. That is about €260 a month, or about €34 for four days.
Cache reads alone would have cost €1,562 at API prices. Without the cache, the same tokens at full input price would cost about €31,700.
## Activity over time
Each bar is one hour, Paris time. Dashed lines mark the first commit, the v0.1.0 tag and the launch.
The busiest hour for merges was midnight on 6 to 7 October, with 23 PRs. That evening I dogfooded Starbridge on my own devices, and the sessions fixed what I found in parallel: setup's first run, sign-in and pairing errors, the limits on machines and requests per account, and the inbox. Claude used 546 million tokens in the hour before, the most of the build.
The gaps are the nights I slept. On 7 October I had about 10% of my weekly Claude limit left until it reset at 22:00, so I spent it on a few things: the first release candidate and the npm package name, the Play closed test, installing Starbridge on my Mac as a new user, and the launch material. I sent the most prompts on 5 October between 21:00 and 22:00, 31 of them.
## CI
CI ran on every PR: unit tests, typecheck, lint, web end-to-end tests, Android screenshot tests, and the CLI on Windows.
On 5 October GitHub stopped starting Starbridge's CI jobs. The private repo had used about 2,040 Actions minutes in five days, more than its monthly allowance. The orchestrator moved CI to self-hosted runners, first on my dev box, then also on a mini PC ([#137](https://github.com/T0mSIlver/starbridge/pull/137)). The Android build went from 7.8 minutes to 1.7.
Then CI became the bottleneck: one end-to-end job in ten waited 17 minutes or more for a runner. I asked the orchestrator to [measure it](https://github.com/T0mSIlver/starbridge/issues/380). It skipped jobs a change can't affect, kept the build caches, and gave the runners four times the CPU weight of the agent sessions, and the end-to-end job went from 258 to 115 seconds.
All seven runners came off before the repo went public. On a public repo, anyone can open a pull request, and its CI would run their code on my machines.
## Load test
A load test answers a different question: will the server hold when people show up. At the size of the real server, 3000 simulated users cost it 190 MB of memory and 19% of one core, with a p99 latency of 14 ms.
## The agents used my browser
The launch needed accounts and consoles, and the agents did most of it in my own Chrome, through Claude in Chrome. Eight sessions made about 665 browser actions. They created the app in the Google Play Console, filled its listing and data safety form, uploaded the bundle, and sent the closed test for review. They moved the domain's DNS from Porkbun to Cloudflare, and worked through the Google Group for Play testers and npm's publishing settings.
They stopped where it was my call: the legal declarations in the Play Console, and the final "send for review", which a permission check wouldn't let an agent click. I clicked those myself.
## What I learned
Agents made building almost free. Everything around building still runs at my speed: knowing whether it's right, whether it's safe, whether the machines hold, and whether anyone wants it.
I used Starbridge as a user from the first night. At 00:33 on 5 October I installed the Android app and paired my phone, and that evening I walked through every flow with a session, reporting what felt wrong as I went. The rough edges kept coming as the features did. On 7 October, about 15 hours before the tag, the new CLI setup on my Mac showed the server as `[https://starbridge.run]`, and nothing about the brackets said "press Enter". It also asked again for the quota accounts my dev box already sends. The agents' tests passed every time. Tests prove the code does what the agents meant, and only using it shows whether it's what a user expects, so the dogfooding never stops.
I also shipped cryptography I can't judge myself. Claude built the encryption, Codex and a Fable session reviewed it, and nobody has audited it from outside. Agents let me ship past my own depth. What I can answer for is set by how far I can check, not by how fast they write. For anything people have to trust, I want an outside audit, or a plain statement of what was checked and what wasn't.
The bottleneck kept moving: AI plan limits, then GitHub's CI minutes, then RAM, then my own attention. Adding sessions only helps until a shared resource saturates. The sandbox ran out of RAM at about nine sessions, and past that, more agents meant more waiting and more crashes. I couldn't have predicted which resource would run out next: each one only showed up once the one before it was fixed. What worked was noticing it fast and measuring it. CI got faster the day I asked the orchestrator to measure it, and Gradle got its rules the afternoon the sandbox thrashed.
And building isn't distribution. I spent four days building and one post launching, and the post died at once. Next time a handful of people who run many agents get the app before launch. Google Play's closed test needs 12 testers anyway.
That's the bottleneck from my [About page](/about/): feedback. I use Starbridge all the time now. Try it, and tell me where it's wrong for you.
The code is at [github.com/T0mSIlver/starbridge](https://github.com/T0mSIlver/starbridge), and the free server is at [starbridge.run](https://starbridge.run).
