gnet — the pitch

Problem

Single-agent code review, even with Claude Opus, has three expensive failure modes:

Serial blind spots. One agent reviewing a whole repo trades depth for breadth — the security pass and the performance pass and the docs pass all compete for the same finite context window.
Wrong model for the job. Spending Opus tokens on style/lint/docs review is a 5× overcharge versus running those tasks on Sonnet.
No team memory. Each rerun re-analyzes the codebase and re-plans the agents from scratch. There is no "bring the same team back tomorrow".

Commercial agentic IDEs (BridgeSpace, Cursor, Windsurf) solve this by running background agents on remote infra with their own account, billing, and opaque orchestration layer. That's a tradeoff — you get a polished UI but you pay a subscription and cede control of the agents, the prompts, and the data.

Solution

gnet is the OSS, local-first, zero-infra version of that idea, purpose-built around Claude Code:

Dynamic meta-planner. An Opus planner reads a precise codebase analysis and designs a bespoke 3–16 agent team for your repo. No preset roles — a Rust monorepo gets different agents than a Django app.
Live tmux grid. Each agent is a real interactive claude session in its own pane. You can watch them work, zoom into any pane, type directly at any specialist.
Shared board coordination. Agents and the conductor post to .gnet/board.md — the poor man's message bus. Readable, greppable, diffable.
Opus + Sonnet routing. Heavy roles (architecture, security, perf, data) run on Opus; focused roles (tests, docs, style, CI) run on Sonnet. Plus prompt caching. Typical savings: 40–60% vs all-Opus.
Savings report. Every gnet synth prints a token + dollar breakdown so you can see exactly what gnet cost vs what the naive baseline would have cost. No trust required — the numbers come straight from the Claude Code JSONL transcripts.
Persistence. .gnet/roster.json + .gnet/sessions/*.json let gnet resume rebuild the same team (same ids, same personas, same board history). Fresh Claude session-ids per resume, but the file-based context carries over.
Read-only by contract. Every agent is constrained to Read/Edit/ Grep/Glob and every planned task is phrased as "review/audit/propose/ recommend". Agents never rewrite your source — you act on their recommendations yourself.

What makes gnet different

Claude-native. Not a framework that happens to call Claude — it uses Claude Code's real interactive CLI with --session-id, --add-dir, --append-system-prompt, and --allowedTools. You inherit everything Claude Code does well.
Zero infra. No servers, no accounts, no daemons, no SaaS. If you can run claude locally, you can run gnet.
Opinionated safety. Meta-planner rejects Haiku. Schema-validated rosters. Non-overlapping tasks. Read-only agents. Nothing to go rogue.
Observable. Everything lives in .gnet/ as plain files you can tail, grep, diff, version, delete. No black box.
Extensible surface. MCP server (gnet mcp), web GUI (gnet gui), voice input (gnet voice), runtime abstraction (claude + codex stub) — all ride on the same file-based core.

Who it's for

Solo devs who want a "second pair of eyes" across an unfamiliar repo without handing it to a SaaS.
Teams doing pre-review sweeps before PR — architecture, security, perf, docs all in one attach.
OSS maintainers triaging incoming contributions.
Anyone who finds "just run Claude on it" insufficient for a repo larger than a single file.

Non-goals

Not a CI tool. gnet is interactive by design. Use it at your desk, not in pipelines.
Not a code generator. Agents review; humans change code. This is deliberate — the blast radius of autonomous code-writing agents on a real repo is not worth the speedup.
Not a multi-user platform. One user, one repo, one tmux session.
Not a replacement for PR review. It's a tool for the solo engineer preparing for PR review, not the team conducting one.