Model Boss orchestrates Claude Code and Codex across multiple models. Delegate bounded implementation to lower-cost workers while a stronger model approves plans and final evidence. Work runs in disposable worktrees with OS sandboxing, tool limits, hash-bound approvals, and test gates.
No reviews yetBe the first to leave a review for Model Boss
Maker
📌
Hey Product Hunt — I'm Vince, maker of Model Boss. I built it after noticing that the costly part of AI coding is often keeping the strongest model on the main loop for every implementation detail. Model Boss separates execution from authority: Lite keeps planning and review in the host session, while Max uses a distinct verified reviewer for the plan and final evidence. Workers run in disposable worktrees with OS sandboxing and restricted tools; approvals are bound to the source snapshot, worker delta, and projected patch, so changed evidence invalidates an old approval. The repository includes fixtures, a blind-test probe, and the full benchmark methodology. In its recorded large constructive run, Max reduced strongest-model output tokens by 89% and a price-weighted quota proxy by 88%; these are scoped historical measurements, not a promise for every model or task. It is MIT-licensed and works with Claude Code and Codex. I would love feedback on where you would most want an independent review gate: migrations, refactors, or multi-file features?
Report
Finally something that lets cheaper models handle the busywork while Claude or Codex sanity-check the plan and the results, and the worktree sandboxing means I stop worrying about one agent trashing another's files.
Report
Maker
@freddiemercury Thanks, Freddie — that’s exactly the boundary I wanted to make explicit: workers can do bounded work, but they never get to declare their own result safe. The original repo stays untouched until the gates, diff audit, and authority review agree on the sealed patch.
One important caveat: the sandbox is isolation, not a network-security boundary, so Model Boss still requires trusted provider binaries and least-privilege credentials.
Report
The cheap-worker/frontier-approver split maps neatly onto a routing gateway — do you pin each role to a fixed provider, or could Model Boss point its workers at a single Anthropic-compatible endpoint and let the gateway resolve which upstream model serves each tier? Curious how you handle cost/latency accounting across the disposable worktrees.
Report
Maker
@tian_yi1 Great question. Roles aren’t pinned to vendors — Model Boss routes by capability — but an endpoint or alias is never treated as identity proof.
You can put a routing gateway behind an external route, but v0.2 does not ship a generic Anthropic-compatible gateway adapter yet. For Max, the gateway (or a pinned adapter around it) must prove the effective provider_family:model_id:variant for the actual child invocation. If it can dynamically route without that evidence, Model Boss fails closed rather than assuming that two gateway aliases are independent models.
On cost/latency: v0.2 intentionally does not maintain a normalized cross-provider billing ledger. Each worker invocation has its own manifest, worktree, gate evidence, and sealed delta, but provider usage accounting remains upstream today. A gateway that emits per-request usage is a natural aggregation point; an optional per-invocation telemetry hook is something I’m considering. Curious whether your priority is chargeback, adaptive routing, or latency SLOs?
Finally something that lets cheaper models handle the busywork while Claude or Codex sanity-check the plan and the results, and the worktree sandboxing means I stop worrying about one agent trashing another's files.
@freddiemercury Thanks, Freddie — that’s exactly the boundary I wanted to make explicit: workers can do bounded work, but they never get to declare their own result safe. The original repo stays untouched until the gates, diff audit, and authority review agree on the sealed patch.
One important caveat: the sandbox is isolation, not a network-security boundary, so Model Boss still requires trusted provider binaries and least-privilege credentials.
The cheap-worker/frontier-approver split maps neatly onto a routing gateway — do you pin each role to a fixed provider, or could Model Boss point its workers at a single Anthropic-compatible endpoint and let the gateway resolve which upstream model serves each tier? Curious how you handle cost/latency accounting across the disposable worktrees.
@tian_yi1 Great question. Roles aren’t pinned to vendors — Model Boss routes by capability — but an endpoint or alias is never treated as identity proof.
You can put a routing gateway behind an external route, but v0.2 does not ship a generic Anthropic-compatible gateway adapter yet. For Max, the gateway (or a pinned adapter around it) must prove the effective provider_family:model_id:variant for the actual child invocation. If it can dynamically route without that evidence, Model Boss fails closed rather than assuming that two gateway aliases are independent models.
On cost/latency: v0.2 intentionally does not maintain a normalized cross-provider billing ledger. Each worker invocation has its own manifest, worktree, gate evidence, and sealed delta, but provider usage accounting remains upstream today. A gateway that emits per-request usage is a natural aggregation point; an optional per-invocation telemetry hook is something I’m considering. Curious whether your priority is chargeback, adaptive routing, or latency SLOs?