Skip to content

Loading search…

中文

Interrupt and take over

You never have to wait for the agent to finish. A message reaches it with its next step, you can stop it where it is, and you can take the computer back at any moment. Every frontend does the same; the table gives the app’s controls and the terminal’s.

To In harness In the app
tell it something type a message type a message
pause Esc (or Ctrl+C) Stop or Esc
go on /continue Continue
end its turn /cancel
approve or reject a step the choices above the input (a digit, or ↑ ↓ and Enter) the card’s buttons
use the computer yourself Take over, then Hand back
end the conversation /end start a new one (the old one stays in the list)

A message is news for the model, and it is told with the model’s next call:

  • While the model writes a reply, the reply is finished and what it says is done; then the model is asked with your message.
  • While a program runs, the program goes on and the model is asked at once, with your message: a program never holds the model’s turn. Its answer decides what happens: it lets the program go on and waits for it, starts another program beside it, or cancels it and does something else.
  • While the model waits, the wait ends.
  • Tasks and sub-agents it started go on until the agent tells or stops them.

So “use the cheaper flight” changes the plan without throwing away the page the agent is reading. To stop it where it is, pause first (below) and then say why: a message sent during a pause replaces a program that had not started.

Each call of the model is one thought, started by one of these:

When
the conversation starts
you send a message with its next call; a wait ends for it
a program ends with its result
a program is still running after a moment the model’s turn comes back while the program goes on
another unit it started ends (a sub-agent, code a program started) with what it ended with
an event or an error nobody handled goes up to the model
a wait it chose is over it is told why: a unit ended, a message, an event, or its time
a reply could not be used
the episode ends a short reflection, which may propose what was learned

Every program the model writes runs as a unit beside the others. One that is over within a moment (runtime.turn_grace_seconds, 2 s by default) gives the model its result with its turn; a longer one goes on, and the turn comes back at once. The model may then start another program, cancel one, or reply <wait>: no call is made while it waits, and the wait ends when a unit it started ended, a message or an event reached it, or its time is over (runtime.longest_wait_seconds, 60 s by default, is the longest). Between calls, reflexes act without the model.

Everything that reaches the model by itself is a notice in one queue, with a priority that its source gives it:

Priority What has it What it does
now an event, what the environment tells, a unit that ended with an error or an event the call that is out is set aside, a reply that did not know does nothing, and the model is asked again with it
next a unit that ended, your messages, a note of the host the call that is out goes on; told with the next call
later a reflex that a program’s priority held back told with the first call after a wait of the model, or with its next turn

Every notice ends a wait and, between turns, starts one; only the end of a unit that was cancelled wakes nobody and is told along with the next call. With each call the model is told, in this order: what its last reply came to (its program’s handle, why its wait ended, why nothing ran); the notices, the more urgent first; and how things stand now: the state, the units that run and what changed in the tree of reflexes. What the run has left (calls, steps, time) is told only where runtime.tell_budget is "always".

What the model leaves running is its own to supervise. It can read what a unit has printed so far while the unit runs: output_of("e3") with the unit’s name, or .output() on its handle from entries(), gives the last characters (2000 by default, at most 30000) and takes nothing from the result, which still has the whole output when the unit ends. With every call the model is told the state as it is then and which units run, for how long, and how long ago each last printed, so it can check on its work before it waits again and cancel a program that is not doing what it expected. A rule that raises an event wakes it for a condition without checking. A program in an isolated workspace gives its output only when it ends.

Esc in harness (or Stop in the app) stops every running program at its next step, and rules are held: nothing more moves, and the model is not called again until you type /continue (Continue) or send a message. A message sent during a pause replaces a program that had not started yet.

/cancel ends the turn that runs: the model’s call is set aside, its programs are cancelled, and the conversation waits for your next message with everything it has.

End ends the conversation. In a run of a benchmark, the environment then scores the episode.

The model’s answer, a reply in plain text, ends its turn, not the conversation. The conversation then waits with its messages, the variables of its programs, its rules, its facts and the environment. What the model left running goes on, and the end of a unit or an event starts its next turn without a message from you. A turn also ends when it has used its model calls or its time (both begin anew with the next turn), when the conversation’s cost limit is reached, on an error, and when you cancel it; the terminal says which.

A sensitive step always waits for you: one that the environment performing it recognizes as touching credentials, a payment, sending, deleting or something that cannot be undone (which environments check). You allow it or reject it, for that step only. With ask = "programs" under [approvals] (Ask before acting in the app), every program waits too: the agent shows it before it runs, and you approve it or reject it with a reason, which the model reads. A rejected step does not run (Permissions).

When the agent works on your own desktop:

  • Take over pauses it while you use the computer. Hand back gives it back, and the agent looks at the screen again before it goes on.
  • Your hands come first. While you use the mouse or keyboard, its steps wait until you stop, and then it looks again. If you bring a window of yours to the front, it stops as after Take over and does not take the screen back until you hand it back.
  • To stop it at once, push the pointer into a corner of the screen.

A background browser, apps in the background and a display of its own never use your mouse and keyboard, so there is nothing to take back: the agent keeps working while you use the computer.

Whether an agent may use the real mouse and keyboard at all, in which apps, and whether it asks first is a setting with several levels, from never to always, with rules for apps, windows and kinds of action. Permissions and privacy describes them; /settings in harness and the app’s Settings change them.

Your messages are marked ● on the timeline, the agent’s ○, a pause ‖ and the end ■. A model call whose reply was set aside or not used is drawn faint, so you can see what your message changed.