▸ self-hosted ticket loop
Your backlog, plowed.
Trau pulls your next ready ticket and drives it build → verify → PR → merge — every phase in its own cold, isolated agent.
One static Go binary. Point it at a repo and let it graze.
- Cold verify:every phase runs fresh, so the verifier never inherits the build agent's blind spots.
- Runs on your existing Claude Code / Codex / Kimi plan. Interactive, never headless.
- Self-hosted, local-first. No SaaS, no control plane, no vendor API key for Trau to hold.
runs on your existing subscription · interactive, never headless · one static Go binary · Apache-2.0 · trau.sh
move your cursor to plow the field 🐃
▸ the loop
One ticket. Seven phases. Each one cold.
Trau pulls the next ready ticket and plows it from build to merge — every phase in its own fresh, isolated agent process.
No --continue. No --resume. Each phase starts a brand-new agent that inherits only what it needs: a durable handoff brief and the code on disk. The build agent's reasoning — and its blind spots — never carry forward.
- build
Writes the code against the ticket, its acceptance criteria, and its non-goals.
- handoff
Distills what changed and why into a brief the next agent can act on cold.
- verify⚠ cold · adversarial
A fresh, skeptical pass. Sees only the brief and the diff, grades it, and waits on your existing CI checks. Disagreement triggers cold repair.
- commit
Stages the verified diff with a clean message.
- PR
Opens the pull request against your branch.
- CI
Hands off to your existing checks and watches them land.
- merge
Green and verified, it merges and picks the next ticket. Epic PRs stay human-merged.
Seven phases. One binary. No mercy at verify.
build · handoff · verify · commit · PR · CI · merge · fresh process per phase — no --continue, no --resume
⚠ the differentiator
Let a rival check your homework.
Cold verify. No mercy.
Most loops let the author grade their own work. Trau doesn't. Every phase runs in its own fresh, isolated agent — so verify is a cold, adversarial pass that sees nothing but the handoff brief and the code on disk. No shared reasoning. No shared blind spots.
Build agent
Writes the code. Knows every shortcut it took, every assumption it made, every corner it cut.
Verify agent
A fresh, skeptical process. Sees only the brief and the diff. Cold. It cannot inherit the build agent's blind spots.
When verify fails, the merge is blocked and a fresh repair agent gets spawned, then it re-verifies — bounded, then quarantine. The build agent knew every shortcut it took. The verifier doesn't, and doesn't trust the diff.
fail → merge blocked → cold repair → re-verify
⊙ execution model
Runs on the plan you already pay for.
Interactive, never headless. Trau drives the agent CLI you already use — not metered one-shot API calls.
Most autonomous loops shell out to agent -p: one-shot, headless, billed against a metered API key. The bill climbs with every phase, and the moment a run hits a prompt it can't answer, it stalls.
Trau drives the normal interactive CLI you already use — Claude Code, Codex, or Kimi — and handles the prompts and interruptions that would otherwise stall an unattended session. So the loop runs on the subscription you already pay for, subject to each CLI's own terms.
Headless
agent -p
One-shot, metered, blind to prompts. The bill climbs with every phase, and a single interactive prompt three phases deep stalls the whole run.
Trau
interactive CLI
Drives the interactive CLI you already use and handles the prompts that would stall it. No metered API key for Trau to hold — just your existing subscription, running unattended.
runs on your existing subscription · interactive, never headless
◇ routing & effort
A brain per phase. The effort to match.
Pick a provider, model, and reasoning effort for every phase — and dial the thinking up or down to fit the work.
Boilerplate doesn't need a deep thinker. The cold verify does. Each phase runs in its own fresh, isolated agent — so each one gets its own brain. Route the build to one provider, hand verify to another, and set the reasoning effort per phase: cheap for the scaffold, max for the gnarly verify that gates the merge.
- Route per phase — build, handoff, verify, commit, PR all addressable.
- Effort per phase — low for the easy furrow, high where the diff has to hold up.
- You draw the line. Trau plows it the same either way.
effort: low → max
- buildlow
- handoffmedium
- verifymax
- commitlow
- PRlow
effort tuning: Claude & Codex · Kimi effort = N/A
# trau.toml — a brain per phase, the effort to match[phase.build]provider = "claude" effort = "low" # scaffold, cheap[phase.verify]provider = "codex" effort = "max" # the diff has to hold up[phase.handoff]provider = "claude" effort = "medium"# one seam underneath — swapping a brain is a config change, not a rewrite
One seam, swap freely. Cheap effort for boilerplate. Max effort for the gnarly verify.
⟳ task detection
It reads the shape of your task.
Parent ticket or single ticket — Trau picks the right pass before it starts plowing. You don't configure it; Trau reads it.
Loop mode
- auth: hash + salt passwordsready-for-agent~40m
- auth: session cookiesready-for-agent~25m
- auth: rate-limit loginneeds-designskipped
- auth: logout endpointready-for-agent~15m
Runs each child tagged ready-for-agent in sequence, leaving the rest untouched.
Solo mode
No children to walk — Trau picks it up and runs it as a single unit, start to finish.
One task in, one task done. No orchestration overhead.
Tracked in human time, not wall-clock
Time reads in human terms, not machine seconds. The number you plan around is the work replaced, not the runtime spent — so a chore that took the agent 90 seconds might read as the ~2 hours of human work it stood in for.
illustrative example — not a measured speedup
machine
90s
human-like
~2h
▸ everything below ships in the binary
The whole loop, in the open.
A summary of what's confirmed in the tree today. Tap a card to dive into the section that covers it.
Cold, isolated phases
Every phase runs in its own fresh process. Verify never sees the build agent's reasoning — or its blind spots.
Self-heal
A failed verify spawns a fresh repair agent, then re-verifies. Bounded, then quarantine.
Crash-proof resume
Re-run the same command and it picks up mid-flight from a durable per-ticket checkpoint.
A brain per phase
Pick provider, model, and reasoning effort per phase. Claude is the exercised path; Codex and Kimi are wired.
Interactive, never headless
Drives the agent CLI you already use, not metered one-shot calls. Runs on the subscription you already pay for.
Bounded by design
Capped iterations and repairs, a per-agent timeout, and quarantine-on-failure. AFK, not unaccountable.
Cost in the open
Normalized per-phase token and cost accounting, summed every run. No black box to reconcile later.
Any tracker
Linear, Jira, or GitHub Issues. Tracker access is MCP-only — no tracker API keys for Trau to hold.
Epics handled
Parent tickets fan out onto a shared long-lived branch. The epic PR stays human-merged.
Waits on your CI
Won't merge until your existing CI checks (EXPECTED_CHECKS) come back green.
Branded TUI
A keyboard-driven Bubble Tea dashboard with a live phase-stepper.
Batteries included
brew install, guided onboarding, and a system readiness check. All in one static Go binary.
Apache-2.0 · one static binary · Claude · Codex · Kimi
⊞ any tracker
Any tracker. Same loop.
Linear, Jira, or GitHub Issues. Point Trau at the one your tickets already live in.
Trau reads your backlog through one typed seam, so the loop doesn't care where the tickets live. Pick your backend — Linear, Jira, or GitHub Issues — and Trau pulls the next ready ticket from there: same cold verify, same furrow.
Multi-project from the start. The onboarding wizard lists the teams, projects, and repos you can see and lets you pick — no hand-edited config to get going. Epics carry over too: parent tickets fan out onto a shared long-lived branch, and the epic PR stays human-merged.
Linear · Jira · GitHub Issues · multi-project · epic PR stays human-merged · (Linear can optionally use a personal API key)
⚠ is this safe?
is this safe?
Opt-in and explicit. You decide what it touches.
Nothing runs by accident. Real work is opt-in and explicit; --dry-run previews every phase and changes nothing on disk.
Trau runs on host machine-trust — point it at a checkout you control and let it graze. It's bounded, too: capped iterations and repairs, a per-agent timeout, and quarantine-on-failure mean a stuck ticket gets parked, not pushed.
◇ providers
Three brains. One seam.
Claude, Codex, Kimi — bring your own. Provider and model are a per-phase choice, not a global one. Same seam underneath, so swapping a brain is a config change, not a rewrite.
Status: Claude is the exercised path. Codex and Kimi are wired but not yet battle-tested — they get sharper with every run. Trau is a young project, and the copy says so.
status: Claude exercised · Codex / Kimi wired · bring your own — one seam, swap freely
$ get started
Build it. Point it. Walk away.
One command to install. One command to run. The onboarding wizard checks your machine, wires up your tracker and brain, then the buffalo takes the field.
One command, macOS or Linux. The whole loop ships in one static binary — no SaaS, no control plane, no vendor API key for Trau to hold.
trauin your repo opens a guided onboarding wizard. A readiness check probes your machine — git, gh, your agent CLI, and tracker access over MCP — and won't let you past until at least one brain and one ticket system come back ready.
Pick your tracker, label a ticket ready-for-agent, and let it graze. Preview the next ticket, run one, or turn the whole loop loose. AFK from here.
Still a young project: the Claude path is the most exercised; Codex and Kimi are wired.
◔ the horizon
More field past the fence.
The roadmap keeps running. Deliberately teased, nothing promised.
Shipped since the last site
- brew cask install
- guided onboarding + the readiness check
- three trackers (Linear / Jira / GitHub)
- auto-merge on green CI
- self-heal via bounded repairs
- per-phase token + cost accounting
- --dry-run
What we're turning toward next — exploratory, not committed, not yet built.
→ Cross-vendor verify panel
soonVerify as 2–3 fresh agents, optionally from different vendors, each grading the diff independently — disagreement blocks the merge under a configurable policy.
→ Budget ceilings
soonPer-ticket and per-day USD or token ceilings that halt and quarantine on breach.
→ Parallel tickets in local worktrees
soonDrain a whole herd at once, locally — no cloud rented.
→ Pluggable verify checks + rubrics
soonAuthor named checks in .trau/checks with severity gating; grade against per-ticket acceptance criteria and non-goals.
→ Execution sandbox + egress allowlist
soonBox agents in for overnight AFK runs.
the next furrow · exploratory · not committed · no dates, no pre-orders