Start Every Task on a Clean Context, and Stop Paying for the Last One

An always-on Claude Code agent does not restart between tasks. That is the whole point of it — the process stays up, the MCP channel stays open, and the next task arrives at an agent that is already running. Nothing has to be booted, re-authenticated, or reminded where the repository is.

The cost of that is quiet and it compounds. The agent that reads your third task of the morning is the same agent that read the first two, with both still sitting in its context: every file it opened, every diff it produced, every failed test it stared at. None of that is relevant to task three. All of it is paid for, on every single turn of task three, until something clears it.

AgentRQ now clears it for you. An eraser beside YOLO in the task composer says: send this agent /clear before it picks this task up.

What Actually Happens

Three things, in an order that matters.

The backend finds the workspace's running session and types /clear into its terminal. Not a message over the task channel — actual bytes down the session's pseudo-terminal, the same path your keystrokes take when you watch that terminal in the browser. The bytes are /clear\r, with a carriage return, because the PTY is in raw mode and \r is what the Enter key produces. A \n would leave the command sitting on the prompt, typed and unsent.

Then it waits two seconds.

Then it pushes the task.

That pause is the part that looks like superstition and is not. The clear travels down the terminal; the task travels over the MCP session. They are two transports with no ordering between them, so without a deliberate gap the task can arrive while the agent is still acting on the clear — and be wiped by it, which is the exact opposite of what was asked for. The constant is called ClearSettleDelay and it is two seconds: far longer than a TUI takes to handle one command, far shorter than the task poller's sixty-second period, so it costs a task nothing and cannot stack up.

And if the clear cannot be sent at all — no machine, daemon offline, session exited, socket held by another instance — the task is pushed anyway, with a line in the log. Every one of those is an ordinary state of a workspace, and none of them is a reason to withhold work from an agent that is sitting there waiting for it. A stale context is a bad day. An agent that never got the task is a worse one.

The Arithmetic Nobody Does

Here is the part that adds up to real money, and the reason this is a feature rather than a convenience.

Claude Code is stateless underneath. Every turn resends the entire conversation. Prompt caching makes a repeated prefix much cheaper to resend than to send fresh — but cheaper is not free, and the cache read is still a read of every token in that prefix, every turn, for as long as the conversation lives.

So consider one agent that has just finished a substantial task and is carrying, say, 120K tokens of it. The next task runs forty turns.

That 4.8M is one task, on one agent, on one morning. A team running ten agents through ten tasks a day each is not in the millions per day as a figure of speech — it is there by the second coffee, and every one of those tokens is a re-read of work that finished hours ago.

Two honest caveats, because the number is only useful if you trust it. This is arithmetic from how the loop works, not a benchmark we ran: your real figure depends entirely on how big your contexts get and how many turns your tasks take. And because cached prefix tokens are billed at a fraction of fresh input tokens, the dollar saving is a good deal smaller than the token count suggests. The token count is still the right thing to look at, because it is what fills the window.

Which is the second half of the cost, and the one you feel before you see the invoice. A task that begins 120K tokens deep reaches auto-compaction sooner, and compaction does not know which half of the context is stale. It summarises everything — including the details of the task the agent is actually doing — to make room for leftovers from the task it already finished. Starting clean means the whole window belongs to the work in front of it.

What This Unlocks

The clean slate stops being something only a human at a keyboard can ask for. /clear has always existed; what did not exist was any way to invoke it without being present. You had to open the terminal, wait for a moment when the agent was idle, type the command, and then hand over the next task quickly enough that nothing else raced in. That is fine when you are watching. It is impossible when the whole point is that you are not — when tasks are queued from your phone, created by a cron schedule at 3am, or written by another agent. Making the clear a property of the task, decided when the task is written, is what moves it from something you do to something the system does.

Task independence becomes an assertion instead of a hope. A task board is built on the idea that tasks are separate units of work: you can reorder them, reassign them, run them tomorrow instead of today. The agent's context quietly broke that model, because a task's behaviour depended on which task ran before it. Two agents handed the same task in the same repository would do different things, and you would have no way to tell why. Clearing first is what makes the board's promise literally true — the task runs against the repository and its instructions, and nothing else.

Agents can hand each other clean work. The clearContext parameter is on the MCP createTask tool, so a supervisor agent building a queue for a worker decides, per task, whether that worker should start fresh. "Investigate this flaky test" wants the previous debugging session. "Now update the changelog" emphatically does not. Before this, a supervisor had no way to express that difference; the worker's context was whatever it happened to be, and the supervisor's only lever was to write a longer prompt asking it to please ignore everything above. Instructions are a weak tool against context. Removing the context is not.

Stale context is a correctness problem, not only a cost one. An agent that still has the last task's files open does not merely pay for them — it uses them. It matches the conventions of the file it was reading an hour ago, re-runs the test suite it already knows about instead of the one this task names, and answers questions about state that no longer exists. Every one of those is a plausible, confident, wrong answer, and plausible wrong answers are the expensive kind. The cheapest fix for context poisoning is to not have the context.

Five Places to Ask For It

The same flag is exposed everywhere a task can be created, because a feature that only exists in the web UI is not available to the agents that create most of the tasks.

The workspace setting is a default, not an override. What a task was created with is stored on the task itself rather than read from the workspace when it is pushed, so a task you wrote yesterday runs with the choice you made yesterday, even if somebody changed the workspace default overnight. That distinction sounds pedantic until a scheduled task behaves differently than it did last week for a reason nobody can find.

The CLI flag is deliberately only sent when it is passed. An absent flag means "use the workspace default"; a literal false would override that default with an opinion the caller never expressed.

The Limits, Stated Plainly

Only Claude Code sessions are typed into — and they are the only ones that need it. /clear is that agent's command. Sending it to an ACP gateway session would put six stray characters into whatever that agent was doing, so the backend checks the session kind and declines. The same check runs in the browser, which is why the eraser is not there at all in a workspace with no Claude Code session, rather than being there and quietly doing nothing.

That is not a gap in coverage, and this is the part worth being precise about. An acp-gateway session already starts every task fresh by construction: when a task arrives, ensureForTask asks the agent for a brand new ACP session for that task id — session/new, with the MCP connection left untouched — and reuses one only for the task it was created for. A gateway agent has nothing to clear, because it never carries the previous task in the first place. Clear Context exists because a long-lived Claude Code TUI is the one place where it does.

Only running sessions. A session that is still starting will not do: the backend writes to a running session's terminal, and the process that reads the prompt is the thing still coming up. The frontend excludes starting for the same reason, so the condition the icon appears on is the same condition the backend acts on, rather than a second opinion about it.

A clear is not a restart. /clear empties the conversation. It does not restart the process, reload CLAUDE.md from disk, reconnect MCP servers, or forget approvals you granted this session. If you want a genuinely fresh process, stop the session and start a new one — the machine page has both buttons.

It is off by default. Every existing and new workspace ships with the setting off, and no task gets a clear unless something asked for one. Plenty of work genuinely wants the previous context, and a feature that decides that for you would be worse than not having it.

Each successful clear is counted, incidentally — it emits a telemetry event on the MCP topic, once per /clear that actually went out and never on an attempt that failed. How often your agents are actually starting clean is a number, not a guess.

Turning It On

Open a workspace with a running Claude Code agent, start a new task, and the eraser is beside YOLO. Press it for this task only. For a workspace where every task should start clean — a queue of unrelated maintenance jobs, a scheduled overnight run, anything driven by cron — turn it on in Workspace Settings → Automations → Clear context before each task and stop thinking about it.

Then go and look at what your agents were carrying around before.