Run a fleet of coding agents. Approve what ships. Free, open-source control room for Claude Code, Codex and more.
USA
Joined December 2021
- Tweets160
- Following8
- Followers37
- Likes122
o8 retweeted
Fixed it for you bro.
Conductor is shutting down and we put together a list of alternatives.
Here is a new and expanded list with over double the alternative products.
There's 43 in total, sorted by coverage of Conductor's core defining features:
Paradev, Tembo, Multica, Continuum, Agentastic, T3 Code, Traycer, Kcap, OpenHands, Orca, Warp, Replicas, Paperclip, Paseo, Orchestrator, Niteshift, Cloudroom, bb, Ghostex, Superconductor, Podium, AQ, Devin, Ellipsis, Synara, Emdash, Maestro, Boxes, CloudCLI, QM, Herdr, OpenClaw, Nimbalyst, Murmell, Capy, Rex, Supacode, Intent, OpenChamber, Sculptor, Darting, Vorflux, ArkenOS
o8 retweeted
1.815 -> 1.816 a very big one and still more work to go! ported the desktop app to native rust + gpui across 237 prs. the new gpui window runs our parallel agent workflows natively now, starting w/ live worker panes right beside your chat.
everything that landed in 0.1.816:
- worker grid beside chat where each agent gets its own pane, live transcript & steer box (close a pane and it stays out, close the last main tab and chat takes its spot)
- working-changes review w/ a files drawer, all/last-turn/staged/unstaged scopes, line wrap, split line numbers, and commit + push + open pr from review
- composer @ mentions for files/threads/agents/worktrees/scripts/terminals, ! shell lines w/ timer + exit code, changed-files pill & drafts that survive restarts
- mission cards for lead-agent decisions + a live subagent roster, plus the workspace activity dock w/ see all & scoped ports
- 1m-line files editor that stays smooth + native mermaid diagrams in replies (er, gitgraph, gantt, mindmap, state, class, pie) w/ zoom & pan
- work w/o a project from your home folder or group repos & shared instructions on project cards (plus open in editor right from the header)
- resources per saved machine (cpu, memory, disk, network) w/ each machine's threads & workers beside your own
- vs code theme import, ui & code font pickers, chat width, rebindable shortcuts, per-project & per-machine settings, mcp + mobile pages, and sonnet 5.5 + haiku 5.5 w/ updated cost estimates
Much more to come, tell a friend to tell a friend!
o8 retweeted
o8 runs on linux *much better* now
AppImage, .deb and .rpm are up on the release. I built it on debian 13 and ran a full day of agents on it: glass ui, local whisper voice, and the app server only listens on your own machine.
linux people, what release are you on, and what breaks first?
github.com/o8-run/o8/release…
o8 retweeted
o8 0.1.810 is out.
I asked my lead to look at the week so far: 417 PRs merged, 12 releases, 146 on the peak day. The native app got the most new features. GPUI loading.
github.com/o8-run/o8
o8 retweeted
Redesigned dark mode (and light but idk who cares lol), header, chat rail, nav rail, shared worktrees vs separate for workers, chats & terminals drag to split, visualizations, gpt live voice baked into any cli (more on this soon), composer images stay put clicking around before sending, a bunch of stuff along with the reliability fixes.
I’ve been requesting percentage on long tasks from the auto agents as they go, I’ve noticed it keeps them on track with looking back at what work was done already and quantifying what we have to do next.
Much less ‘after compaction’ context loss w/ slightly more usage because the doc must be read (this one is 44 pages) but if you have the bandwidth for it add a percentage bar to your plan doc.
It does a little bit more than just give you a visual indicator and can be used as a canary as well. If the agent isn’t updating you on the percentage bar then compaction may be needed.
Burn down agent 35/200 overnight, not bad, not bad at all.
o8 retweeted
An autonomous video introduction to o8.
Added: My Voice
Agent Annotations
Small Explanations
(Episode 04)
Eventually we are going to move wayyy past IDEs….and even past ADEs (Agentic Development Environments).
The next frontier of software engineering is likely Level 4 Autonomy: Self-Evolving Codebases.
Soon, we won't just orchestrate AI agents; we’ll maintain a living product spec (via voice) while autonomous platforms self-heal, optimize code, and push features based on real-time telemetry.
The developer's role is shifting from code generation to pure architecture and intent validation.
o8 retweeted
We spent last night and this morning testing Jev, the new judgment model from TypeSafe AI, against o8's own approval history. It does not write anything. You hand it a state and typed questions and it hands back probabilities and a confidence. That shape is exactly what a governance layer wants, because the model can never act, only answer.
What we found on 126 real approval diffs from o8's database (91 distinct), 1,408 calls, $0.55 total:
Speed: about 260 ms per call on a 12K token diff.
Is this diff only documentation? Show it one docs-only diff and one code diff, and it picks the right one every time. We checked 118 diffs against the actual file paths. Does this diff add tests? Same setup, right 98 times out of 100.
Will this diff fail our merge gate? Show it one diff that failed and one that passed, and it picks the failing one 94 times out of 100.
Brain question routing (factual vs narrative): 24 of 24 on our labeled set, where the keyword fallback got 16.
Where it broke, which matters more. When we removed o8's own rule-risk number from the state, a fake "Reviewed-by" trailer inside the diff moved 6 of 6 diffs toward auto-approve. A lying title flipped the docs-only answer 6 of 6.
Padding a diff with 15K tokens of noise moved the scope-creep answer by 0.61. With o8's own computed facts anchored in the state, none of the injection moved it.
So the rules we wrote down: o8 computes the state, never the worker. Never use the model's recommended action, only per-question answers with thresholds. Thresholds only on risk and docs-only, fit from your own install's history with held-out packets. Strip anything the worker wrote before asking. Confidence under 0.4 means abstain. Everything behind a setting, default off, with the local path as fallback.
What is going into o8 this week, all advisory and none of it touching the merge decision: a referee row on approval cards, a first-tier classifier for the Brain, a gate-failure warning recorded before the one automatic rerun, and a calibration replay script that fits thresholds from your local approval history. Next is the phone: a referee-ordered inbox and one-tap approve chips, all computed on the desktop, the phone never calls the model. Then ranking browser actions per step.
The cheapen story is not the model's price, though $42 per billion input tokens is cheap. It is that worker reruns are where the money goes, and a 260 ms question before each rerun is worth asking.
The build ran as Claude Fable 5.1 orchestrating, Claude Opus 5 workers in ginsu seats, and o8 Claude Sonnet 5 reviewers told to refute. Same as always: the tests through the real entry point are what earned the merge.
o8 retweeted
The laptop is already becoming the wrong unit. I think the next jump is main agent or agents holding the goal while it spins up the machines and workers it needs, then hands back one result to review.
o8 retweeted
o8 is open source today. MIT.
Agents do the work. You run the room.
One orchestrator scopes what you asked for and dispatches a fleet across 13 agent runtimes. Every worker stays isolated in its own git worktree. Nothing merges until you approve it.
• Approve what ships — every diff reviewed, high-risk work escalated, your sign-off on the merge
• Use the agents you already pay for — Claude Code, Codex, Gemini, opencode, one adapter contract
• Canvas — turn the IDE into a work surface and work with the thing itself
• Speak to the whole system — Symon dispatches by voice through the same gate
• Run the room from your pocket — approve or reject from your phone
• The fleet remembers the work — repeated fixes come back as rules you accept or reject
Fork every line. Change the interface, add a runtime, replace a workflow, or ship your own build.
Free, macOS, runs on the subscriptions you already have. 30 releases in the last 14 days. I built it with itself.
Repo in the first reply.
o8 retweeted
The o8 workflows that actually save us hours, in one place:
1. Patch inspection taught me that missing evidence must fail loudly. An agent that fills gaps with plausible code is worse than one that stops.
2. Phone model choice exposed a contract boundary I’d treated as plumbing. User intent has to survive every handoff or the control is cosmetic.
3. A port probe passed alone and failed under shared runs. Isolation is part of correctness when agents test concurrently.
4. Conflicting packet state taught me to keep one terminal authority. Every card, receipt, and status view has to reconcile against it.
5. Browser work needs containment too. I accept less worker freedom to keep previews observable and inside the workspace.
o8 retweeted
We decided o8 should run where your code already lives: on your machine.
The tempting architecture was obvious: upload the repo, run agents in our cloud, send the patches back.
It would have made deployment easier.
It also would have created a second copy of your source, a second credential boundary, and a remote system capable of modifying your code.
That is the wrong trust model for autonomous agents.
1. The repository stays local.
o8 runs as a macOS desktop app. Agents work against isolated git worktrees on your disk.
Each lane gets its own checkout and branch. It cannot reach another lane or touch main.
o8 never needs to upload your repository to an o8 server just to orchestrate the work.
2. Credentials stay under your control.
Your agent credentials live in the OS keychain, not in a dashboard database we operate.
You bring the accounts you already use. o8 coordinates them without becoming another vendor holding the keys to your engineering stack.
3. Local-first makes isolation real.
Worktrees are not simulated sandboxes or remote copies that drift from the repository.
Agents operate against the actual local git history, dependencies, scripts, and filesystem boundaries.
When two lanes touch the same file, o8 can surface the collision before either reaches main.
4. Autonomy stops at the gate.
Local execution does not mean unrestricted execution.
Before a lane can merge, o8 rebases it, runs typecheck, locks the reviewed head SHA, and queues merges in order.
Nothing lands without operator sign-off.
The agents can work independently. The repository cannot approve itself.
5. We accepted the tradeoffs.
Local-first is harder to build.
The machine has to manage processes, worktrees, lifecycle recovery, credentials, and concurrent git state. A browser-only product would have hidden more of that complexity on our servers.
We chose the harder architecture because the easier one moved trust away from the developer.
6. Mobile became a control surface, not a code host.
You can review and approve or reject in two taps, while the actual work remains anchored to your machine.
The replayable audit trail records every packet, decision, and merge without turning our infrastructure into the owner of your repo.
That is what local-first unlocks: a fleet that can move quickly without asking you to surrender the machine, the credentials, or the final say.
Your agents can be autonomous. Your code should still belong to you.
o8 retweeted
A multi-model coding fleet fails when every agent is allowed to redefine the job.
That was our early mistake in o8.
We assumed better prompts and more context would keep parallel agents aligned. Instead, each agent interpreted the repo, scope, and handoff differently.
The fix was not a larger context window. It was stronger coordination.
1. Give every agent a fixed role.
We stopped renegotiating responsibilities inside every prompt.
The orchestrator now decomposes the intent into bounded lanes with a clear owner and finish condition. Each agent knows what it may change, what it must return, and where its responsibility ends.
Less improvisation. Fewer overlapping rewrites.
2. Treat handoffs like APIs.
“Investigate this and help the next agent” is not a handoff.
We use output contracts: changed files, assumptions, evidence, unresolved risks, and the exact result the next lane can consume.
A structured handoff beats dumping another 20,000 tokens into context. More context gives an agent more information; a contract tells it what matters.
3. Make agents check each other.
The agent that writes a patch should not be the only agent judging it.
One lane implements. Another can review the result against the task and repo evidence.
Different reasoning paths catch different failures: invented assumptions, missed edge cases, unnecessary scope, or code that looks correct without fitting the surrounding system.
4. Isolate execution, not just prompts.
Every o8 agent works in its own git worktree. It cannot reach another lane or touch main.
That stopped agents from overwriting files mid-task, but exposed the deeper problem: two isolated agents can still form incompatible assumptions about the same surface.
So when lanes touch the same file, o8 surfaces the collision before anyone ships.
5. The orchestrator is an assumption manager.
Dispatch is the easy part.
The real job is preserving scope, ordering dependencies, enforcing handoffs, and preventing one agent’s local truth from silently becoming the fleet’s shared truth.
Then the review gate rebases, typechecks, locks the reviewed head SHA, and merges in order only after operator approval.
That is the tradeoff: more structure around the agents, far less chaos around the code.
o8 taught us that a fleet does not become reliable by making every agent smarter.
It becomes reliable when the system makes disagreement visible before it reaches main.
o8 retweeted
Autonomous coding only gets interesting when the agent is powerful enough to scare you.
That was the design pressure behind o8's review gate.
We wanted a local-first desktop app that could run a team of coding agents, not one chat box with a bigger prompt. Claude, Codex, Gemini, each doing real repo work in parallel.
But the obvious version is unusable:
“Agent finished. Pushing to main.”
No.
That turns your repo into a black box with commit access.
So we put a governance gate between the fleet and main.
1. No agent touches main.
o8 decomposes your intent through an orchestrator, then dispatches agents into isolated git worktrees.
Each lane has its own checkout.
Each lane has its own branch.
Agents cannot reach each other’s worktrees.
Agents cannot quietly mutate main.
That isolation is boring until the first time two agents both make “correct” changes that conflict in the same file.
2. The thing that broke first was parallel confidence.
One agent changed a shared component.
Another changed the same surface from a different direction.
Both diffs looked reasonable alone.
Together, they were not safe.
So o8 treats file overlap as a control event, not an afterthought. If two lanes touch the same file, the operator sees the collision before it becomes a bad merge.
3. The gate does the mechanical discipline every time.
Before anything lands:
Rebase onto current main.
Run typecheck.
Lock the expected head SHA.
Queue the merge in order.
Wait for operator sign-off.
The head-SHA lock matters. You approve the commit you reviewed, not whatever the branch became 30 seconds later.
Ordered merge matters too. A fleet should not race itself into main.
4. Approval is a product surface, not a terminal chore.
The operator gets the diff, check status, conflict context, and replayable audit trail.
The Engineering Brain can answer repo questions with citations, so “what changed?” and “why does this file matter?” do not require spelunking.
On mobile, the decision compresses to two taps: approve or reject.
5. The tradeoff is intentional.
Yes, the gate adds friction.
But the cost of a wrong merge is higher than the cost of a clean checkpoint.
Autonomy without a gate is just permission you hope does not get abused. Autonomy with a gate is throughput under control.
That is what we are building with o8: macOS, Apple Silicon, local-first, free with your own Claude/Codex keys, a fleet of agents that can move fast without owning the final say.
The bottleneck was never capability. It was control.
o8 retweeted
The fastest way to ruin a coding-agent fleet is to let every agent share one checkout.
That was one of the first hard o8 lessons.
A single agent in one repo can look impressive. Multiple agents in the same tree get weird fast.
One edits a component.
Another rewrites the hook it depends on.
A third runs tests against a state that no longer exists.
Now nobody is technically “wrong,” but the repo is lying to all of them.
So we made the boring decision that unlocks the whole system:
Every o8 agent gets its own git worktree.
1. Isolation first.
o8 is a local-first desktop app for running a team of coding agents: Codex, Claude, Gemini.
One orchestrator breaks down your intent and dispatches the fleet.
Each agent gets its own lane:
own git worktree
own branch
own filesystem view
own assumptions
no access to the other agents’ lanes
no access to main
That means an agent can move quickly without trampling another agent’s edits mid-thought.
2. Parallelism without shared-state chaos.
The point of a fleet is not “one mega-agent with a larger context window.”
A mega-agent serializes everything through one reasoning path. It gets slower, softer, and more tempted to solve unrelated problems in one giant diff.
A fleet lets agents specialize:
one fixes the failing type path
one updates the UI
one writes the adapter
one checks the edge case
Separate worktrees make that parallelism real instead of theatrical.
3. Conflicts become visible early.
Isolation does not mean pretending conflicts vanish.
If two lanes touch the same file, o8 surfaces that collision before anything ships.
That is the difference between “the merge exploded” and “two agents are reaching for the same surface; operator, decide.”
We would rather turn conflict into a review event than discover it after main is already dirty.
4. Main is behind a gate.
An agent finishing work is not permission to merge.
o8 rebases the lane, runs typecheck, locks the reviewed head SHA, then queues merges in order.
Nothing lands without the operator’s sign-off.
On mobile, that decision becomes two taps: approve or reject.
5. The audit trail matters.
When a lane finishes, you can inspect the diff, checks, history, and repo context. The Engineering Brain can answer questions with citations instead of vibes.
That makes review faster without making it blind.
The tradeoff is a little more ceremony per lane. The payoff is that autonomous coding stops being a black box with commit access.
o8 is macOS / Apple Silicon, local-first, free with your own Claude/Codex keys, built around this idea:
o8 retweeted
o8 beta is LIVE, using my last bit of Fable 5 for fixes with you all.
youtube.com/live/UGcUA30vnxY…
