v0.0.6
brindle 0.0.6, free to use, source-available (Brindle License 1.0)

A team of coding agents, each on its own branch.

brindle runs Claude Code, Codex, Google Antigravity and open-weight models side by side in tmux. Every agent works in its own git worktree, a supervisor agent splits up the work and hands it out, and with autopilot on, a worker's branch merges only after a reviewer agent approves it and your checks pass. Nothing counts as done until a command says so.

$curl -fsSL pawdelta.com/brindle/install | sh
GitHub Read the docs

macOS or Linux, with tmux, git and Claude Code (or Codex or Antigravity for the supervisor, with --provider); a local model can run workers and reviewers. Or pipx install brindle.

brindle — myapp
  brindle
──────────────────────
1 needs you · 1 working
3 agents in 3 workspaces

main  (your checkout)
  ○ Supervisor         
    idle for 1m

feat/csv-export
  3 ahead main
  ● Developer
    working for 4m

feat/settings
  ◆ Developer
    needs you for 40s

↑↓ ⏎ open  x close  ? keys
> Add CSV export to reports and a
  settings page, with tests.

● I'll split this into two parallel tasks,
  each on its own branch:

  feat/csv-export  CSV export + tests
  feat/settings    settings page + tests

  Both workers are running. I'll review
  each branch when it reports back.

See it run

brindle demo on a practice repo: the supervisor splits a goal between two workers, each branch is reviewed and merged, and both milestones turn green once their checks pass.

brindle demo — recorded on 0.0.2, sped up 4×
brindle demo: a supervisor splits a goal between two workers, each branch is reviewed and merged, and both milestones turn green once their checks pass

How it works

Run brindle

In any repo, brindle opens a supervisor chat with a live dashboard of every agent alongside. Tell it what you want built, or write the goal in .brindle/goals.md.

Workers fan out

The supervisor assigns each task to a worker, on the model that fits its size. Each worker gets a fresh worktree on its own branch, so nobody edits the same files.

Review, then merge

Workers commit and report back. A reviewer agent checks each branch, brindle runs your tests and hooks, and with autopilot on only approved branches merge. brindle never merges into your default branch on its own: an approved branch based on it goes back to the supervisor, and only an explicit merge_workspace merges it.

What you get

Autopilot with verified milestones

Give it a goal and it works like a project manager: milestones, each with a check command brindle runs itself. It keeps going until every check passes or it needs a decision from you. More

Reviewed before it merges

With autopilot on, a branch merges only when it's committed, a reviewer has approved that exact commit, and your pre-commit hooks and checks pass (set "review": true to require the approval without autopilot). brindle runs the review-and-merge pipeline itself, and leaves merges into your default branch to an explicit merge_workspace.

Any model, mixed freely

Claude Code, Codex, Antigravity, or brindle's own agent loop over an open-weight model on Ollama, LM Studio or a hosted API. A Codex reviewer gives Claude's work a second model's opinion.

Routed by weight

The supervisor sizes each task as light, medium or heavy, and brindle picks a profile for it: a stronger one for hard problems, skipping any provider that's near its limit or isn't signed in.

Knows its limits

brindle reads Claude's and Codex's usage against their subscription limits, and benches Antigravity for a cooldown once it hits its limit. When your Claude usage nears its limit, autopilot pauses its Claude workers and resumes them on its own when the window resets.

Parallel, without collisions

Every workspace is a separate git worktree on its own branch, with its own block of ports for dev servers. Workers branch from the supervisor's committed work; brindle new cuts from a freshly fetched base.

Knows when an agent needs you

Agents report their status through lifecycle hooks; brindle reads the screen only for what no hook reports, such as approval prompts and trust dialogs. A ◆ marks only what needs you, and a worker stuck on a prompt for 90 seconds is reported to its supervisor.

A sidebar you can steer

? lists the keys, n jumps to the next agent that needs you, ⏎ opens it and p peeks. It follows you between brindle windows; brindle sidebar brings it back if it's left behind. Put it at the bottom, hide it with h, and drag in the chat to copy text.

See what each task costs

Token usage per Claude Code and local-model agent shows in the sidebar and in every worker's report. brindle history keeps a log of results, reviews, merges and milestone checks.

Pick up where you left off

Close the chat and the whole session pauses: workers stop, and branches, worktrees and conversations are kept. brindle continue brings it all back; plain brindle starts fresh. Run brindle where a session is running and it asks: open it, start a second session in its own worktree (both run at once), or pause it and start fresh.

Cleans up after itself

Finished workers close on their own, merged worktrees are cleared away with their merged branches, a local model server brindle started is stopped with the session, and brindle prune sweeps anything left. Unmerged branches are always kept.

Per-repo setup

.brindle/config.json runs setup and teardown scripts, copies local files such as .env into every new workspace, and can give agents directories outside the worktree.

Free, with optional paid plans

Everything above is in the free brindle, source-available (Brindle License 1.0): every provider, autopilot, the review pipeline, and no plan limit on agents (max_agents runs 4 workers at once by default; raise it, or set 0 for no cap). It runs on your machine with no account. The paid plans add isolated services per worktree, sessions that span several repos, brindle in CI, team policy and audit, and an air-gapped enterprise edition.

Developer CoreFreeEverything above, source-available Power-Dev Pro$15 / moPer-worktree services, hosted learning, several repos in one session DevOps Automation$25 / seatbrindle CI, org policy, audit feed EnterpriseCustomAir-gap mode, signed audit trail

Install

curl -fsSL pawdelta.com/brindle/install | sh

The script installs uv if it's missing and, on macOS with Homebrew, tmux (elsewhere it prints the command to install tmux), then brindle, then runs brindle doctor. Run it again to upgrade. Or by hand:

brew install tmux # or your package manager uv tool install brindle # or: pipx install brindle brindle doctor # checks tmux, the agent CLIs, models, config

