/cloud commands

Every /cloud command the plugin adds to omp, where finished turns and questions go, and the cards they land as.

Wherever a command takes <id> (the cloud tool takes the same references), type the full 12-character thread id (any thread, any age) or one of these, matched case-insensitively among the newest 1000 threads, each in turn until one matches uniquely:

1. The id of the job omp shows for the thread's running turn (PaneZoomShortcut, with omp's -2 suffix when an earlier turn's job still holds the id), or the job id without a suffix.
2. A suffix of the thread id (at least 4 characters).
3. A prefix of the thread id.
4. A word the thread's name starts with (/cloud show zoom, when no other name has a word starting with it).

A reference that matches several threads at one step is refused with up to 10 candidates; use the full id. Completion offers threads by name.

Where results go#

For a thread you started yourself, a finished turn (done or failed) and a question do not land in the conversation. They go to a cloud inbox you read when you are ready, and cost the model nothing:

• The footer status counts them: ☁ 3 unread, or ☁ 2 working · 1 waiting · 3 unread; the owner's footer also says update ready when an update waits for a click.
• /cloud opens the hub, which is the inbox: its header reads ☁ omp-cloud · <user> · N unread, and a thread with unread entries starts with [N new]. Selecting a thread loads its detail and marks it read. The key o opens that thread's latest finished turn as a card with its buttons (it never wakes the model), marks it read and closes the hub; a thread with no finished turn yet says so. The hub footer lists the keys: ↑↓ select · s send · a answer · o open · x stop · p pull · r resume · d delete · q close, plus u update while the owner has an update ready. /cloud show and a card's Show button mark a thread read too.
• In a terminal that supports it, the same entries reach the terminal's own attention tray through the Program Status Protocol (OSC 7501): a pending question shows as blocked, a result as done, a failure as an error, one record per thread, cleared when you read or answer it. In Tern an entry that arrives while the omp pane is unfocused fills "Needs attention" and badges the bell; one that arrives while you are looking at that pane counts as seen and gets no tray entry. Either way the pane's tab shows the state (red for a question) until you read it. It is written only on a real terminal, never headless, and only while omp's terminal.programStatus is on.
• A desktop notification also goes out for each entry, under omp's own switches: completion.notify for a finished turn, error.notify for a failure (off by default in omp) and ask.notify for a question.
• Text that comes from the cloud (thread names, the first line of a reply or error, a question) has control characters replaced with spaces before it reaches the inbox, the tray record or the notification, since some terminals write those raw. A deleted thread's entries and tray record are dropped, and a question already in the inbox is not added or notified a second time when you re-watch a waiting thread. If omp's terminal.programStatus is switched off and on again, or the terminal is suspended and resumed, the records are written again.
• A thread the model delegated through the cloud tool is the exception: its results reach the model, not the inbox (how results arrive).
• Set deliver: transcript in your personal ~/.config/omp-cloud/config.yml to get cards for every thread; deliver: tray is the default. A repository's .omp-cloud.yml cannot set it (ignored, with a warning). /cloud status shows deliver: tray (default) or deliver: transcript (~/.config/omp-cloud/config.yml). The inbox lives in memory for the session and holds at most 200 entries.

Cards and buttons#

Hand-offs, and the finished turns and questions of model-delegated threads (or of every thread with deliver: transcript, or opened with o), land in the transcript as cards. In Tern each ends in a row of buttons that run the command for you; a terminal UI and the model see the command hints instead.

• A launch card has Respond, Show and Stop.
• A finished turn has Respond (the main action), Pull, Resume and Show; a failed one has Respond and Show.
• A single-choice question lists its options (the recommended one badged) and gets one Other… button; a multiple-choice or free-text question gets one Answer… button. In Tern the card lists the options the way omp's ask does; once answered, expired or cancelled it settles and shows the answer. In a terminal without Tern's protocol the card is framed with omp's own output block and status line, with ask markers on a question. A launch card's chip follows turn 1 (running, done, failed or cancelled) and has no chip while that is unknown.
• A card announcing a service update (owner only) has a Restart to update button; a terminal UI shows /cloud update.
• Respond opens omp's input sheet (Reply to <name> · <short id>) and sends your text as /cloud send would. A question of a thread you started yourself opens omp's own ask dialog by itself (all of the turn's pending questions in one; tool approvals and the push question use omp's approve prompt instead, where once, session or a grant approve and deny denies; closing the dialog counts as no answer); Other… and Answer… and /cloud answer <id> without text take the same path, and an omp without those APIs asks with its select and input prompts. A question of a thread the model started wakes the model through its card instead (the model answers an ask question through the cloud tool or asks you); approvals and pushes are always yours, and each question card is posted once. The other buttons run their verbs; Resume switches the session, so where a button has no command context it asks you to type /cloud resume <id>.
• In Tern the /cloud hub is native as well: the threads are a list you select with the keys the footer shows, the selected thread's job tile is shown with its detail, and the actions are buttons with their key caps.

A text box inside a card is not offered: in omp it would fight the composer for focus, so Respond uses the sheet.

Slash commands in the cloud agent#

A message to a cloud agent that starts with / (/cloud send <id> /usage, or the Respond button) runs in the agent's own omp, like a command typed there, when omp can run it over its RPC mode:

• Built-ins with a non-interactive handler work (/usage, /compact, /handoff, …), and so do extension and custom commands, skills and file commands.
• Terminal-only commands and names omp does not know reach the agent as plain text, as they do in omp.
• A built-in command ends its turn about a second after omp answers, not after the usual wait, and its reply is the command's output (plus any messages an extension command prints), cut at 100,000 characters. A built-in that keeps running after it answers (/compact, /handoff, a bare /rename) keeps the turn open until the agent is idle and not compacting, and what it prints meanwhile is the reply. Such a turn costs no model requests, commits only if the command changed files, and pushes nothing; the next model turn pushes what a command changed. The conversation is saved as after any turn.
• /usage reports the agent's own provider usage, which is usually empty in a cloud VM, so omp falls back to the session's token tally and cost. It is not your local quota.
• An extension command whose handler goes on to ask the model is an ordinary model turn: the reply is the agent's text, usage is recorded and the result is committed and pushed as usual. Output that arrives while no turn is running is dropped.

The model's side of all this, the cloud tool, is in The cloud tool.