u/AccomplishedLab3697

**Open Source!**

I built o8 after Codex and Claude became daily tools for me.

Once I had several agents moving across production repos, the work around them started taking over. I was deciding who should lead, splitting jobs cleanly, keeping agents from touching the same state, reviewing every diff, and trying to remember why we made a decision three days ago.

o8 sits above the runtimes I already use. One agent can orchestrate while other supported agents take bounded pieces in separate copies of the repo. Workers cannot approve or merge their own changes. Their work goes through independent review and then comes back to me, and the Engineering Brain can answer what changed across repos with citations instead of making me dig through old chats.

On Mac, Symon adds a voice layer over the same system. I can dictate into whichever app is focused, ask what the fleet is doing, have it watch a terminal, or give it a command without hunting for the control room. Anything with a side effect still waits for confirmation.

I can also check the fleet and handle approvals from a paired phone or browser. The system still runs on a machine I own rather than inside a cloud IDE.

The signed Mac build is available now. I also published unsigned Windows 11 and Linux preview installers. Windows 11 has been runtime-verified. Linux has AppImage, deb, and rpm builds, but Linux desktop verification, signing, and updates are still open. These previews may trigger operating-system warnings, and checksums are included.

If one agent in one repo covers your work, this is probably too much. It starts making sense when you are running several agents or several repos and need review authority, memory, and one place to supervise the whole thing.

Project: https://o8.run
Source: https://github.com/hurttlocker/o8
Windows and Linux previews: https://github.com/hurttlocker/o8/releases/tag/v0.1.664

If you already use Codex or Claude, where does your setup start becoming work: coordinating agents, reviewing their changes, or keeping context between sessions?

My main runtime hit its usage wall this week so I needed a fallback chain for an agent pipeline that runs all day. Instead of guessing, i ran 6 candidates through the real prompts and had two blind judges score the outputs, one for quality and one for factual grounding.

The one I put first ranked #2 on quality. The reason: when it fails, it fails loud — it occasionally dumps its reasoning scratchpad instead of an answer, which my guard catches and drops. The model that ranked #1 fails silent. It took 43,877 and wrote "45,000." On a pipeline where the whole point is the exact number, a fluent wrong answer nobody re-checks is so much worse than a visible mess.

Other thing the bench almost missed: prompt size. every candidate was clean at around 3.5k tokens. At 7k on the same task, one went to empty completions every single time and another started dumping reasoning. A bench that only tests one prompt size tells you almost nothing about the model you'll actually run.

Made me rethink how I pick models in general, im weighing failure visibility as its own column now next to quality.

How do you all handle fallbacks — do you pick by benchmark rank or does failure mode factor in?

Run more than one coding agent and your day becomes five terminals, no shared memory, and git log as your only audit trail. Every vendor's answer is "use only ours."

o8 is the layer above all of them. One orchestrator scopes the work and dispatches it, every worker runs in its own git worktree, and nothing merges until you approve it. Claude Code, Codex, Gemini, Aider, Goose and eight more run behind a single adapter contract, so you're not picking a lab and living inside their box.

What's in it:

• Merge gate — rebase, typecheck, head-SHA lock, ordered merge. Workers can't merge their own work; execution and approval are separate authorities by construction.
• Engineering Brain — ask about your repo or your fleet's history, get answers with citations. "What did the agents ship yesterday" is a query, not archaeology.
• Organizational memory — repeated fixes come back as proposed rules you accept or reject.
• Replayable audit trail — every packet, merge and decision is a row in SQLite on your own disk. No telemetry; it's off by default and opt-in.
• Mobile — approve or reject a merge from your phone while the fleet keeps working.
• Canvas — the IDE as a work surface, with agents, diffs and a live preview side by side.

Free, MIT, and it runs on the subscriptions you already pay for. macOS today; Windows and Linux are mapped and in progress. ~88MB, signed build, auto-updates.

I built it, and I used it to build itself — 5,500+ commits, most of them dispatched through it.

Issues are open, and adding a runtime is a documented patch — the adapter contract is one file. If there's a CLI you want in there, that's the shortest path to a merged PR.

What are you using right now to stop two agents from stepping on each other?

Something nobody tells you when you start using Claude Code / Cursor / Codex / any of these: every session gets saved to your disk. The whole conversation. Forever.

Which is fine — until you remember that time you pasted an API key straight into the chat "just to test something." Or the agent printed your env vars while debugging. Or a stack trace with your database URL in it. All of that is sitting in plaintext files in folders like ~/.claude right now, and it happily tags along into your Time Machine backups, your Dropbox sync, that screen share last week.

Not a scary-hacker thing. It's the same as your shell history — boring housekeeping, except for a history most people don't even know exists. Go look at the folder, honestly, it's eye-opening.

A friend of mine, Ishan — solid dev, better known in the Cardano world — built a tool for exactly this cleanup, just trying to give people something they can actually use. It checks the local history of ~29 different agents for a couple hundred secret patterns, runs fully offline (nothing leaves your machine), and just scans by default — it only redacts if you tell it to, and it makes backups you can undo from. Genuinely beginner-friendly.

Two things worth doing with it: don't trust me or him — point your own agent at the repo and ask it for a safety review before you run anything (good habit for every tool you find on the internet, this one included). And if it misses a pattern or you want your runtime covered, open a PR — he's responsive. Link in the comments.

Not my project, just vouching for the guy and the idea. What do you all do about old sessions — clean them, ignore them, or is this the first you're hearing that they exist?

Anthropic's Fable 5 runs my agent fleet, and I had it write down the discipline behind how — the thing that keeps its context window tiny while sessions that skip it drown in their own file reads. I generalized it and open-sourced it as one markdown skill: token-lean.

It's fully model-agnostic. The same discipline runs on Fable 5, GPT-5.6 sol, Opus, Gemini, Grok, or open-weights — the orchestrator changes, the discipline doesn't.

The core rule: never generate bulk, never absorb bulk. The orchestrator's window only holds decisions, briefs, and compact reports. Everything else happens in cheaper contexts.

The parts that changed my sessions the most:

• The ladder is roles, not model names. Scout → worker → builder → panel. Haiku/Sonnet/Opus-and-Fable, GPT-5.6 luna/terra/sol, Flash/Pro — all the same rows. And effort dials count as rungs: the same model at low effort and xhigh are two different tiers.
• >3 file reads = you should've sent a scout. You want the conclusion, not the pages.
• 1KB hand-backs. If a sub-agent returns a transcript instead of a report, you briefed it wrong.
• One big brief beats twenty steers — every mid-flight nudge re-meters your whole window.
• Pre-digest inbound bulk — except security/auth/payment diffs, which you always read raw. A summary can encode the proposer's error.
• Never let a builder grade its own work. Independent reviewer, told to refute.

Install is 30 seconds (Claude Code skill or plugin; pastes into AGENTS.md/.cursorrules for Codex/Cursor). No binary, no MCP server, no deps — it's a discipline, installed as words.

Repo: https://github.com/hurttlocker/token-lean

Disclosure: I build o8 (a governance layer for agent fleets) and this is extracted from how we actually run it. The skill is MIT and does not need o8 for anything.