Your Claude Code or Codex Session is ready to run the test suite, but another Session has the compile slot. The command has not started. If the Agent stays in the conversation and asks again every few minutes, each check opens another turn with no new test result.
Give Clawdline a command that needs no decisions while it runs, then end the Agent’s turn. The local daemon waits for the resources, runs the command, and sends a completion notice. The Agent returns once to read the recorded result.
The test can wait without the Agent
For a Go repository, the Agent might run:
clawdline heavy -- go test ./...heavy coordinates the machine’s compile slot and available memory. If both are ready, it runs the tests and returns their exit status. If a Root Session has to queue, Heavy Work hands the command to a callback by default. The Root can end its turn while the daemon waits. A Child Session follows its own task to completion instead of handing off this way.
On that handoff, the CLI prints callback <id> started and exits 76. Keep the ID. Exit 76 means Clawdline accepted the handoff; it says nothing about whether the tests passed. If the wait reaches its limit and heavy exits 75, the command did not run. When a callback cannot be started, heavy reports that and waits in place rather than silently treating the handoff as complete.
An already-started CI run does not need the local compile slot. The Agent can hand its wait to a callback explicitly:
clawdline callback --title "CI run ended" --timeout 45m -- gh run watch RUN_ID --exit-statusReplace RUN_ID with the actual run ID. gh must be able to read its own authentication; the callback does not inherit the Agent’s full environment. The CLI prints callback <id> briefed when Clawdline accepts the Task. At that point, end the turn and keep the ID for the completion notice. The callback workflow describes this handoff in the public guide.
The Agent gives up the wait
A queued Heavy Work command becomes a callback, and the Root ends its turn.
The daemon owns the command
It waits for the slot and memory when needed, runs the command, and records its exit.
The Agent reads the result
A notice returns to the originating Session, which checks the Task before continuing.
What the waiting Session means
A callback is a Task owned by the originating Session. It opens no Child Session tab and takes no child slot. The daemon records the command and eventually sends its completion notice to that Session. You do not need to rerun the command because the Session has gone quiet.
There are four moments to keep apart:
| Moment | What you know |
|---|---|
| Accepted | Clawdline recorded the callback. briefed or Heavy Work’s exit 76 is an acceptance signal, not a test result. |
| Waiting for resources | A handed-off Heavy Work command may still be in the compile-slot or memory queue. |
| Executing | The daemon has started the command. The callback’s Task state alone does not prove this moment has arrived. |
| Finished | The command has exited, timed out, or been stopped. Its Task record holds the outcome Clawdline observed. |
This distinction matters when reading a Session’s status. A quiet Session waiting for its own callback is waiting for a command result; it is not asking you to answer a question. Follow the callback ID and Task record instead of reading silence as success.
Read the Task after the notice
The completion notice names the callback and points to the check:
clawdline task show <id>
For a callback, this prints its state and verdict: the command’s exit status when one was observed, plus the last lines of its output. Read those before telling anyone the test or CI run succeeded. A completion notice says Clawdline settled the command; it does not review a build artifact or prove a deployment is live. Delivered, reviewed, and landed remain separate questions.
If the Task says failure or timeout, inspect the output and the command’s effects before deciding whether to retry. An unknown outcome also needs inspection: a command may have ended while the daemon could not observe its exit. Recovery does not blindly run it again. That matters most for commands with side effects, such as a deployment.
What repeated checks cost on one night
We examined our own Clawdline records from 6 October 2026, 20:00, through 7 October, 04:00, Taiwan time. Several Sessions took turns preparing builds: in each of two adjacent half-hour windows, 14 distinct Sessions issued build or check commands. Of 408 successful compile-slot grants during the eight hours, 239 waited at least five seconds before getting the slot. Across Claude Code and Codex, we found 29 sequences in which an Agent read the same background build or check log at least twice. Those sequences contained 127 model requests. The recorded input and output for those requests totalled 15,045,273 tokens.
For a callback estimate, we kept the final recorded request in each sequence as a stand-in for the one return after a completion notice. That leaves 29 requests and 3,869,321 tokens. For these waiting turns, the callback estimate is 25.7% of the observed polling total: 11,175,952 fewer tokens, or 74.3% less. The denominator is the original 127 waiting requests, not every token spent working that night.
| Same 29 waiting sequences | Model requests | Input + output tokens | Relative to polling |
|---|---|---|---|
| Repeated status checks, observed | 127 | 15,045,273 | 100% |
| One return per sequence, estimated | 29 | 3,869,321 | 25.7% |
The estimated difference comes from 98 avoided model turns, not from making the compiler faster. Every status question wakes the Agent and brings conversation context back into a model request, even when the log has no new answer.
Where the estimate ends
This was a retrospective comparison, not a live callback experiment. No callback was replayed for those 29 sequences; a real completion notice could cost a different number of tokens from the last log read. Some status turns may also have supplied useful information. The sample includes Child Sessions, while automatic Heavy Work handoff currently applies to queued Root Sessions. It therefore describes the potential of replacing all selected polling, not savings already delivered across every Session. Tokens are not a bill: cache treatment and model prices can change the money saved.
If the Agent would otherwise check only once, there is little polling to remove. There is no fixed savings percentage.
Use a callback when the command and its stopping condition are already decided and the Agent can judge the result from its exit and output. Keep interactive work in the Session when the Agent must read intermediate output and choose the next step. Callbacks run on macOS and Linux; Windows currently refuses them. Commands that need credentials must read them through their own tool configuration, because the callback receives only a limited set of environment variables.
The next time Heavy Work hands back a callback ID, let the turn end. When the notice arrives, read clawdline task show <id> and continue from the outcome it actually recorded.