→ self-hosted coding-agent hub

Your backlog, plowed.

Trau turns ideas into merged PRs and lands every run from one local hub.

One static Go binary. trau serve, open the hub, let it graze.

Get TrauSee the hub Star on GitHub

one binary, hub included · runs on your existing subscription · interactive, never headless · Apache-2.0 · trau.sh

127.0.0.1:8728
Get notified when a run pauses, faults, quarantines, or merges.Enable

OVERVIEW

What trau is doing, and what needs you

Start loop
1 running1 need you0 idleSPEND TODAY$3.18

LIVE LOOPS

loop
FLD-215build

fix flaky timezone test

ELAPSED7m 20sIN PHASE7m 19s

BuildVerifyShip

Build · build

WatchStop

NEEDS ATTENTION

needs-attention
pausedFLD-212harden the retry budget on upload
Paused · provider blipOpen run

RECENT RUNS

recent runs5
FLD-215fix flaky timezone testbuild
FLD-211debounce the map viewport writesmerged
FLD-209drop the unused geo polyfillmerged
PLW-95cache the station lookupmerged
FLD-208tighten the upload rubricmerged

⌂ the hub

One tab for the whole herd.

Every screen below is served by trau serve — from the same binary, on your machine, in either theme.

Operate

Observe

Configure

THEME
127.0.0.1:8728
Get notified when a run pauses, faults, quarantines, or merges.Enable

FIELDKIT-WEB

Inbox

Make unclear or new work ready to run — questions waiting on you come first.

New issueAsk ahead (3)
WAITING FOR YOU3
  • FLD-221conflict banner when a draft is stale
  • INT-4tidy the readme
  • PLW-99clarify the page-size cap on equipment
1 of 3FLD-221conflict banner when a draft is staleSkip
FLD-221needs-triage

conflict banner when a draft is stale

What's unclear

The epic asks for a banner when a stored draft is stale, but it never says what makes a draft stale — a newer server revision, a different device, or simply age.

Why it matters

The build agent has to pick a staleness rule to write the check against, and the wrong guess ships a banner that fires on every reload.

Direction

Settle the rule and the affordance before this is queued: what the banner says, and whether it offers to keep the local draft or take the server copy.

No interview yet — start one, or send a first message to open with it.

Start interviewAsk aheadSkip

Type your first message to start the interview…

Send

Operate

From half an idea to a ready ticket.

Drop a thought in the Inbox. The Interview asks one question at a time — recommending an answer and saying why — until the item becomes something the loop can run. Ask ahead queues your context early, Draftshold tickets that don't exist yet, Start over resets a session cleanly, and you can switch the interviewing agent's provider or model mid-conversation.

one question at a time · Draft → ready ticket · End interview / Discard draft

See it in the docsGet Trau

→ the engine

Build → Verify → Ship. Every phase cold.

Under the hub, each ticket runs through three steps — and every activity inside them starts a fresh, isolated agent.

No --continue. No --resume. Each activity 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.

trau — live run
→FLD-512— in progress
BUILD
build
lintfix
cleanup
handoff
VERIFY
verify
repair
bugfix
SHIP
commit
pr
ci-wait
merge
  1. Build

    Writes the code against the ticket, strips AI-slop, and distills what changed into a brief the next agent can act on cold.

    buildlintfixcleanuphandoff
  2. Verify⚠ cold

    A fresh, skeptical pass that sees only the brief and the diff. Failure spawns cold repair, then re-verifies — bounded, then quarantined.

    verifyrepairbugfix
  3. Ship

    Stages the verified diff, opens the PR, waits on your existing CI checks, and merges on green.

    commitprci-waitmerge

A ticket with sub-issues runs as an epic — children fan out onto a shared epic branch; a ticket without them runs solo. You don't configure it — Trau reads it.

Three steps. One binary. No mercy at verify.

See how verify worksRead the docs

Build · Verify · Ship · fresh process per activity — 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.

never meet

Verify agent

A fresh, skeptical process. Sees only the brief and the diff. Cold. It cannot inherit the build agent's blind spots.

Or convene a panel — across vendors

Turn one verifier into two or three. Each is a fresh, isolated agent grading the same diff independently — and you can pull them from different vendors, so no single model's blind spots decide the merge. Disagreement blocks it, under a policy you set. The most rigorous cold-verify pass in any AFK loop.

build → panel grades cold & independent → consensus, or no merge

When verify fails, the merge is blocked and a fresh repair agent gets spawned, then it re-verifies — bounded, then quarantined. The build agent knew every shortcut it took. The verifier doesn't, and doesn't trust the diff.

Every verdict and every rubric lands in the Run ledger — the receipts live in the hub.

fail → merge blocked → cold repair → re-verify → bounded, then quarantined

Read the verify docs

⊙ 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.

A brain per phase. The effort to match.

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. Pick the model and reasoning effort per phase — cheap for the scaffold, max for the gnarly verify — and put a cross-vendor panel on the phase that gates the merge.

  • Route per phase — build, handoff, verify, repair, bugfix, cleanup, lintfix, commit, pick: 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.ini
# .trau.ini — a brain per phase, the effort to match
 
CLAUDE_BUILD_MODEL=claude-sonnet-5     # scaffold, cheap
CLAUDE_BUILD_EFFORT=low
CLAUDE_VERIFY_MODEL=fable              # Fable 5 — the diff has to hold up
CLAUDE_VERIFY_EFFORT=max
CLAUDE_COMMIT_EFFORT=low               # mechanical
 
