Check-ins

Some work outlives a single reply: a CI run that takes 20 minutes, a render queued on a GPU box, a swarm comparing plan revisions. An agent that says “I’ll check back when it’s done” needs something that actually brings it back. Check-ins are that something: the agent schedules a time to look again, and at that time Snippbot starts a turn for it — no message from you required.

What you see

When an agent is waiting on work, it ends its reply with a short status and a line like State: waiting. Alongside, it schedules a check-in:

In the web app, a Check-in in 14m chip appears in the room’s toolbar, next to the reply cap. Click it to see each scheduled check-in — which agent, what it’s waiting on, and why it chose that time — and to cancel one or all.
In the mobile app, a small clock pill in the chat header shows the same; tap it for the list.
When the check-in comes due, the agent posts a status update in the conversation: what it’s waiting on, its current state with evidence, and an updated estimate. Then it either continues the work (it finished), schedules the next check-in (still running), or reports the problem (it stalled or failed).
In Slack, Google Chat, Telegram and Discord, those status updates are posted to the conversation’s channel or thread too, so a conversation you started there doesn’t go quiet.

Your own messages take priority: a check-in that comes due while the room is busy waits its turn, and one that comes due while you have an unanswered question from the room is deferred until you answer.

How agents choose the time

The agent estimates from evidence — elapsed time, stages done and left, the observed rate, how long similar work usually takes — plus a modest margin, and records that reasoning with the check-in. You can see it in the chip’s panel (“~18 min total, 4 elapsed”).

If an agent ends a reply with State: waiting but forgot to schedule a check-in, Snippbot arms a backup check-in (shown with a backup badge) and immediately asks the agent for a real estimate. So a waiting agent always has a time to look again.

Agents that launch long commands use Snippbot’s durable job runner: the command runs in its own process, survives the end of the reply (and daemon restarts), and when it finishes the agent is woken with its actual exit code and output. A check-in is the backstop in case that notification never arrives.

Stopping check-ins

Cancel one — open the chip (web) or pill (mobile) and press Cancel next to it. The agent isn’t woken for it.
Cancel everything — press Stop while a reply is streaming: it stops the turn and cancels every open check-in in the conversation. When nothing is running, use Cancel all in the chip’s panel.
Tell the agent — “stop checking on the deploy” works too; the agent can cancel its own check-in.

A check-in also ends by itself when the agent declares the work done, when the conversation is deleted or archived, or when the agent leaves the room or is muted.

Limits

Limit	Default	Setting
Delay	1 minute – 24 hours	Longer waits belong in the Scheduler
Check-ins one agent may fire since you last spoke	12	`SNIPPBOT_CHECK_IN_MAX_CHAIN`
Check-ins a whole conversation may fire since you last spoke	24	`SNIPPBOT_CHECK_IN_MAX_ROOM`

When a limit is reached, the agent is told to report where things stand and ask whether to keep waiting, and you get a notice. Sending any message resets the count.

In a room, the room’s own limit on turns the agents take without you (the continuation limit, which also counts the short turns in which an agent sets its check-in) often applies first. The check-in that hits it isn’t dropped: the agent posts a notice saying it was due and asks you to send a message.

Which agents can use check-ins

Any agent whose tool profile includes schedule_check_in (it’s a core tool, so profiles keep it by default), in solo chats and multi-agent rooms, on claude-native, codex-native and API providers (Anthropic API, OpenAI-compatible, Gemini). An agent that can’t schedule a check-in is never told to, and isn’t held to one.

Team mode (the Architect → Executor → Reviewer run) doesn’t use check-ins.

API

Method	Path	Description
`GET`	`/api/chat/conversations/{id}/check-ins`	Open check-ins, soonest first
`DELETE`	`/api/chat/conversations/{id}/check-ins/{check_in_id}`	Cancel one
`DELETE`	`/api/chat/conversations/{id}/check-ins`	Cancel all in the conversation

The chat.check_in.changed event on /ws/events fires whenever a conversation’s check-ins change (payload: conversation_id, and agent_id when one agent’s changed). See the Chat API.