brindle doctor checks that everything brindle needs is there (tmux, the agent CLIs, native profiles' model endpoints, add_dirs, a writable home) and, in a repo, its config, checks and code map, and says what to do about anything missing.

brindle --version prints the installed version, and the tmux status bar of every brindle session shows it too (brindle 0.0.6). A session started before an upgrade keeps running the old code, and shows the old number, until you restart it.

Quick start

# see the whole loop on a practice repo first (a few minutes) brindle demo # then in your repo: detect setup and test commands, once cd ~/code/myapp brindle init # open a supervisor chat, with the dashboard alongside brindle # or drive one workspace yourself brindle new fix-login -p "Fix the login redirect bug and add a test" brindle ls # workspaces, agents, ahead/behind brindle diff fix-login --stat brindle pr fix-login # push and open a pull request brindle rm fix-login # deletes the branch once merged brindle history # what ran, what merged, what it cost

Not in a git repo? brindle still works: it starts a scratch session under ~/.brindle/scratch/, and brindle transfer ~/path/to/repo moves the work onto a new branch in a real repository when it's ready.

Recommended use

brindle pays off when work splits into pieces that can run in parallel, or runs long enough that you want it reviewed and merged without babysitting. For a one-line fix, plain claude is quicker; the supervisor also does small things itself instead of starting workers.

Start on a clean base

Commit or stash first. Workers branch from the supervisor's committed work, not your uncommitted edits. To keep main free while brindle works, run it on another branch with brindle start -b BRANCH.

Give it a goal with checks

Say what “done” means as commands (a test file, npm test, a build), or write .brindle/goals.md. Milestones with real checks let autopilot keep going without you and stop when the work is actually done.

Set checks and setup

In .brindle/config.json: your full test suite as checks, so no branch merges red, and a setup if a new worktree needs npm install or similar.

Watch the sidebar, not every window

It flags agents waiting on you with ◆. n jumps to the next one, ⏎ opens it, p peeks, ? lists every key. Workers that need a decision surface through the supervisor's need_user.

Step away freely

Quit the chat to pause everything; brindle continue resumes the session, workers included. brindle history shows what ran, what merged and what it cost.

Clean up

Finished workers close on their own after stale_after minutes, and brindle sweeps leftover processes at start. brindle close --exited and brindle prune do it on demand. A removed worktree's branch goes too once it's fully merged; unmerged branches are always kept.

For a large task

Write the milestones first, each with a check. Keep each worker's task to one area of the code with its own test command, and let the supervisor run up to max_agents workers at once. Give a milestone a cheaper profile for mechanical edits, and make reviewer-codex the reviewer for a second model's opinion. Turn on plan_first when you want to see each worker's plan before it edits anything.

Autopilot

brindle starts the supervisor with autopilot on. Tell it what you're building, or put the goal in .brindle/goals.md, and it works like a project manager: milestones, workers, reviews and merges, until every check passes.

Goals and milestones

The goal is split into milestones, and each has a check command that brindle runs itself. A milestone is done only when its check exits 0, so progress is verified, not just claimed. A milestone may name a profile, the worker profile for its tasks, so a small milestone can run on a cheaper one. The sidebar shows the goal and each milestone (✓ verified, ✗ failing, ○ not checked yet).

<!-- .brindle/goals.md --> # Settings page ## Settings API check: uv run pytest tests/test_settings_api.py -q ## Settings UI check: npm test -- settings profile: developer-local

goals.md stays in sync

A session that loaded its goal from goals.md writes each milestone's status back to that file after every check, as one line under the milestone, for example status: passed at abc1234 (2026-09-29). The rest of the file is left exactly as you wrote it, and since goals.md may be committed, no session data ever goes in. A status line is information only: a new session starts every milestone as pending and re-runs the checks. A session stops writing when it's handed over, paused, or has autopilot off.

Workers in parallel

The supervisor splits each milestone into tasks and starts workers on their own branches, up to max_agents at once. Claude workers run the task as a Claude Code /goal with a finish line, so they keep going until it's met. A task can declare the files it expects to touch (checked for overlap with other running workers) and depends_on earlier tasks: it waits in a queue and starts on its own, from the updated base, once those merge. list_tasks shows what's queued.

Plan-first workers

With plan_first (per task, or as a repo default), a worker reads the code, proposes a short plan with submit_plan, and waits. The supervisor approves it with approve_plan, or sends it back with feedback. Claude workers can't edit files until the plan is approved; other CLIs are told to wait.

The review-and-merge pipeline

When a worker reports, brindle starts a reviewer at once and runs your checks in the background. Findings go straight back to the worker to fix (up to review_rounds times). When the reviewer approves that exact commit and the checks pass, brindle merges the branch, removes the worktree, and sends the supervisor one message with the report and the review. Anything it can't settle (a conflict, a failing check) arrives as “needs you”. Check runs share the machine: at most check_concurrency run at once across all branches (2 by default), the rest wait their turn, and a run that goes far past its last duration is reported to the supervisor.

It never merges into your default branch on its own. When a reviewed branch's base is main (or whatever the default is), the supervisor gets a “needs you” message and merge_workspace merges it. Set merge_into to an integration branch to have workers branch from and merge into it instead, or auto_merge_default_branch: true for fully automatic merges.

The reviewer is your review_profile if set, else the repo's reviewer (the built-in reviewer by default). brindle never switches to a different model on its own: set reviewer or review_profile to reviewer-codex or reviewer-local for a second model's view. With hosted learning on, brindle may pick one of those instead when it can run here and has reviewed this kind of work better.

It keeps going, and knows when to stop

If the supervisor stops while milestones are unverified and no worker is running, brindle tells it to continue. It stops when every check passes, when it needs a decision from you, or after three reminders with no progress.

Passing checks aren't the finish line yet. A check can pass while the milestone isn't done: the test asserts too little, or checks the wrong thing. So once every milestone passes, a read-only reviewer audits the work since the goal was set against the goal and each milestone, looking for anything missing, stubbed or weakly tested. Only its approval of that commit finishes the goal; if it finds gaps, the supervisor gets them and keeps working until a fresh audit approves. "goal_audit": false turns it off.

Pausing for usage limits

When your Claude usage reaches usage_limit (90% by default), autopilot pauses: its running Claude workers stop, with worktrees, branches, queued messages and sessions kept, and the sidebar says “paused for usage until <time>”. When the usage window resets, brindle restarts those workers on its own and tells the supervisor what it resumed. To see your usage, brindle gives the Claude Code agents it launches a status line that records it (Claude.ai plans report it; API-key use doesn't), then prints whatever your own status line prints.

Quieter messages

Messages from workers and the pipeline don't interrupt the supervisor one by one. It gets a single notice (“brindle (16:25:03): 2 new messages ... Call read_messages.”) and reads them with read_messages when it's ready; the sidebar shows the unread count. If a notice goes unread, the next message or the end of the supervisor's turn sends a fresh one, at most once every two minutes. "message_delivery": "push" restores the old behaviour; messages you send skip the notice: they reach the agent as written, as soon as it's idle.

Handing over to another branch

brindle start -b BRANCH (or -w PATH) runs the supervisor in that branch's worktree, creating it if needed; a linked worktree finds the repo's .brindle config through the main checkout. brindle handover --to BRANCH (or the supervisor's handover tool) moves the goal, milestones, workers, queued tasks and a note to a new supervisor there, and pauses the old one.

Controlling it

brindle autopilot shows progress, brindle autopilot check runs the checks now, and brindle autopilot off (or on) hands the wheel back or takes it again. brindle --no-autopilot, or "autopilot": false in the repo config, starts without it.

Cost and history

Each Claude Code and local-model agent's token usage is read from its own transcript (Codex and Antigravity don't report one) and shows in the sidebar, in brindle ls, in each worker's report, and per row in brindle history, a durable log of results, reviews, merges and milestone checks that survives brindle prune. To spend fewer tokens, workers run only the tests for their change, the full suite runs once before merge and is cached by commit, and the supervisor makes small changes itself.

Providers and models

brindle runs whichever agent CLIs you have, signed in your own way, and its own loop over open-weight models. Mix them: a profile names its provider, and the supervisor hands each task to the one that fits.

Claude Code

The default for the supervisor and workers. brindle launches your installed claude with its own hooks for status and messages, marks each worktree as trusted, and approves a compound command such as cd src && pytest -q when every part matches the profile's allowed_tools, so workers don't stall on prompts. A profile's env.NAME: value lines can point Claude Code at another Anthropic-compatible backend.

Codex

Give a profile provider: codex, or run the supervisor on it with brindle --provider codex (workers still use their own profiles' providers). brindle reads a Codex agent's status from Codex's notify hook, passed at launch with -c, so it adds nothing to your Codex config (brindle does accept Codex's trust prompt for each new worktree, which Codex records in ~/.codex/config.toml, and with "permission_policy": "on" trusts its own permission hook there once). Codex has no Stop hook, so for an autopilot supervisor on Codex, the end of a turn is where brindle tells it to keep going. The built-in reviewer-codex profile reviews Claude's work with a different model: make it the repo's reviewer or review_profile.

Google Antigravity

brindle runs Antigravity's terminal agent, agy. Install it and sign in once, then use brindle --provider antigravity or give a profile provider: antigravity (for example a Gemini reviewer).

curl -fsSL https://antigravity.google/cli/install.sh | bash agy # sign in with your Google account, then quit

agy takes no command-line options for hooks or MCP servers, so brindle adds its files to the checkout's .agents/ folder and lists them in .git/info/exclude. Hooks can't approve shell commands in agy, so add allow rules to ~/.gemini/antigravity-cli/settings.json for the commands agents should run without asking.

Open-weight models (native provider)

provider: native runs brindle's own agent loop instead of a third-party CLI: it talks to any OpenAI-compatible chat-completions or Anthropic Messages endpoint, runs the worker's tools (Read, Write, Edit, Glob, Grep, Bash) inside its worktree, and reports status directly. The built-in developer-local and reviewer-local profiles run Qwen3-Coder 30B on Ollama.

brew install ollama ollama pull qwen3-coder:30b brindle doctor # "model qwen3-coder:30b ... is available"

brindle can start the model for you. A 30B model holds about 20 GB of GPU memory, so by default brindle uses an Ollama server that's already running and never starts or preloads one. Set "local_models": true and, when brindle or brindle continue opens and a native profile points at Ollama on this machine that isn't answering, brindle starts ollama serve with the context length the profiles need and preloads their models. It stops that server again when the last session using it ends. A server you started yourself is left alone.

Endpoints for the native provider
Ollamaapi: openai, http://localhost:11434/v1; free
LM Studioapi: openai, http://localhost:1234/v1; free
llama.cppapi: openai, http://127.0.0.1:8080/v1; start with --jinja
OpenRouterapi: openai, https://openrouter.ai/api/v1; api_key_env: OPENROUTER_API_KEY
Z.ai GLMapi: anthropic, https://api.z.ai/api/anthropic; api_key_env: ZAI_API_KEY
DeepSeekapi: anthropic, https://api.deepseek.com/anthropic; api_key_env: DEEPSEEK_API_KEY
Anthropicapi: anthropic, https://api.anthropic.com; api_key_env: ANTHROPIC_API_KEY

A 30B-class local model does well on small, well-specified tasks and reviews of modest diffs, and less well on long multi-step work. Native workers are headless: brindle agent peek shows each turn, and brindle send talks to them.

Which provider can do what

Supervisor and worker roles by provider
Claude CodeSupervisor (the default) and workers
CodexSupervisor (brindle --provider codex) and workers
AntigravitySupervisor (brindle --provider antigravity) and workers
nativeWorkers and reviewers only: its loop has the worker tools, not assign or handoff
subagentWorkers only, through assign/handoff: it runs inside the supervisor's own Agent tool

Only signed-in CLIs are offered. A profile whose CLI isn't installed or isn't signed in is left out of the supervisor's profile list and of routing by weight, and learning never picks it as a reviewer. Naming one directly, including as the repo's reviewer, stops with how to sign in (claude auth login, codex login, running agy) instead of opening the CLI's login screen, and brindle doctor shows each CLI's sign-in. A key in the environment (ANTHROPIC_API_KEY, OPENAI_API_KEY, ...) counts as signed in; agy uses GEMINI_API_KEY only with "modelProvider": "gemini" in its settings (brindle counts the key as signed in either way, so set both), otherwise run it once yourself to sign in with your Google account. A Codex worker that shows nothing new for 10 minutes without reporting, say because the account's plan doesn't include Codex, is reported to its supervisor.

Routing by weight

The supervisor sizes a task and passes weight (light, medium or heavy) to assign or handoff, and brindle picks an available profile for that tier. Light is small, mechanical work (docs, renames, simple tests); medium is a normal feature or bugfix; heavy is design-heavy, cross-cutting work or subtle bugs. The routing key lists each tier's profiles: the first is the tier's baseline, the rest are candidates hosted learning may pick instead. The defaults, which you can override tier by tier:

{ "routing": { "light": ["developer", "developer-codex", "developer-local"], "medium": ["developer", "developer-codex", "developer-heavy"], "heavy": ["developer-heavy", "developer", "developer-codex"] } }

developer-local runs on your local model, developer-codex on Codex, and developer-heavy on Claude (Fable) at high effort. No tier prefers another provider for its own sake. A profile is skipped when its CLI isn't installed or signed in, the local model isn't answering, or its provider is at your usage_limit. With hosted learning on, it chooses among the profiles left; otherwise the first one wins, and when every candidate is out, learning may pick from your learning_candidates, else the repo's default_agent runs. The reply says what was picked and why, e.g. weight medium -> developer (Codex at 93%, skipped developer-codex). A profile you name, or a milestone's profile, always wins.

Provider quota

brindle keeps track of how close each provider is to its subscription limit and shows a note per provider (e.g. Codex at 82% of its weekly limit, resets Thu 9:00am) in assign replies, get_progress, the sidebar (all but the local model) and brindle doctor. It uses only what the CLIs write locally; it never reads login tokens or calls a provider's servers.

  • Claude: the status line data Claude Code gives brindle.
  • Codex: the latest rate-limit event in its local session logs (5-hour, weekly and monthly windows).
  • Antigravity: no numbers; after a limit error it counts as unavailable for limit_cooldown_minutes.
  • Native: full headroom while the local model server answers, none while it doesn't.

Hosted learning

With a brindle Pro plan, brindle learns which profile suits which kind of task, and picks one when neither you nor a milestone names one: among the available profiles for the task's weight, or among your learning_candidates (the reply says why). Offline, or without the plan, routing works as above. A profile you name always wins. Learning is per person on Pro and per organization on Team, runs only on PawDelta's servers, and gets only coarse records (task kind and size, weight, profile names and relative cost, outcomes, with the repo and agent as keyed hashes), never task text, file paths, branch names, provider or model. "learning": "auto" (the default) uses it when your plan includes it; "cloud" selects it explicitly (it still needs the plan); "off" turns it off. brindle learning says whether it's on for this repo, and if not, why.

What it gained. brindle account savings shows what learning's picks did in this repo, this month, last month and all time: how many tasks it picked against the baseline, review rounds per task and failed or escalated tasks for each, and an estimate of the relative cost difference (not money; shown once at least 5 of learning's picks have finished). It reads only this machine's records and is labelled as an estimate. Org admins see org-wide totals on the account page.

Learning across your company. If your company runs several orgs, someone who owns them can link them into one company with brindle account org company link <org_id> (and take one out with unlink). Each org's owner or admin then decides whether to pool its learning with the company's other orgs: brindle account org learning-share on. It's off by default, it never pools with another company, and an org in no company pools with no one. The pool gives a starting point; each org's own results still count most. Turning it off stops new contributions.

Configuration

Per-repo settings live in .brindle/config.json (brindle init writes one with your setup and test commands filled in). .brindle/config.local.json is git-ignored and overrides keys for you only; for a command list it can also give {"before": [...], "after": [...]} to wrap the team's commands. ~/.brindle/config.json holds your own defaults for every repo, and both repo files override it (command lists, plugins, routing, services and airgap come from the repo only). A linked worktree finds the config through the main checkout.

{ "setup": ["pnpm install", "cp \"$BRINDLE_ROOT_PATH/.env.local\" ."], "teardown": ["docker compose down"], "copy": [".env", "apps/*/.env"], "base_branch": "main", "default_agent": "developer", "checks": ["uv run pytest -q"], "max_agents": 4, "merge_into": "develop", "sidebar": "bottom" }
Workspaces
setup / teardownCommands run when a workspace is created or removed.
copyLocal files (globs) copied into each new workspace, such as .env.
base_branch / branch_prefixThe branch workspaces are cut from, and a prefix for new branch names.
fetchFetch the base before cutting a branch (default on).
default_agentThe worker profile when nothing else picks one.
pool_sizePre-built worktrees kept ready so a new worker doesn't wait on setup (default 1 when there is a setup, else 0; 0 turns it off).
add_dirsDirectories outside the worktree that Claude Code agents may use (--add-dir; full tool access, not read-only). Relative paths resolve against the repo root, ~ is your home, and a missing directory is reported.
Autopilot, review and merge
autopilotStart the supervisor with autopilot on (default true).
checksCommands that must pass in a branch before it merges.
check_timeoutSeconds each check may take (default 900).
check_concurrencyCheck runs at once on this machine, across branches (default 2; 0 means no cap). The rest wait their turn, and a run far past its last duration is reported to the supervisor.
review / reviewer / review_profileRequire a reviewer's approval (unset: only under autopilot); the reviewer profile (default reviewer); force request_review's profile.
pre_commitRun pre-commit over the branch, if the repo uses it (default on).
pipeline / review_roundsbrindle reviews and merges reported branches itself; fix-and-re-review rounds before findings reach the supervisor (default 2).
goal_auditOnce every milestone passes, a read-only reviewer checks the work against the original goal before it counts as reached (default true).
merge_intoThe branch the supervisor's workers are cut from and merge into, whatever branch the supervisor is on (a worker's own workers still use its branch).
auto_merge_default_branchLet the pipeline merge into the default branch on its own (default false: the approved branch goes to the supervisor to merge).
max_agentsWorkers running at once per session (default 4; 0 means no cap).
overlap"block" (default) refuses a task whose files overlap a running one; "warn" starts it anyway.
plan_firstWorkers propose a plan and wait for approval before editing (default false).
stale_afterMinutes before a worker that reported and sat idle is closed (default 30; 0: never).
Models, limits and messages
routingFor each weight (light, medium, heavy), the profiles to try in order. See Routing by weight.
usage_limitAt this % of a provider's usage limit (default 90) routing skips that provider's profiles; at this % of your Claude limit autopilot pauses.
limit_cooldown_minutesHow long a provider that hit its limit counts as unavailable (default 300).
local_modelstrue: start a local Ollama server for native profiles when needed, and load their models. Default false: brindle uses a server that's already running.
message_delivery"pull" (default): one notice, read with read_messages; "push": each message delivered as it arrives.
permission_policy"on": brindle answers workers' permission prompts from its rules. Default "off": prompts behave as they always did. See Permission policy.
learning / learning_candidates"auto" (default), "cloud" or "off" for hosted learning, and the profiles it may pick from.
pluginsWhich installed plugin to use per group (events, policy, account), or "off", e.g. {"policy": "<name>", "events": "off"}. Unset, a group uses its only installed plugin, and every installed events plugin hears every event. A policy plugin named here that can't load refuses delegations and merges rather than allowing them.
graphifyPoint agents at the repo's graphify code map, if there is one (false turns it off).
servicesPower-Dev Pro: containers each worktree gets its own copy of, e.g. [{"name": "db", "preset": "postgres"}] (presets postgres, redis, mongo, or your own image and port). Each gets a port from the worktree's block, and its connection settings are added to the workspace's environment.
airgapEnterprise Sovereign: true turns on air-gap mode: no requests to PawDelta, and only profiles whose model is on this machine or your private network may run. .brindle/config.json, config.local.json or BRINDLE_AIRGAP=1 can turn it on, and neither file can turn it off (~/.brindle/config.json doesn't count).
sidebar"left" (default) or "bottom": where the dashboard sits in each window.
delegation"balanced" (default): how readily the supervisor hands work to workers. "conservative" does most work in its own chat (fewest tokens); "fast" splits work across parallel workers straight away (quickest). brindle delegation fast saves it for every repo in ~/.brindle/config.json, and Pro plans sync it across your machines.
delete_merged_branchestrue (default): removing a worktree also deletes its branch once every commit is in its base; an unmerged branch is kept unless you delete it yourself with force.
pr_footertrue (default): brindle pr ends the PR description with one "built with brindle" line; false leaves it out.
rulesStanding rules for the supervisor, added to every supervisor's brief, e.g. ["Fix review findings without asking"]. Rules in ~/.brindle/config.json, the repo's config and config.local.json all add up.

Setup, teardown and agents see BRINDLE_ROOT_PATH, BRINDLE_WORKSPACE_PATH, BRINDLE_WORKSPACE_NAME, BRINDLE_WORKSPACE_ID, BRINDLE_BRANCH, BRINDLE_BASE_BRANCH and BRINDLE_PORT_BASE. Each workspace gets ten ports from BRINDLE_PORT_BASE, so parallel dev servers don't collide.

Permission policy

Workers stop at their CLI's permission prompts like any other session. With "permission_policy": "on" (in the repo's config or ~/.brindle/config.json), brindle answers those prompts from rules instead. It reads the structured request the CLI hands its hook (the tool and its command, path or URL), never the screen, and answers allow, deny, or ask, which leaves the prompt to you as usual.

