TabSplitAI
by Lang-Kevin
README.md
# TabSplitAI
A workflow engine for managing AI coding spend: it splits a plan → implement → review → evaluate loop across separate AI subscriptions, so each step runs against the budget best suited for it instead of every token going through whichever single tool you happen to be driving the session in.
## The problem: subscriptions don't share a budget
If you have access to more than one AI coding tool, they're billed separately and the usage isn't fungible between them — a Claude subscription has its own monthly allowance, a Copilot subscription has another, and a local model (Ollama, etc.) runs free but only handles lighter work. Left alone, a session routes every task — architecture, implementation, review — through whatever tool you happened to start in. There's no built-in way to push the expensive, high-volume work onto the subscription with more headroom and keep the low-volume, high-leverage work on the one with less.
## What TabSplitAI does
It hard-splits the workflow into four steps — `plan`, `implement`, `review`, `evaluate` — and assigns each to a specific agent identity, so usage lands on the subscription/budget you intend:
- **Plan & evaluate** (low-volume: once per phase/iteration) run on one agent.
- **Implement & review** (high-volume: every iteration, sometimes more than once per bug) run on a different agent, so the frequent work doesn't eat the budget reserved for planning.
State for all of this — current step, iteration count, whose turn it is — lives in `workflow-state.json`, so at any point there's one unambiguous answer to what stage the project is at.
## Other benefits
As a side effect of separating the steps into distinct agent identities, TabSplitAI also enforces that no agent reviews its own work: the engine records which agent implemented each iteration and refuses to let that same agent review it. This is structural, not a convention — `reviewMode` can be swapped between reviewers without changing how the guard works.
The long-term goal (Phase 7, in progress) is a fully unattended driver: point a session at this MCP server once with a goal, and it loops through plan/implement/review/evaluate on its own, dispatching to real tool integrations (e.g. `gh` for Copilot, a headless CLI invocation for Claude) until the project is complete or hits a guardrail.
## Requirements
- `gh` CLI installed and authenticated (`gh auth login`) — used to create/poll issues and PRs for Copilot-Builder/Reviewer.
- Target GitHub repo has the Copilot coding agent enabled (GitHub Enterprise/Business tier — `drive` polls for a PR linked to an `@copilot`-assigned issue and fails if none appears).
- `claude` CLI on PATH — used for the plan/evaluate steps (`claude -p`, inherits this repo's `CLAUDE.md`).
## Usage
```bash
npm run cli status # whose turn is it
npm run cli transition <status> # advance workflow-state.json
npm run cli drive [dir] [goal] # unattended plan/implement/review/evaluate loop
npm run dev # run as MCP server
```
## Status
- Phases 0–6 complete: file-based MVP, workflow automation, reviewer routing with the same-agent guard, full MCP service migration, standalone packaging.
- Phase 7 (unattended headless driver) — in progress, iteration 13.
- **Known limitation**: no bootstrap/init command yet. `drive` expects `workflow-state.json` and the `docs/` skeleton to already exist in the target repo — create them by hand before the first run.
See `docs/01-project-plan.md` for the full architecture and `CLAUDE.md` for the role rules every agent in this repo operates under.
This server cannot be deployed
Maintenance
ActivityMaintained
ResponsivenessSyncing