Run Codex, Claude Code, OpenCode, Hermes, DeepSeek Harness, or Pi in a hosted worktree. Select an available harness/model combination from the deployment's catalog, set a budget, and follow the work as it happens.
Start a run
Choose a workspace for isolated work, a worktree to use its files, or a session to continue its conversation. Select only one of these contexts. Agent presets save reusable configuration; explicit supported overrides apply to the submitted run.
Model availability depends on the deployment and funding mode. Query /v1/harnesses and /v1/models or use the dashboard selectors. A different harness starts a new conversation over the preserved files; native conversation state is not interchangeable across harness families.
Reuse an agent
Once a task works, save an agent preset with its instructions, harness, model, and run configuration. Choose its allowed connections and tools, then reuse that setup with new prompts through the API or dashboard. Saving a preset does not create new tool permissions or start work.
For example, reuse a research agent to update a brief, or a team agent to inspect a repository and write a diagnostic report. Add a schedule, Slack message, or webhook when the workflow should start automatically. The trigger still uses the ordinary run permissions, funding, and capacity checks.
Follow progress
The run view and detailed SSE stream show lifecycle changes, assistant output, tool activity, artifacts, and provider-exposed reasoning summaries. Hidden model reasoning is not available. Retrieve the final result even if you were disconnected during execution.
Execution, persistence, and Git synchronization are separate outcomes. A failed task can still save recoverable files. A completed agent with a failed checkpoint requires recovery attention.
Waiting and deadlines
New jobs can wait up to 24 hours by default. Set queue_timeout_seconds to request a shorter wait. The queue deadline bounds waiting before start; limits.timeout_seconds bounds execution afterward.
The API and dashboard expose elapsed waiting time, deadline, held credits, and the waiting reason: global capacity, account concurrency, or earlier worktree work. Accounts receive weighted opportunities as slots free up. Interactive work has priority within available capacity; running tasks are not interrupted to make space.
Continue, answer, or cancel
Continue a session with another message. A busy session can accept a queued follow-up with queue_if_busy=true, up to 100 queued runs per session by default (the deployment can configure this limit). Answer explicit input requests using their request ID; a follow-up prompt is a separate task.
Cancel with the dashboard, CLI, or POST /v1/runs/{id}/cancel. Queued cancellation releases reserved credits. Running cancellation saves available work and settles consumed usage. It does not undo external tool actions or cancel other queued follow-ups. Leaving a browser or terminal does not stop a run.
Stop after a model failure
For native agents, add these fields to your Run configuration (also supported in saved preset/session limits):
{
"permissions": {"version": 1, "questions": "deny"},
"limits": {"max_cost_micro_usd": "250000", "stop_on_model_error": true}
}
stop_on_model_error defaults to false. With it enabled, the first failed upstream model request permanently closes model admission for that Run. This includes provider rejection, transport/timeout failure, malformed response, or interrupted/error stream. Native retries and reconnects receive HTTP 409 model_request_failed without another upstream call. Requests already admitted can still finish and incur usage; the safeguard cannot undo those calls or external tool effects. Non-generating token counting does not trip it. Invalid requests rejected before model admission do not count as provider failures.
The Run emits run.model_error, stops the native harness, preserves its checkpoint and settles usage through normal finalization. Its terminal status is failed with failure_code: "model_request_failed"; fetch the result to inspect persistence separately. Known usage remains recorded. Missing usage stays provisional, and ambiguous server/transport errors are not reported as free successful calls. Independent new Runs have independent limits; restarting the same failed Run's worker cannot reset the safeguard.
Use questions: "allow" instead when your application can present and answer native questions. Workspace/worktree denial still wins over Run allowance. See permissions for inheritance and harness behavior. These fields are available in the REST schema and all five generated SDKs; inference/decision endpoints have their separate limit types.
Learn more
- Warm sandboxes and long-running servers: reuse compute independently of durable files and sessions.
- Choose a harness: native tools, models, streaming, and continuation.
- Unified Harness Interface: how native adapters connect and how to contribute a harness.
- Custom model deployments: host Hugging Face models or use compatible external chat endpoints.
- Model catalog: built-in choices, discovery, and accepted prices.
- Streaming and webhooks.
- Plans and limits.
- Scheduling policy, runtime implementation, execution architecture, and Workflow recovery.