Starting rules. Allow reading files git tracks in the worktree or the repo root, your checks commands, and plain git status, diff, log and show, but only as a single simple command with no shell metacharacters. Deny git push, force flags, and reading ~/.ssh, ~/.aws, ~/.gnupg and .env*. Everything else is asked. A deny beats any allow.

Your rules. brindle permissions allow and deny add rules to ~/.brindle/permissions.json; a repo's .brindle/permissions.json can only add denies, and a profile can add its own with permission_denies. brindle never learns a rule on its own: once you've approved the same request twice in a Claude Code worker, brindle permissions suggestions lists it and accept makes it a rule. Claude Code and Codex decisions (and Antigravity denies) are in brindle history --kind permission, and when a Claude Code worker sits on a prompt, its supervisor is told which request is pending.

Codex and Antigravity. Codex runs the same hook once it's trusted: brindle trusts it the first time a Codex worker needs it (brindle permissions install-codex-hook --yes does it by hand). Antigravity's hook can deny but ignores an allow, so brindle copies the rules it can express into Antigravity's own settings, touching only its own entries (brindle permissions sync-agy).

Team policy

With brindle Team, an org admin sets a policy that every member's brindle enforces on delegations and merges: which providers, models and agent profiles (allowed_profiles) workers may use, a cap on parallel workers, and whether a person must approve each merge. A delegation to a profile outside the list is refused, even one hosted learning picked. Each role (owner, admin, member) can get its own overrides, and on Enterprise an admin can give a member a custom policy role with brindle account org member policy-role <member> <role|none>. brindle account org policy shows the org's policy, each role's overrides, and the policy that applies to you. A refused delegation or merge says why, and if brindle can't get the policy at all, it refuses work rather than running unchecked.

