# Use (https://condensate.dev/use/)

> Run agents on your accounts, with failover and per-workspace spending limits.

Use Condensate as the place your agents run. You start a task from Dex, your phone, the HTTP API or the SDK, and the runtime runs Claude Code, Codex or its own agent on your Mac, on the Claude and ChatGPT accounts you connect.

## What you get

### Account failover

When an account reaches its usage limit, the task moves to the next account on the workspace's list and resumes from the thread's log. A tool that already ran is not run again, and the task never goes back to an account it already tried. When every account is out, the task stops and names each account, why it is out, and the earliest reset.

### Spending limits per workspace

A **workspace** names the repositories it covers and the accounts its work may spend, and the runtime never spends an account outside that list. A task that asks for an account or model the workspace does not allow is refused before it starts, and the refusal lists what is allowed.

### Logins agents never see

The runtime holds each login and keeps it fresh. By default, agents get a placeholder token, never the login, and never refresh it themselves.

### A builder and a reviewer on one change

A review room puts two agents on one change, for example Claude to build and Codex to review, and both write to one thread you can read. Each verdict belongs to the commit it reviewed, so a new commit needs a new verdict. The room has a round cap, and it stops by itself when the review approves, when it needs you, or when it reaches the cap.

### One list of everything waiting on you

The Needs you list holds every approval and question your agents are waiting on, across all threads. Dex shows it in its header, and you can approve or deny from the list.

### Your phone knows when you are needed

The iPhone app shows a Live Activity on the lock screen and rings when an agent needs you. Tapping it opens the thread. From your phone you can also send a message to a running task, and it reaches the task at its next safe point, never in the middle of a tool call. The app is installed by hand, not from the App Store.

### Recovery after a crash or restart

A thread survives a crash or a restart of the runtime. The next turn resumes from its log.

### Parallel work without collisions

Each task that changes code gets its own git worktree, so parallel tasks do not touch each other's files. You can fork a thread at any point in its history and take the copy in another direction. An agent can hand part of its task to a child agent and read the result back, and it can wake another thread with a message. Pending wakes survive a restart.

### Pacing across accounts

Work is spread across your Claude accounts so one account does not run dry early. See [Accounts and model routing](https://condensate.dev/guides/accounts/).

## The parts

| Part | Role |
| --- | --- |
| Account | One Claude or ChatGPT login. The runtime holds it and keeps it fresh. |
| Workspace | An entry in `~/.condensate/workspaces.json`: its repositories, the accounts it may spend in order of preference, and optionally the models it allows. You can edit the file by hand. |
| Thread | The record of one task. A task that moves to another account resumes from it. |
| Needs you list | Every approval and question your agents are waiting on, across all threads. |
| Review room | A builder and a reviewer taking rounds on one change. |

## How failover works

1. **The provider says the account is spent.** A failing tool does not mark the account. A tool server's own "invalid API key" or "429" is a tool failure, not an account failure.
2. **The account is marked out until its reset.** The reset comes from the account's last usage reading or from the provider's message. If neither gives one, the account stays out for one hour. Some limits cover only one model family, and then only that family is marked out.
3. **The task moves to the next account.** It never goes back to an account it has already tried for this task.
4. **Tools are not run again.** The new session resumes from the log, so a tool that already ran is not run a second time.
5. **When every account is out, the task stops.** The error names each account, why it is out, and the earliest reset.

Two other failures also move the task. A login the provider rejects is marked as needing sign-in, and the error says how to sign in. A model that Codex refuses for one login is recorded for that login only, and the account is not marked as spent.

A workspace can opt in to engine failover. It names an engine and a model, and when every account on the workspace's own engine is out, the turn moves to that engine and model, spending the workspace's accounts for that engine. Without it, the task stops at step 5.

## What a workspace refuses

A task is refused before it starts, and the refusal says what was refused and lists what is allowed. A workspace never borrows another workspace's accounts instead.

- **An account that is not on its list.** The refusal lists the workspace's accounts.
- **A model that is not on its list.** A workspace with no model list allows any model its engines serve.
- **A model that none of its accounts can serve.** The refusal lists the accounts, so you can add one or pick another model.
- **A workspace that is not registered.** The refusal lists the workspaces that are.

An account that no workspace lists belongs to the shared pool. Work that names no workspace spends only from that pool, never from a workspace's accounts.

## How a review room runs

- **Each round runs in a fixed order.** The builder makes the change, then the reviewer reads it and gives a verdict.
- **You choose when the room pauses.** It can pause for you after every round, never, or when a chosen agent ends its message with a marker you set when you create the room.
- **A verdict is recorded against one revision.** The log records it against the exact revision it reviewed, and it says whether the work may advance.

Pull requests can be stacked, each built on the one below it. The runtime's merge receipt reads one pull request at its exact commit: the room's verdict, CI at its commit and at what it merges into, and any open pull request below it, which must land first. The receipt only reports. It refuses nothing.

## What lands in the Needs you list

- a tool call waiting for your approval
- a question from an agent, including an answer you gave that could not be delivered

An item leaves the list when it is resolved, answered or cancelled, or when its thread is archived.

## Read next

- [Connect the tools you already use](https://condensate.dev/connect/)
- [Build on the runtime](https://condensate.dev/build/)
- [Keeping keys away from agents](https://condensate.dev/security/)
- [Quickstart](https://condensate.dev/start/quickstart/)
- [Questions](https://condensate.dev/faq/) and [status](https://condensate.dev/status/)