# cross-vendor second opinion on the phase that gates the merge
VERIFY_PANEL=claude,codex:gpt-5.6-sol
 
# 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.

Read the routing docsSee how verify works

runs on your existing subscription · interactive, never headless

→ everything below ships in the binary

The whole loop, in the open.

A summary of what's confirmed in the tree today — hub included. Tap a card to dive into the section that covers it.

The hub included

trau serve and a full local control center ship inside the same static binary. No extra install.

Cold, isolated phases

Every activity runs in its own fresh process. Verify never sees the build agent's reasoning — or its blind spots.

Cross-vendor verify panel

Optionally convene 2–3 fresh verifiers across vendors; consensus gates the merge.

Self-heal, blamelessly

Provider blips pause the run without blame; failed verifies spawn cold repair. Bounded, then quarantined.

Crash-proof, DB-backed

Runs checkpoint to a durable hub database. Resume mid-flight; history survives restarts.

A brain per phase

Provider, model, and reasoning effort per phase. Claude, Codex, Kimi.

Interactive, never headless

Drives the agent CLI you already use, on the subscription you already pay for.

Bounded by design

Capped iterations and repairs, per-agent timeout, spend caps in USD or tokens.

Cost in the open

Per-phase token and cost accounting, a costs page with anomaly flags, spend-today on the board.

Any tracker — or none

Linear, Jira, GitHub Issues, or Trau's internal issue store.

Epics & monorepos handled

Parent tickets fan out onto a shared epic branch; multi-app repos map each workspace with APP_URLS.

The terminal never left

The full Bubble Tea TUI still ships: same engine, same queue, trau in any repo.

Read the docsGet Trau

Apache-2.0 · one static binary · Claude · Codex · Kimi

→ any tracker

Any tracker. Or none.

Linear, Jira, GitHub Issues — or Trau's own internal issue store when a repo has no tracker at all.

LinearJiraGitHub IssuesInternal

No tracker on that repo? Trau keeps an internal issue store in the hub — author tickets there and run them like any other.

tracker access: MCP or direct API · Linear GraphQL · Jira REST

Trau reads your backlog through one typed seam, so the loop doesn't care where the tickets live. The hub keeps a local working copy of your issues — sync is one-way inbound, and Trau writes back statuses and comments only. Your tracker stays the source of truth.

Assignees come along read-only — filter the board by Me without giving Trau permission to reassign anyone. Epics carry over too: parent tickets fan out onto a shared epic branch that keeps syncing with main and auto-merges on green CI once its children land.

Wire up your trackerRead the tracker docs

Linear · Jira · GitHub Issues · internal issue store · your tracker stays the source of truth · read-only assignees

⚠ 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.

The hub binds to 127.0.0.1 and stays yours. Bind it anywhere else and Trau refuses to start without a bearer token (SERVE_TOKEN); registering repos over an exposed bind takes a second explicit flag. Want it on your laptop and your desktop? Tailscale is the blessed path — not a public port.

--dry-runpreviews everything, changes nothingdefault: host machine-trusthalts and quarantines on failure127.0.0.1 by defaulttoken-gated beyond loopbackTailscale, not a public port
See --dry-runRead the docs

◇ 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.

claude
exercised path
codex
wired · default model GPT-5.6 Sol
kimi
wired

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 serve. The onboarding wizard checks your machine, wires up your tracker and brain, then the buffalo takes the field.

# macOS / Linux
$brew install --cask RomkaLTU/trau/trau
$trau --version
$trau serve# the hub → http://127.0.0.1:8728
# from source (Go 1.25+)
$git clone https://github.com/RomkaLTU/trau && cd trau
$make build# -> bin/trau█
1Install

One command, macOS or Linux. The whole loop — hub included — ships in one static binary. No SaaS, no control plane, no vendor API key for Trau to hold.

2Serve

Run trau serve and open http://127.0.0.1:8728. The Add a project wizard takes a repo from a path to a live backlog: register, wire the tracker (or pick internal issues), and seed the board. trau doctor checks your machine any time. Prefer the terminal? Bare trau in a repo still opens the TUI wizard — and autostarts the hub for you.

3Run next

Queue a ticket — from the Backlog, the Inbox, or a label in your tracker — and press Run next. The loop drains the queue top to bottom and pings you only if something needs a human. AFK from here.

Read the docs Star on GitHub

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.

What v2 shipped

  • the hub — Overview · Loop · Inbox · Runs (trau serve)
  • hub SQLite database — durable run history
  • All projects scope
  • Inbox Interviews (idea → ready ticket)
  • one Queue + Run next
  • Run ledger
  • epic-aware Backlog + Archive
  • assignee filters (Me)
  • Atlas architecture views
  • notification center + away recap
  • light mode
  • internal issue store — no tracker required
  • monorepo APP_URLS
  • web onboarding wizard
  • repo config beats home config

What we're turning toward next — exploratory, not committed, not yet built.

→ Parallel tickets in local worktrees

not yet built

Drain a whole herd at once, locally — no cloud rented.

→ Verify split: evidence vs. grade

not yet built

One agent gathers the evidence, an independent grader reads it cold and writes the verdict — so repair targets findings, not a hunch.

→ Windows support

not yet built

The binary already cross-compiles; the interactive PTY runner is the blocker. ConPTY is the trailhead.

→ Durable agent memory across runs

not yet built

Lessons that carry from one run to the next, beyond the current lessons store.

Read the changelogOpen an issue

the next furrow · exploratory · not committed · no dates, no pre-orders