Agent profiles

Markdown files with frontmatter. brindle looks in .brindle/agents/, then ~/.brindle/agents/, then its built-ins (supervisor, developer, reviewer, reviewer-codex, developer-local, reviewer-local, subagent, and the routing profiles developer-codex and developer-heavy). brindle agent profiles lists them.

--- name: frontend description: React/TypeScript specialist provider: claude # claude | codex | antigravity | native | shell | subagent model: sonnet permission_mode: acceptEdits allowed_tools: Bash(npm test:*), Bash(git commit:*) add_dirs: /srv/extra --- You are a frontend engineer...

The built-in developer runs in Claude Code's auto mode with an allowed_tools list for git and common test and build commands. git push isn't on that list, so a push is left to auto mode's judgment or a prompt (with the permission policy on, brindle denies it). The built-in reviewer refuses anything outside its list rather than waiting for an answer.

Cheap workers

Claude Code profiles can trim what a worker loads on every turn: strict_mcp: true (only brindle's MCP server), setting_sources: project,local (skip your user plugins and ~/.claude/CLAUDE.md), effort: low, and headless: true (each turn is a claude -p run; nothing can answer a prompt, so anything not allowed is refused).

Subagent workers

The built-in subagent profile gives a Claude Code supervisor brindle's worktree and branch handling for work done by its own Agent tool, with no separate process. The supervisor gets a worktree and a ready-made prompt, and records the outcome with complete_subagent.

Command reference

Commands with an optional workspace argument act on the workspace you're in when you leave it out. Every command takes --help.

Sessions
brindleA fresh supervisor chat here, with the sidebar. If a session is already running here, you choose: open it, start the new one in its own worktree, or pause it. Outside a repo, a scratch session. --provider codex|antigravity runs the supervisor on another CLI (native and subagent can't supervise).
brindle --versionThe installed version.
brindle delegation [LEVEL]How readily the supervisor delegates: conservative, balanced (default) or fast. --repo for this repo only.
brindle continue [ID]Resume a paused session, workers included (brindle -c for the latest).
brindle start [-a PROFILE] [-p PROMPT] [-b BRANCH] [-w PATH]Like brindle, with options: another profile, a first prompt, --no-autopilot, --no-watch; -b/-w run it in that branch's worktree, created if needed.
brindle handover --to BRANCH|PATH [-n NOTE]Hand the session to a new supervisor there: goal, milestones, workers, queued tasks and your note move across; the old one pauses.
brindle sessionsPaused sessions in this repo and the disk they use.
brindle autopilot [on|off|check]The goal's progress; hand the wheel back or take it again; run the checks now.
brindle transfer [REPO]Move a scratch session's work onto a branch in a real repo (--from a session, -b BRANCH).
brindle initDetect setup and test commands from your lockfiles, write .brindle/config.json, check the tools (-y writes without asking). An existing config is left alone.
brindle demoWatch brindle finish a tiny practice repo: parallel workers, reviews, gated merges, verified milestones. --local runs it on Ollama.
brindle doctorCheck tmux, the agent CLIs, model endpoints, add_dirs, the clipboard tool and the repo's config, and say what to fix.
Seeing what's going on
brindle watchThe dashboard on its own, the same view as the sidebar (--all for every repo, --once for one snapshot).
brindle sidebarBring this session's sidebar into the tmux session you're in, or restart it if it was closed (Ctrl-b S does the same in a window without one).
brindle lsWorkspaces and agents, with ahead/behind and tokens (--all for every repo, --json).
brindle historyWorker results, reviews, merges and milestone checks, with token cost (--limit N, --kind, --all). --share sums up a session in a few lines to paste into Slack or a post.
brindle account […]Paid plans. On its own: which paid features your plan includes and how to get the rest. Also login (approve in your browser; --device shows a code to enter elsewhere, e.g. over SSH), status, sync (your settings across machines), savings (what hosted learning's picks gained in this repo; estimates from this machine's records), upgrade (--team --seats N for a Team org), portal, org list|create|invite|join|use, org policy (the org's policy, its role overrides and yours), org member policy-role MEMBER ROLE|none (Enterprise), org company [link ORG|unlink], org learning-share [on|off], org ci-token create|list|revoke, license install|status|remove (offline enterprise license), logout.
brindle learningWhether hosted learning is on for this repo, and if not, why. Nothing is learned on your machine.
brindle permissions […]The rules brindle answers workers' permission prompts with (see Permission policy): list, check (the effective rules per provider, changing nothing), suggestions, accept ID, allow / deny KIND MATCH, forget ID, reset, install-codex-hook, sync-agy.
brindle services [ls|up|down] [workspace]Power-Dev Pro: the worktree's own service containers (from services in the config): list, start, or stop and remove them.
brindle repo add PATH [--name ALIAS] / rm ALIAS / lsPower-Dev Pro: attach another local repo you own to the current session, so the supervisor can put workers there (each gets a worktree in that repo, with its checks, review and merge); detach it (its worktrees and branches stay); list what's attached.
brindle ci init|start|run|report|doctorbrindle Team: CI on your own GitHub Actions with your own model keys. init sets a repository up (the brindle GitHub App, the BRINDLE_PRO_TOKEN and model-key secrets, and the workflows, as a pull request); start, run and report are what those workflows call to fix a broken build, turn an issue into a verified pull request, or validate a pull request with evidence; doctor shows which provider CLIs and credentials CI can use here.
brindle audit verifyEnterprise Sovereign: check the signed, hash-chained audit log and report the first broken record (--repo for another repo).
brindle audit export [--since ISO] [--format jsonl|csv]Export the audit log for your security team (unverified; run verify too).
brindle audit pubkeyThe public key that signs this install's audit records, for verifying offline.
brindle attach [WS] / cd WS / open [WS]Jump into a workspace's tmux session, print its path, or open it in your editor (--editor, default $BRINDLE_EDITOR or code).
Workspaces and branches
brindle new BRANCH -p PROMPTA worktree on a new branch with an agent working on the prompt (-b BASE, -a PROFILE or none, --provider, --no-fetch, --no-setup). --pr N checks out a GitHub pull request's branch instead.
brindle status / diff [WS]Compared with the base branch, committed and uncommitted.
brindle sync [WS]Rebase (or --merge) the latest base into the branch.
brindle commit / push / pr [WS]Commit everything (-m MSG), push with upstream, open a pull request (-t TITLE, --draft). The first brindle pr in a repo offers to turn on GitHub's automatic deletion of merged branches.
brindle merge [WS]Merge into the base branch locally (--squash).
brindle setup [WS]Re-run the repo's setup commands.
brindle rm WSStop its agents, remove the worktree, and its branch once fully merged (-K keeps it, -D deletes a merged one, -f discards uncommitted changes).
Agents
brindle send ID MSGMessage an agent; delivered when it's idle.
brindle close IDStop an agent and hide it (--exited: every stopped one; add --all for every repo). Its worktree and branch stay.
brindle pruneApply the cleanup rules now: old paused sessions, merged worktrees (and their merged branches), leftover tmux sessions. Worktrees with uncommitted changes stay.
brindle agent spawn / kill / peek / profilesStart another agent in a workspace, stop one, see its screen, list profiles.
brindle mcpThe MCP server agents talk to. brindle launches it for them.
Tools the agents get
assign / handoff / wait_for_workerStart a worker: return now, or wait for its result (and keep waiting). Take weight, files, depends_on, plan_first and, with several repos attached, repo.
send_messageMessage another agent; delivered when it's idle.
read_messagesAn agent reads the messages other agents and brindle sent it, and marks them read.
list_agents / list_tasks / list_agent_profilesWho's running (with each worker's last tool call), what's queued, which profiles exist.
list_reposThe repos attached to the session (Power-Dev Pro; brindle repo add).
cancel_taskCancel one of your queued tasks (and anything waiting on it), e.g. to re-plan.
workspace_diffA worker branch's changes against its base.
request_review / submit_reviewStart a reviewer on a branch; the reviewer's verdict.
merge_workspace / remove_workspaceMerge through the gates; delete the worktree.
report_resultA worker finishes a task and hands back the result.
submit_plan / approve_planA plan-first worker proposes its plan; the supervisor approves it or sends it back with feedback.
complete_subagentThe supervisor records the result of a subagent-profile task.
set_goal / get_progress / check_milestoneAutopilot's goal, its progress, and running the checks.
need_userPause autopilot and ask you a question.
transfer_to_repoMove scratch work into a repository.
handoverHand the session to a new supervisor on another branch or worktree, with a note.

Copying chat text. Drag with the mouse in the chat: the selection stays inside that pane and is copied to the system clipboard (pbcopy, wl-copy or xclip). Ctrl-b z zooms the chat by hand, and "sidebar": "bottom" puts the dashboard under the chat instead of beside it. The sidebar follows you between brindle windows, and Claude Code's own subagents show nested under the agent that started them. If it's left behind in another tmux session, brindle sidebar (or Ctrl-b S) brings it here.

brindle CI

brindle works in your CI too. With brindle Pro it fixes broken builds, within a monthly limit on one repo; with brindle Team it fixes them without the Pro limit, turns issues into pull requests that have proven themselves with your tests, and checks pull requests with evidence. With brindle Team a Jira ticket can start a run too, and the ticket gets the status back; no Atlassian app is needed. On Pro and Team, brindle learns what works in each repo, uses it in later runs, and can propose updates to your agent instructions file as a pull request for you to review. It runs in your own GitHub Actions with your own model access. Claude signs in with an Anthropic API key (the ANTHROPIC_API_KEY secret) or with Anthropic workload identity federation (WIF). A key scoped to a workspace works as is; an organization-level key also needs the repository variable ANTHROPIC_WORKSPACE_ID (wrkspc_...), which the job sends as the anthropic-workspace-id header. For WIF, set the repository variables ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID and, if the rule covers several workspaces, ANTHROPIC_WORKSPACE_ID, and instead of holding a key the job exchanges its GitHub OIDC token for a short-lived Anthropic token that all of the run's agents share, and brindle ci run mints a fresh OIDC token and exchanges it again before the Anthropic token expires. If both are set, the API key is used. With WIF, a federation rule token lifetime of 10 minutes is enough, even though a run can last up to 2 hours. The CI job never pushes: it uploads its commits, the agents never see the job's GitHub token, and the brindle GitHub App opens the pull request. Set a repository up with brindle ci init.

Questions

Does it cost anything?

No. brindle is free to use and source-available (Brindle License 1.0): parallel agents, review, merging, autopilot and local models cost nothing. Optional paid plans add per-worktree services, hosted learning, sessions across several repos, brindle CI, team policy and a local audit log, and an air-gapped enterprise edition. Pricing

Is brindle open source?

No, it's source-available under the Brindle License 1.0, from PawDelta LLC. You can install and use brindle for free, including at work and for commercial projects. Beyond configuration, plugins, private fixes and contributions, modifying or redistributing it needs PawDelta's written permission, and using it to build a competing service (listed in SCHEDULE-A) isn't allowed. The full text is in the LICENSE file that comes with brindle.

Whose Claude, Codex or Antigravity account does it use?

Yours. brindle launches the CLIs you already have installed, signed in the way you normally sign in. It never stores your credentials or reads your CLIs' login tokens; it only passes along keys you put in a profile's env lines or a native profile's api_key_env. Its quota notes come only from what those CLIs write locally.

How does Claude sign in to brindle CI?

With an Anthropic API key stored as the ANTHROPIC_API_KEY secret, or with Anthropic workload identity federation (WIF). A workspace key works as is; an organization-level key also needs the ANTHROPIC_WORKSPACE_ID repository variable, the workspace its requests go to. WIF needs no stored key: the job exchanges its own GitHub OIDC token for a short-lived Anthropic token, using the federation rule, organization and service account you set as repository variables, and all of the run's agents use that token. If both are set, the key is used. For WIF, a federation rule token lifetime of 10 minutes is enough: brindle mints a fresh GitHub OIDC token and exchanges it again before the Anthropic token expires, so a run can still last up to 2 hours. brindle CI

Can I run it without a subscription?

Yes, for workers and reviewers: the native provider runs open-weight models on Ollama, LM Studio or llama.cpp on your own machine, or on a hosted API. The built-in developer-local and reviewer-local profiles are ready for Ollama.

Will it merge into main without me?

No. The pipeline reviews and merges worker branches, but a branch whose base is your default branch waits for you (or for the supervisor's merge_workspace). Point merge_into at an integration branch to let it merge there freely.

What happens when I hit my usage limit?

Near your Claude limit, autopilot pauses its Claude workers, keeping all their work, and restarts them when the usage window resets. Routing skips a provider that's at its limit.

Does my code leave my machine?

Only the way it already does when you use those tools yourself. brindle runs locally and keeps its state in ~/.brindle; free brindle sends PawDelta nothing. On your machine, the paid plans never send code, prompts or file paths. brindle CI is different: it uploads the commits it made, check output and review results so it can open the pull request (Privacy). With local models for every worker and reviewer and no paid plan, brindle sends nothing to PawDelta; your supervisor's CLI still talks to its provider, and brindle fetches and pushes to your own git remote.

What happens when I close it?

The brindle window closes and you're back at your prompt. Every agent process is stopped, an Ollama server brindle started for you (with local_models on) is shut down once no other brindle session needs it, and the session is paused with its work saved until you run brindle continue.

Do I need a git repository?

No. Outside a repo, brindle starts a scratch session, and brindle transfer ~/path/to/repo moves the work into a real repository when you're ready.

Which version am I running?

The tmux status bar of every brindle session shows it, and brindle --version prints it. The latest release is 0.0.6. Upgrade with uv tool upgrade brindle.

Something broke. Where do I report it?

Run brindle doctor first, then open an issue on GitHub.

Pricing

brindle is free to use, source-available (Brindle License 1.0), and that won't change. The paid plans add what a single checkout can't give you: isolated services for every worktree, sessions that span several repos, agents that run in CI without anyone watching, and the controls and records regulated teams need.

Free

Developer Core

$0 forever

Free to use, source-available (Brindle License 1.0). No account.

  • Everything on these pages: parallel worktrees, autopilot, the review-and-merge pipeline, the sidebar
  • Claude Code, Codex, Antigravity and open-weight models, mixed freely
  • No limit on agents, workers or sessions
  • Runs entirely on your machine; code goes only to the providers you choose
  • Plugin interfaces for policy and events
Get it
curl -fsSL pawdelta.com/brindle/install | sh
For power users
Pro

Power-Dev Pro

$15 / month

For one person running many agents on real backends.

  • Per-worktree services: its own Postgres, Redis or any container per worktree, on its own ports, so parallel agents never share a database
  • Hosted learning: learns which profile fits which task, on every machine you use
  • Savings report: brindle account savings shows what learning's picks gained in each repo
  • Several repos in one session: brindle repo add attaches another local repo, and the supervisor puts workers there too
  • Settings sync: your brindle preferences, such as delegation and sidebar position, follow you to every machine
  • Falls back to local routing offline; never blocks your work
  • Learning and settings sync send only task features and hashed keys, never code, prompts or paths
Fixes broken builds
30 fix attempts a month
1 repo
The default branch and brindle's own PRs
Up to 30 CI runs a day per org
At most 2 fix attempts per failing commit
Up to 100 min and 2M tokens per run, on your own model keys
Upgrade to Pro

or in a terminal: brindle account upgrade

Team

DevOps Automation

$25 / seat / month

For teams running agents on shared code and in their pipelines.

  • Everything in Pro, with learning shared across the team, and across your company's orgs if you turn it on
  • brindle CI: label an issue and brindle plans it, runs the workers in GitHub Actions and opens the PR, without the agents ever holding a token that can push
  • Org policy: allowed providers, models and profiles, a worker cap, required human review, with overrides per role
  • Org savings: monthly learning totals for admins on the account page
  • Audit feed: delegations, reviews and merges, kept for a year
  • Invites, roles and seat management
Fixes broken builds
Every repo; the default branch and any open PR
Pushes to people's PRs when your org's policy allows it
Up to 200 CI runs a day per org (issues, Jira and fixes combined)
At most 2 fix attempts per failing commit
Up to 100 min per run, on your own model keys
2M tokens per run by default, adjustable in org policy up to 50M
Start a team

or in a terminal: brindle account upgrade --team --seats N --org ORG

Enterprise

Enterprise Sovereign

Custom

For defense, finance, healthcare and government teams.

  • Everything in Team
  • Custom policy roles: define your own roles and give each member the rules that fit
  • Air-gap mode: no traffic to brindle's servers, an offline license and policy, only models on your own network
  • Tamper-evident audit trail: a signed, hash-chained log your security team verifies offline with brindle audit verify
  • Priority support, with terms in your contract
Fixes broken builds
Every repo; the default branch and any open PR
Pushes to people's PRs when your org's policy allows it
Custom limits on CI runs a day and fix attempts per failing commit, set per contract
Up to 100 min per run, on your own model keys
2M tokens per run by default, adjustable in org policy up to 50M
Learn more

Already have a plan? Your account shows it, with billing and team members, and brindle account shows which features it includes and how to turn each one on.

Questions about the plans? Email support@pawdelta.com.

Enterprise Sovereign

Coding agents your security team can sign off on.

Run brindle entirely inside your network, on models you host, with a signed record of every agent action that your auditors verify themselves. Built for defense, finance, healthcare and government teams.

Talk to us Compare plans

Annual pricing for your team's size. Includes everything in Team. Or email support@pawdelta.com.

air-gapped workstation
$ brindle doctor
✓ air-gap          on via .brindle/config.json
✓ model            qwen3-coder:30b on 10.0.4.12
✓ default agent    developer-local
✓ offline license  enterprise, no network needed
✓ offline policy   .brindle/policy.json
! hosted profiles  refused in air-gap mode

$ brindle audit verify
audit/payments.jsonl: 1284 record(s),
chain intact, every signature valid

Nothing leaves your network

Air-gap mode blocks every request to our servers and every hosted model.

  • Only models on this machine or your private network can run.
  • Once a process starts air-gapped, no config change can turn it off.
  • Your plan and policy load from files, so nothing phones home.

Every action is on the record

A hash-chained log, signed with Ed25519, of everything agents did and everything policy stopped.

  • Delegations, reviews, escalations, merges and removals, with who and which model.
  • brindle audit verify finds the first edited, deleted or truncated record.
  • Export to CSV or JSONL for your SIEM or your auditors.

Rules that fail closed

Decide which providers and models agents may use, and who has to approve a merge.

  • Allowed providers, models and profiles, a parallel-worker cap, required human review.
  • Custom roles give each group of developers its own rules.
  • If the policy file is missing or broken, brindle refuses work instead of running unchecked.
  • Pair it with branch protection for a guarantee no client can bypass.

From first call to agents in production

  1. Talk to usTell us your team's size, where agents will run, and what your security review needs to see.
  2. Get your licenseWe issue a signed offline license that brindle checks locally. Install the renewed license before the old one expires.
  3. Set your policyWrite .brindle/policy.json, point brindle at your own model server, and let brindle doctor confirm the setup.
  4. Run agentsYour developers use brindle as usual. Your security team verifies the audit log whenever it likes.

What Enterprise adds to Team

TeamEnterprise Sovereign
Parallel agents, review before merge, brindle CI✓✓
Org policy: providers, models, profiles, worker cap, human review✓✓
Policy per roleOwner, admin and memberPlus custom roles
Audit feed of delegations, reviews and mergesHosted, 1 yearHosted, plus a signed local log
Runs with no connection to our serversNoAir-gap mode
ModelsAny providerAny, or only your own
LicenseOnline, refreshed dailyOffline file
SupportEmailPriority, with terms in your contract
Price$25 per seat per monthPer contract, by team size

Questions security teams ask

Does any code or prompt reach PawDelta?

No. In air-gap mode brindle makes no requests to us at all. Even outside it, the paid plans never send code, prompts or file paths. See Privacy.

Which models can we run?

Any model served over an OpenAI-compatible API on your network, such as Ollama, LM Studio or vLLM, through a native profile. Hosted CLIs are refused.

Can a developer turn policy off?

Not from config while air-gapped, and a missing policy blocks work. The client enforces it, so require reviews in your Git host too when you need a hard guarantee.

How do we check the audit log ourselves?

brindle audit verify recomputes every hash and signature, and brindle audit pubkey gives you the key to check exports with your own tools.

Bring agents inside the perimeter.

Tell us about your team and environment. We'll reply with pricing and a rollout plan.

Talk to us support@pawdelta.com

Privacy

What brindle sends to PawDelta, what we keep, and how it's protected. The short version: free brindle sends us nothing. On your machine, the paid plans send only counts and hashes, never your code, prompts or file paths. brindle CI, which works in your GitHub repo, is the exception, described below.

Free brindle

brindle without an account makes no requests to PawDelta: no telemetry, no analytics, no update checks. Your agents talk only to the model providers you configure, under those providers' own terms.

Signing in

  • You sign in from the terminal with brindle account login, approving the login in your browser. Credentials are kept in your OS keychain (macOS Keychain or the Linux Secret Service), or in a file only your user can read where neither exists.
  • Your plan is a signed license that brindle checks offline, so a brief outage or a flight doesn't interrupt your work.
  • Sessions are short-lived and rotate as you use them. brindle account logout revokes this machine's session on our servers and deletes its credentials locally.

What the paid plans send

  • Hosted learning (Pro and up) sends a summary of each finished task: its kind and size, the profile and weight that ran it, whether it was approved and passed its checks, review rounds, escalations, tokens and time, plus opaque ids for the repo and the task. Each record is logged with your account id and IP address. When a task is finished, it also says which profile brindle would have used without learning and whether learning made the pick, so admins can see what learning gained. It never sends task text, prompts, code, file or repo paths, branch names, or provider and model names. Asking for a suggestion sends the new task's kind, size and weight, with the candidate profile names and their relative cost. The learner runs only on PawDelta's servers, never on your machine.
  • Learning across your company is off unless an org's owner or admin turns it on. Then that org's learning records, the same ones listed above, are pooled only with the other orgs its owner linked into the same company, never with another company. Profile names are pooled as written, including your own, so give private profiles neutral names. Turning it off stops new contributions.
  • Settings sync (Pro and up) stores the brindle preferences you set for every repo, from a fixed list such as delegation and sidebar position, with your account, so they follow you to other machines. It never stores command lists, paths or repo settings.
  • Outside CI, repos and agents are identified by keyed hashes (HMAC-SHA256 under a key PawDelta keeps for your organization), not by name. brindle CI identifies your GitHub repository by its owner/name.
  • Team events (Team and up) add the provider, model and who acted, so admins can see delegations, reviews and merges in the audit feed, with the member's account id and IP address.
  • Profile names, organization names, invite emails and CI token names are sent as you write them, so keep secrets out of them.

brindle CI

brindle CI runs in your own GitHub Actions, through the brindle GitHub App, and works on your code, so it sends and keeps more than the rest of brindle:

  • A run uploads a git bundle of the commits it made (up to 25 MB), its check and milestone output, reviewers' replies and any question it has for you. We verify the bundle, push it to a brindle/ci-* branch and open the pull request; the bundle itself isn't kept.
  • To plan a run, we read the issue or pull request, its diff, repo files such as .brindle/config.json and your workflows, and for a broken build the failing job's log, and send the runner instructions built from them.
  • Run and pull-request-check records keep the repo's owner/name, branch and commit, issue or PR number, the task's title and text, check commands with short output excerpts, file paths and findings from the review, model names and token counts. They're deleted after 90 days.
  • Jira ticket text is kept for up to 7 days. Jira links (site, project, allowed account ids) and the repos the GitHub App is installed on are kept until you remove them.
  • Repo knowledge (build and test commands, flaky workflows, failure kinds) is encrypted with the learning key and kept until you reset it or uninstall the app.
  • CI's audit rows name the repo, PR or issue, and Jira key, and are kept for one year.
  • Model credentials stay in your GitHub repository: an Anthropic API key secret, or for Anthropic workload identity federation, repository variables naming the federation rule, organization and service account. The run job exchanges its GitHub OIDC token with Anthropic itself; we never see your keys or either token.

How it's stored

  • Everything we store is encrypted at rest with keys used only by this service, each organization's records are kept under its own id and reachable only by its members, and learning data is also encrypted separately per organization. The API accepts only HTTPS, and the site tells browsers to use HTTPS only.
  • Secrets such as refresh and CI tokens are stored only as hashes.
  • Learning data is also encrypted with a key only the running service can use. PawDelta's staff can't read it without changing that key's policy, or the service's code or permissions, and AWS CloudTrail records each of those changes.
  • The audit feed is kept for one year. It records the account id and IP address of sign-ins, token refreshes, license checks and learning records on every plan. Sign-in codes and expired sessions are removed automatically.
  • Your account, organizations, settings and learning data are kept until you ask us to delete them. Expired records are usually gone within two days, and backups keep deleted data for up to 35 days.
  • Org policy is enforced by the brindle client. Pair it with your Git host's branch protection when you need a guarantee that can't be bypassed.

Who at PawDelta sees it

To run the service and answer support requests, PawDelta's owner console shows totals (accounts, plans, revenue) and each organization's id, plan, seats, member count, billing status and creation date, but not members' emails or names. The owner can change an organization's plan, for example to grant a free upgrade, and set an Enterprise organization's CI limits; both changes are logged. Your other data is read only to answer a request you make or when the law requires it.

This website

pawdelta.com counts views of its main sections (home, tempo, brindle), one number per section per day. It sets no cookies for this and stores nothing about you: no IP address, browser details or identifiers. The counts are deleted after 90 days. Signing in to your account sets a session cookie that lasts an hour or until you sign out, plus a cookie holding only "signed in" so these pages can show your account button. The sign-in page itself (Amazon Cognito) sets its own cookies.

Payments

Stripe handles checkout and billing. Your card details go to Stripe and never reach PawDelta. We give Stripe your account email, and keep your Stripe customer and subscription ids and your subscription's plan, seats, status and renewal date.

Who else is involved

The service runs on Amazon Web Services, which also handles sign-in (Amazon Cognito). Payments go through Stripe. If you use brindle CI, we work with GitHub through the brindle GitHub App, and with Jira when you link it. We don't sell your data or use it for advertising.

Your account

To get a copy of your data or have your account deleted, email support@pawdelta.com. For agents that should never reach us at all, see air-gap mode in Enterprise Sovereign.

Last updated October 6, 2026.

Changelog

What changed in each release of brindle, newest first. Upgrade with uv tool upgrade brindle; brindle --version shows what you have.

0.0.6 Latest

brindle CI

  • brindle ci init sets up more for you. It creates the brindle label, offers to mark a check as required (fix builds only fix required checks), and leaves you on the branch you started on.
  • Federated runs keep their Claude access for the whole run. brindle refreshes the Anthropic token during the run through a local credential proxy, so the agents never see it. A 10-minute federation rule lifetime is enough.
  • Unattended federation setup: --rule-id, --organization-id and --service-account-id.
  • Clicks stay with brindle in chat panes. Claude Code now tracks the mouse, so tmux used to pass every click into it: drag-to-copy broke and a click could trap you in Claude Code's Settings dialog. Clicks now focus the pane, drags copy, and the README shows how to close that dialog (Esc up to three times).

Fixes

  • Fixed bugs related to brindle ci init.
0.0.5

Fixes

  • Fixed bugs related to PR validation in brindle CI.
0.0.4

brindle CI

  • Sign Claude in with workload identity federation instead of an API key. brindle ci init asks "API key or identity federation?" (or pass --credential key|federation) and stores your federation rule, organization and service-account IDs as repository variables, so there's no Anthropic secret to create, rotate or leak. init prints the Claude Console rule to create.
  • Organization-level API keys work too. Pass the workspace ID with brindle ci init --workspace-id; workspace keys work as is.

Fixes

  • Fixed bugs related to brindle ci init.
  • Fixed bugs related to Claude credentials in CI.
  • Fixed bugs related to running brindle CI on GitHub Actions.
0.0.3

brindle 0.0.3 adds multi-repo sessions, turns brindle ci into the client for the hosted brindle CI service (which adds fixing broken builds, repo knowledge and a Jira trigger), and makes brindle hold up when tmux stops answering.

  • New in the brindle CI service (hosted by PawDelta; works with the 0.0.3 client):
    • Issue to pull request (Team). Label an issue, and brindle runs the work in your GitHub Actions and opens a PR. brindle never merges.
    • Pull request checks (Team). brindle checks pull requests and reports the results.
    • Fixes broken builds (Pro). When CI fails, brindle opens a fix PR, proven by your own CI. On Pro: 1 repo, with a monthly quota.
    • Repo knowledge (Pro). brindle learns what works in each repo, uses it in later runs, and can propose updates to your agent instructions file.
    • Jira trigger (Team). Start brindle runs from Jira tickets and get status back on the ticket. No Atlassian app needed.
    • Larger runs (Team). Org admins can raise the per-run token budget in org policy.
  • Sign-in checks in brindle doctor. For each installed agent CLI (Claude Code, Codex, Antigravity), brindle doctor shows how it's signed in and whether a quota limit is in effect. It names a key's environment variable, never its value.
  • Antigravity sign-in. Antigravity works with GEMINI_API_KEY when its settings select the Gemini API ("modelProvider": "gemini"), including a key kept only in a profile's env lines. A worker whose Antigravity is signed out is refused with a clear message instead of sitting on its login screen.
  • tmux problems no longer take agents down.
    • Every tmux call now times out (30s, or BRINDLE_TMUX_TIMEOUT) with a one-line explanation, instead of hanging brindle.
    • Cleanup never decides agents have died from a hung tmux server, or from another tmux server's pane list (for example brindle demo's private server).
    • brindle never kills your default tmux server.
    • Starting brindle inside a tmux pane switches to the session instead of nesting a client, even when TMUX is unset.
  • Multi-repo sessions (brindle Pro). One session can work across several repos. Attach them with brindle repo add <path> [--name alias], and list or remove them with brindle repo ls and brindle repo rm. The supervisor hands work to workers in any attached repo. Each repo keeps its own checks, reviews and merges. Task dependencies work across repos, and a milestone can run its check in another repo (check@alias: …). brindle ls and the sidebar group work by repo. Without attached repos, nothing changes. Without Pro, repo add and cross-repo tasks say so.
  • brindle ci is now the client for brindle CI (brindle Pro for fixing broken builds; Team for everything else). The work runs in your own GitHub Actions with your own model keys: Claude Code, Codex and open-weight models. brindle ci init sets up a repo in one command; model keys go into GitHub's own secret prompt, and brindle never sees them. brindle ci start, run and report are what the generated workflow runs, and brindle ci doctor shows which agent CLIs and keys a CI job has. A run triggered from a Jira ticket whose text has expired ends cleanly with a message instead of failing the workflow.
    • Breaking: 0.0.2's local CI commands (brindle ci entitle and brindle ci publish, and the old brindle ci run) are gone. A workflow made by 0.0.2's brindle ci init stops working once it installs 0.0.3: run brindle ci init again to replace it.

Upgrade with uv tool upgrade brindle, then restart running sessions to pick up the new code.

---

Docs and install: pawdelta.com/brindle · Release notes: pawdelta.com/brindle/changelog

0.0.2

brindle 0.0.2 gives the dashboard a new paw.

  • A new paw in brindle watch. The header's paw has rounded toes and a fawn pad with brindle-brown stripes, the same paw as on pawdelta.com/brindle. It's a row shorter, so the agent list gets more room.

Upgrade with uv tool upgrade brindle.

0.0.1

brindle 0.0.1 is the first release of Brindle by PawDelta: a supervisor that runs Claude Code, Codex, Google Antigravity and open-weight models side by side in tmux, each agent on its own git worktree and branch, with checks (and, under autopilot, a review) before a branch merges.

What's in it

  • Parallel workers on their own branches. The supervisor splits a goal into tasks, gives each worker its own worktree, and merges a branch only after the checks pass and, under autopilot or with "review": true, a review approves it.
  • Goals and milestones. Give brindle a goal with milestones; each milestone has a check command, and it turns green only when that check passes.
  • Learning picks models. Each routing tier starts from a baseline profile; hosted learning may pick a better candidate. Set reviewer or review_profile (for example reviewer-codex) when you want a second model's review.
  • Local models stay off until you ask. local_models now defaults to false: brindle uses an Ollama server that's already running and never starts one or preloads a model. "local_models": true lets brindle start a local Ollama and load its models.
  • Permission rules. brindle permissions check shows the effective rules per provider without changing anything, and profiles can add their own permission_denies.
  • brindle sidebar brings a session's sidebar into the tmux session you're in (Ctrl-b S does the same), and follows you between brindle windows.
  • brindle demo runs the whole loop on a tiny practice repo in a few minutes.
  • Savings report (Pro): brindle account savings shows what learning's picks did in this repo, this month and last, against the baseline. Org admins and owners see monthly totals for the whole org on the account page.
  • Learning across your company (Team): link several orgs into one company and let each org opt in to pooling its learning. Off by default; never shared with another company.
  • Policy per role (Team): owners, admins and members can each get their own overrides, policies can limit agent profiles (allowed_profiles), and Enterprise can define custom roles.
  • Safer brindle CI (Team): brindle ci entitle, brindle ci run --bundle and brindle ci publish split a run across three machines, so the agents never hold the CI token or a token that can push; brindle ci init writes that workflow. (Replaced in 0.0.3 by the hosted brindle CI service.)

Install

uv tool install brindle (or pipx install brindle), or curl -fsSL pawdelta.com/brindle/install | sh. The command is brindle.

License

brindle is free to use and source-available under the Brindle License 1.0 from PawDelta LLC. It is not open source: see LICENSE and SCHEDULE-A in the package. Contributions need a signed CLA.