Assistant
Download

Daintree Assistant

An agent whose job is your other agents

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 starts the agents, reads what their terminals print, and takes the next action based on what it sees. It is tuned for that one job and nothing else, which is why it answers quickly.

Create your account See what it costs

The built-in engine costs $20 a month, or $60 for heavy use. It also runs free today on a coding CLI you already pay for, and Daintree itself is free and Apache 2.0.

Illustrative Daintree Assistant panel. Asked to fan a review task across all five worktrees, it has replied that five agents are running, one per worktree, and that it will watch them and say who needs attention. Below that, five actions: three finished (listing the worktrees, spawning the five agents, attaching a terminal watcher to each), one still running after four minutes, and a force push waiting on approval. The approval card names the branch, says the push rewrites the remote, and asks the reader to type the word confirm before it will go ahead.

Why this exists

Code generation got fast. Supervising it didn’t.

One task is one worktree. Five tasks are five worktrees, five agents, five terminals to keep checking, and a queue of things waiting on you. Daintree already makes that work visible. The Assistant is the part that keeps it moving.

What people ask it

The babysitting, handed over

These are the jobs you used to do by hand across a wall of agent terminals. What comes back depends on what it finds in the output, the capability tier you set, and Daintree being up. It reports what actually happened, not what you hoped would.

  • 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 once they are all running.

  • you Find the agents that hit their API limit and resume them once it clears.

    Reads each terminal’s output, looks for the rate-limit errors, waits out the window, and sends the ones it found back to work.

  • you Which agents are waiting on a question?

    Polls every running agent in one pass and tells you who is blocked and on what: the exact prompt each one is stuck on.

  • you Watch this PR and tell me when checks go red.

    Attaches a durable watcher that polls the pull request every 60 seconds and publishes to the attention inbox when the state changes.

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

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.

  1. 01

    A supervised process, rendered natively

    The engine is its own binary that Daintree spawns and supervises, speaking a versioned event protocol over stdio. It used to be a terminal UI rendered inside an xterm pane. It is now a React panel that is part of the app, with Daintree’s own confirm dialogs, notification tiers and motion.

  2. 02

    Reaches the app through a local MCP server

    It attaches to an in-process daintree server on 127.0.0.1 that exposes the app itself as tools: worktrees, terminals, agents, panels, git and your forge. What it can call without stopping to ask you is bounded by the capability tier you set.

  3. 03

    Watches on a cadence, and acts on what changed

    Agent-state changes arrive as they happen. Terminal watchers classify output on a cadence, 120 seconds by default, and pull-request watchers poll every 60 seconds. Both publish to an attention inbox rather than into the conversation. Every Daintree action it dispatches lands in a local audit trail you can read, export and clear.

What you are paying for

Fast, because it only knows how to do one thing

The built-in engine is not a coding assistant with Daintree bolted onto the side. It is a harness tuned for one job, operating your habitat, and it is barred from touching your working tree at all. Any tool whose name looks file-mutating is refused before the process finishes booting. That narrowness is not a limitation to apologize for. It is the reason it is quick.

01

The behavior lives in runbooks, not in the model

Every Daintree operation has a written procedure the assistant follows. It is a library that grows, rather than knowledge a general model is expected to already have. That is the layer that would otherwise be fine-tuning. It also means the model doing the work does not have to be big enough to derive the procedure itself, and a smaller model answers faster. Being narrow is what makes it quick.

02

The runbook arrives with the answer, not before it

A small classifier picks the right procedures for the turn, and the backend renders them into the request that is already going out. The runbook is in hand for that same response, so there is no round trip to go and look up how the job is done. They sit in the stable part of the request, which is what lets them hit the prompt cache across the rounds of a turn instead of being re-read on each one.

03

Speed you can measure

A benchmark suite runs real turns against a scripted Daintree and checks that the assistant actually reached the result. Values planted in agent output have to survive into the final answer, so a plausible-sounding summary cannot pass. It reports a per-round timing split: when selection finished, when the first token landed, and how much of the prompt was cached. Tuning the harness is a measurement, not a matter of taste.

04

Commitments that outlive the process that made them

Watchers, timers, async work, the attention inbox and the conversation are stored per project, not per session. When the attached session exits, or crashes, a daemon takes the ownership lease, adopts all of it and carries on. A coding CLI can poll for as long as its own process is alive. What it has no way to do is hand the job to something else when that process ends.

Pricing

One assistant, two engines, three ways to run it

The Assistant is a Daintree feature, not a model. What changes between these is where the thinking happens, who pays for it, and what survives you closing the lid.

Bring your own CLI

Free from Daintree

Point the Assistant at a coding CLI you already have. It runs on that subscription, and it works today.

  • Included: Costs you nothing beyond the CLI subscription you already pay for
  • Included: Does the same jobs, with the same permission tiers, while you are watching
  • Included: Brings your own commands and skills with it
  • Included: Nothing of yours reaches a Daintree server
  • Limitation: Works each job out from scratch on a big general model
  • Limitation: Stops when its session does. No overnight watching, no memory of the project
Set it up

Where most people will land

Standard

$20 per month

