Daintree Assistant
The agent that runs your habitat
Daintree gives every coding task its own worktree and keeps the runs that follow in one place. The Assistant is the agent that operates Daintree itself: it spawns the terminals, watches their output, and takes the next action based on what it sees, so you stop being the thing that ferries work between panels.
The Assistant ships in Daintree today, backed by a coding CLI you already have. The purpose-built Daintree Assistant is in private testing.
you fan the review task out across all five worktrees
▸ Spawned 5 Claude Code terminals
feat/auth · feat/billing · fix/cache · feat/search · fix/ratelimit
▸ Watching for state changes…
you which ones are waiting on me?
▸ Read output across every running agent
⚠ feat/billing: “Overwrite migration 0009? (y/n)”
the other four are still working
you dock each one as it finishes
▸ Listening: I’ll move them to the dock on completion.
What backs it
One assistant, two engines
The Assistant is a Daintree feature, not a model. Everything below this section is true whichever CLI you point it at. What changes is where the thinking happens and who bills you for it.
Daintree Assistant
Purpose-built for this one job. It never edits your files, which is enforced at startup rather than promised: any tool whose name looks file-mutating is refused before the process finishes booting. When something needs changing it spawns a visible agent into a worktree and supervises that instead.
- Keeps working in the background after you close the panel
- Watches terminals and pull requests, schedules its own follow-ups
- Remembers things about the project between sessions
- Explains what it did from a local audit trail
Claude Code or Codex
The fallback, and a good one. Point the Assistant at a coding CLI you already have and it runs on the subscription you are already logged into. Nothing new to install, nothing new to sign into, and no model traffic that was not already going to that vendor.
- Runs on your existing subscription
- Same capability tiers and the same audit log
- Picks up your own commands and skills
- No background supervision between sessions
Those three are the whole picker. The Gemini CLI was retired in June 2026 and is excluded; Antigravity is a first-class coding agent in Daintree but is not wired to back the Assistant; Copilot CLI is wired and held back as experimental.
Under the hood
It sees the whole habitat
The Assistant has the one thing a bare CLI in a terminal does not: live orchestration context. Every panel, worktree and running agent is addressable, and it can act on them.
- 01
A real agent session, not a chat box
The Assistant is a full agent process that Daintree launches and supervises, with its own conversation, its own tools and its own resume across restarts. That is why it can carry a job across twenty minutes and five terminals instead of answering one question at a time.
- 02
Reaches the app through a local MCP server
It attaches to an in-process
daintreeserver on127.0.0.1that exposes the app as tools, and to adaintree-docsserver so it can answer how-to questions on the side. What it can call without stopping to ask is bounded by the capability tier you set. - 03
Watches the habitat and acts on it
It subscribes to agent state changes and reads terminal output, so it can act the moment something shifts: answer a prompt, resume a rate-limited agent, dock a finished one. Every tool call it dispatches lands in a local audit log you can read, export and clear.
What people ask it
The babysitting, handled
These are the jobs you used to do by hand across a wall of agent terminals. Now you just ask.
you Fan the review task out across all five worktrees.
Spawns an agent in each worktree and sends them the same prompt, a few at a time, then reports back when they’re all running.
you Find the agents that hit their API limit and resume them once it clears.
Reads each terminal’s output, spots the rate-limit errors, waits out the window, and sends every one of them back to work.
you Which agents are waiting on a question?
Polls every running agent in one pass and tells you who’s blocked and on what: the exact prompt each one is stuck on.
you Dock each one as it finishes.
Listens for completions and moves terminals to the dock as they land, so the grid only shows what’s still working.
you Tell all of them to switch to the v2 client and re-run.
Broadcasts the same follow-up to every running terminal at once instead of you typing it into each panel.
you Restart the ones that failed.
Reads the errors, kills the dead terminals, and relaunches them in the same worktree where they left off.
You stay in control
It reaches exactly as far as you let it
Every action runs through a capability tier that sets the blast radius: how far one tool call can reach before Daintree stops and asks you. Set it per project, raise it for a single call, or issue a grant with a use budget. Tiers are cumulative.
Workbench
60 actions
Watches everything, changes nothing. Reads projects, worktrees, files, terminal output, agent state, git status and forge issues.
Action
110 actions
Runs the app: creates worktrees, launches and focuses agents, sends commands, manages terminals and panels. Nothing destructive.
System
149 actions
Adds what touches disk and outside services: delete worktrees, commit and push, create and merge pull requests, open and close issues.
The counts move with every release, and the in-app preview is the authority: it is generated from the same allow-list the server enforces, and it pins the high blast radius actions above the rest. How tiers and grants work.
Cost and data
You bring the key. Nobody marks up the tokens.
Model usage is never resold or marked up. On either engine you bring the credential and it funds the work directly, at whatever your provider charges. What differs is which credential, and where the traffic goes.
Backed by your own CLI
Your existing Claude or OpenAI subscription, used by the CLI exactly as it would be in a terminal. Daintree adds no model endpoint and routes your conversation nowhere new.
you → CLI → your provider
Backed by the Daintree Assistant
Your own OpenRouter key, held request-scoped and never stored by us. Model traffic passes through a Daintree-operated service that owns the system prompt and picks the model; the key funds every call, including the background ones you are not watching: watcher checks, async completions, summarize and extract. Use a dedicated low-limit key.
you → CLI → Daintree Assistant backend → OpenRouter
That backend is the one place Daintree operates a service in the path of your work, and it
is the single exception to the architecture described on Trust. It sees
your conversation, your project snapshot, your DAINTREE.md and the results of
tools it ran, because that is how it answers. It is not shipping yet, and it will carry its
own data policy when it does. Your Daintree MCP connection stays local either way.
Before you wait for it
What the built-in engine cannot do yet
The Daintree Assistant is pre-release software under active development, and these are the things most likely to matter to you. None of them apply to backing the Assistant with a CLI you already have.
macOS and Linux only
Windows is not merely untested. One process at a time owns a project’s state, and that lease is an
flock, which has no Windows port, so every mode that holds state fails there.Pre-release, and it breaks
The wire protocol, the on-disk schema and the sign-in flow are all still moving. An update can move your local database aside and start clean: your sign-in survives, a project’s conversation history and memories do not.
Supervision pauses with Daintree
Background work outlives closing the Assistant panel, not quitting the app. It reaches your terminals through Daintree’s MCP server, so when Daintree quits it publishes a blocked item and resumes on the next launch rather than fabricating an outcome.
The model is still wrong sometimes
It can misread a terminal, pick the wrong worktree, or stop early. That is why nothing destructive happens without the System tier, and why every tool call is written to an audit trail you can read afterwards.
Stop ferrying work between panels
The Assistant is in Daintree now. Point it at the CLI you already have, and swap the engine when the built-in one lands.