Most automation scripts assume a single uninterrupted run from start to finish. In reality, you often need an operator to approve a transaction, verify a security check, or handle an unexpected UI state. The Coasty runs API exposes this pattern directly. You can set on_awaiting_human to pause a task run when the agent encounters a human approval prompt. The run enters the awaiting_human state, and you can later POST /v1/runs/{id}/resume to re-engage the agent with fresh context. This post shows the exact fields, states, and billing implications for building robust human-in-the-loop pipelines.
How awaiting_human and resume work
To enable human approval, specify on_awaiting_human in the POST /v1/runs payload. Valid values are pause, fail, or cancel. When the agent encounters a human approval UI, the run transitions to the awaiting_human state. You can check the run status with GET /v1/runs or stream events with GET /v1/runs/{id}/events. Once the human completes the approval, you POST /v1/runs/{id}/resume to restart the agent from the last checkpoint. The resume operation respects the original system_prompt, instructions, max_steps, and deadline_seconds you provided in the initial run. Billing remains at $0.05 per agent step throughout the pause and resume cycle.
curl https://coasty.ai/v1/runs \
-H "X-API-Key: $COASTY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"machine_id": "m-12345",
"task": "Open Chrome, navigate to https://example.com, and approve any human prompt that appears."
"cua_version": "v4",
"on_awaiting_human": "pause",
"max_steps": 30,
"deadline_seconds": 300,
"system_prompt": "You are a cautious web automation agent. When you see a human approval dialog, pause the run and wait for manual approval."
}'Key behaviors for the awaiting_human pattern
- on_awaiting_human can be set to pause, fail, or cancel. Use pause to defer to a human operator.
- A run in the awaiting_human state will not consume credits until you call resume.
- The resume request POST /v1/runs/{id}/resume does not require a full task description, just the run ID.
- Stream events with GET /v1/runs/{id}/events to detect transitions to awaiting_human without polling.
- States include queued, running, awaiting_human, succeeded, failed, cancelled, and timed_out.
Always set on_awaiting_human to "pause" and poll events for the awaiting_human state before calling resume.
Where this beats brittle automation
Traditional automation relies on fragile selectors, hardcoded coordinates, and full screenshots. If the UI changes by a few pixels, a brittle script fails. A computer use agent sees the screen, understands the context, and can detect a human approval prompt. By leveraging awaiting_human, you avoid writing special-case logic to guess whether a button is a human approval or a real action. The agent can focus on the core task, and you retain control over critical decisions. This approach works for approval flows, security checks, and multi-step workflows that span dozens of states.
What to build next
Combine awaiting_human with workflows to orchestrate multi-step pipelines that pause for human input at each gate. You can also integrate webhooks to notify your system when a run enters awaiting_human or succeeds. Start by creating a key at https://coasty.ai/developers and then experiment with POST /v1/runs to see the awaiting_human pattern in action.
The Coasty runs API makes human-in-the-loop automation straightforward. Set on_awaiting_human to pause, track the awaiting_human state, and resume with /v1/runs/{id}/resume. This pattern lets you build resilient agents that stay aligned with real-world workflows. Get a key at https://coasty.ai/developers to start building.
Want to see this in action?
View Case Studies