The purpose-built engine: tuned for this one job, so it answers fast. Daintree holds the model credential and pays for every call, including the background ones you never see.

  • Included: Answers fast, because it already knows the procedure instead of working it out
  • Included: Keeps watching after you close the panel, and picks up where it left off
  • Included: Tells you when an agent gets stuck, a pull request turns red, or a job lands
  • Included: Remembers what it learned about the project between sessions
  • Included: No API key and no model bill. The subscription covers the tokens
  • Included: A usage allowance sized for a normal day of supervised work — not yet metered
Start with Standard

Pro

$60 per month

For a habitat that is busy all day. More agents watched at once, longer stretches left unattended, and room to spend a bigger model when a turn genuinely needs one.

  • Included: Everything in Standard
  • Included: Five times Standard's usage allowance — not yet metered
  • Included: More agents watched at the same time
  • Included: Longer unattended runs. Set work going and leave it
  • Included: A bigger model on the turns that need real judgment
Start with Pro

You can subscribe now; the app cannot see it yet. Accounts and checkout live on this site, and a plan you buy is recorded against your account immediately. What is still landing is the other end: signing in to the Assistant from inside Daintree, so the desktop app knows which subscription is yours. Until that ships, subscribing bills you for something you cannot yet use, and the free route is the one that actually runs today. Wait for it if you would rather - nothing here is a limited allocation.

Entitlement is read from the billing system rather than held in a flag the client could flip. The exact monthly allowances get set from what the beta actually spends rather than guessed at now, and they will be published before they start being enforced.

The engine is Apache 2.0 and will run against a backend you host yourself if you would rather. The subscription buys the managed service and the inference it funds, not permission to run the software.

Two CLIs back the free route: Claude Code and Codex. 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.

You stay in control

It reaches exactly as far as you let it

Every action the Assistant takes runs through a capability tier. It limits 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, and they apply to both engines.

1 Read-only

Workbench

61 actions

Watches everything, changes nothing. Reads projects, worktrees, files, terminal output, agent state, git status and forge issues.

2 Default

Action

120 actions

Runs the app: creates worktrees, launches and focuses agents, sends commands, manages terminals and panels. In-app orchestration, which is not the same as harmless. Closing a terminal lives here.

3 Full

System

161 actions

Adds what touches disk and outside services: delete worktrees, commit and push, create and merge pull requests, open and close issues. Three of these are flagged high blast radius and pinned above the rest.

The counts change 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.

Where your work goes

The paid engine is the one place Daintree runs a service in the path of your work

This is the trade the subscription makes, stated plainly rather than buried. On the free route nothing of yours reaches us. On the paid route your conversation passes through a backend we operate, and that is what lets us fund the tokens and pick the model. The paid route has a weaker privacy story than the free one. That is the trade-off.

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

You supply no key at all. The backend holds the upstream credential, owns the system prompt and picks the model, and Daintree pays for every call. That covers the turns you type and the ones you never see: watcher checks on a cadence, async supervision waking up, summarize, extract, classify, memory distillation and compaction. That is what the subscription funds.

you → engine → Daintree Assistant backend → the provider → the model

What travels with a turn. The visible conversation, a project snapshot, your DAINTREE.md up to 16 KiB, runtime context, the tool inventory, and the results of the tools it ran. When it reads a terminal, that output goes to the model. When it reads a file, so does the file. That is how it answers, and it means the boundary is what you point it at. It is cumulative too. The conversation is resent each round until it is compacted or cleared.

A maintainer operates that backend. Not sending a support bundle does not make your conversation private from whoever runs the service, and this page is not a data policy. The Assistant backend will carry its own when it ships. Your Daintree MCP connection stays local on either engine, and the app's own architecture on Trust is unchanged. This is the single documented exception to it.

Before you wait for it

What the built-in engine cannot do yet

It is pre-release software under active development, and these are the things most likely to matter to you. The first four do not 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 before it starts. The binary cross-compiles for Windows and still cannot run there.

  • Pre-release, and it resets

    The wire protocol and the on-disk schema are still moving, and the schema is a single clean baseline rather than a migration chain. An update can move your local database aside to a timestamped backup and start again. A project’s conversation history and its memories do not survive that.

  • Supervision pauses when Daintree quits

    Background work outlives closing the Assistant panel, provided the supervisor daemon started. Spawning it is deliberately non-fatal, so it may not have. It reaches your terminals through Daintree’s MCP server, so quitting the app pauses supervision. It publishes a blocked item and resumes on the next launch rather than inventing an outcome. Do not promise anyone something overnight unless Daintree is staying up.

  • Your commands and skills do not come along yet

    The CLI-backed route picks up whatever you have already written for Claude Code or Codex. The built-in engine has its own runbooks and does not read yours. If that is most of your workflow, the free route is currently the better one.

  • It still asks, but not for everything

    Confirmations are on by default and destructive actions need a typed phrase, but approvals can be remembered for a session, unattended actors run under scoped grants, and an AUTO_APPROVE setting exists and suppresses the prompts. None of that widens the tier gate. It does mean "it always asks first" would not be true.

  • 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 Daintree action 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.

Download for macOS for Windows for Linux Create your account

The Daintree app is free and Apache 2.0 · Read the docs