Start a new Capy agent thread in the cloud to do a piece of engineering work. The agent runs in its own isolated VM with the project's repos checked out, and works independently of this conversation. Call this once per independent piece of work: calling it several times gives you several agents running genuinely in parallel.

Write the prompt the way you would brief a competent engineer who cannot ask you follow-up questions: state the goal, the acceptance criteria, and any constraint that is not obvious from the code.

Returns a thread id. Use capy_wait to block until the work is done, or capy_status to poll. Note that starting a thread consumes Capy credits.

Get the diff a Capy task produced, so you can review the work without leaving this conversation. Task ids come from capy_status, capy_wait, or capy_list, which list the tasks belonging to each thread.

Large diffs are truncated to stay within a token budget. Use stats_only to see just the file list and line counts first, then request specific paths.

List agent threads in a project, newest first. Use this to see the whole fleet at once: what is still running, what is finished and waiting for review, and what has opened pull requests. Filter by status, tag, PR state, or a free-text query.

Send a follow-up instruction into an existing Capy thread: steer it, answer a question it asked, correct its approach, or ask it to do more work. This is also how you get the agent to open a pull request, since the Capy API has no PR endpoint of its own.

Use mode "interrupt" to cut into work in progress, or "queue" to have the message picked up when the current turn finishes.

Read the message history of a Capy thread: what you asked, and what the agent said back. Use this to get the agent's own summary of what it did, its reasoning, or the question it is waiting on you to answer.

List the models available for delegation, with their provider and whether each can act as the Captain (planner) agent. Useful when you want to deliberately spread a batch of parallel work across different models, or pick a cheaper one for simple tasks.

Ask the agent in a thread to commit its work and open a pull request, then report any PRs on the thread.

This is a convenience wrapper around capy_message: the Capy API has no endpoint that creates a PR directly, so the agent is instructed to do it. The PR will not exist the instant this returns. Call capy_wait or capy_status afterwards to pick up the PR URL.

List the Capy projects this API token can reach, with their ids and connected repos. Call this first if you do not know which project to delegate into.

Get the current state of one Capy agent thread: whether it is running, what it is waiting on, whether it is blocked on a human, its tasks, and any pull requests it has opened. This is a one-shot check that returns immediately. To block until the work is finished, use capy_wait instead.

Stop a Capy agent thread that is currently running. Use this to cancel work that is going the wrong way, or to stop a thread that is burning credits on the wrong problem. Work already committed by the agent is not undone.

Report what your Capy agents have cost over a date range, split into LLM and VM dollars, broken down by user and by thread. Use this to answer 'what did that fleet cost me'.

Requires your organization id, which the Capy API does not expose a listing endpoint for: take it from the Capy web dashboard.

Block until one or more Capy threads finish, then report what happened. This is what turns a fleet of background agents into something you can use inside a single conversation: delegate several pieces of work, then wait for all of them here.

The Capy API has no streaming or push notifications, so this polls with backoff. It returns early, without an error, if a thread becomes blocked on a human (an auth or permission gate), so you never sit waiting on something that cannot progress.

If the timeout is reached the result says so and the threads keep running on Capy's side: just call this tool again with the same ids to keep waiting.