Run the task in the cloud. Keep the result for later.

Choose what should execute

For a native Clanker task, start in its Project and Session with the needed Tools. For a supported external harness, use BYOA when it is available to your account. For a separate programmatic shell or runtime, follow Sandbox API. These choices can support agent work, but they do not create the same resource or share every operation.

Identify the actual dependency before deploying: a script, an agent’s native configuration, a website, or an application on a specific computer. A connected computer still needs to be online and approved. A task that can finish from Project files may not need an additional cloud machine at all.

Configure a supported BYOA deployment deliberately

In BYOA, add an agent, choose a supported harness and host, and review the name, tag, Project, and access. Deploy installs and checks a supported cloud agent. Finish any required sign-in, then message it or use its tag in a Session in the same Project. Confirm available runtime, storage, and approval settings before a meaningful task.

Hosting and inference are separate choices. Some supported harnesses can use Clanker inference; Codex and Claude Code use their own provider inference in the documented preview. Hosted Claude Code installation is unavailable in that preview. An existing external host needs the BYOA adapter; a raw agent gateway URL is insufficient.

Sources: Clanker: BYOA setup, runtime, saved state, and usage

Treat runtime as an allowance for an operation

Cloud BYOA runs for setup and accepted tasks within the allowance shown in the product. It is not a promise of an agent process online forever. When a run ends, compute stops; a later accepted message can start compute and restore successfully saved state. Closing the browser tab does not stop an active operation.

Define the useful stopping point in the task: save a reconciled table, prepare a draft, or finish a named analysis. Approval waits also consume hosted compute. Use Stop agent when you want that work to stop, and inspect any submitted operation whose outcome is uncertain rather than assuming the stop reversed it.

Check what was saved before claiming persistence

The registration, Sessions, Project files, and successfully saved private agent files can remain after compute stops. Private snapshots can preserve configuration, memory, skills, and files in the agent home. BYOA shows the last confirmed save. Unsaved changes and running-process memory may be lost after a crash.

Ask the agent to save important outputs to the Project and read them back. For a restoration trial, use a small known file and verify it in a later accepted task. Do not test recovery by assuming an interrupted external action never happened. Retain operation identifiers and inspect the destination before any retry.

Verify tools and recurring behavior separately

BYOA does not currently expose direct Cloud Browser or Cloud Desktop control or every native Workspace Agent tool. Check the selected Workspace tools, connections, and published custom tools for the actual binding. A successfully deployed harness is not proof that a particular browser interaction or external write is supported.

Native Loops and Schedules are separate recurring-work surfaces. Ordinary Channels, Loops, and Schedules do not yet run native BYOA harnesses. Where a supported Telegram connection is available, accepted messages can wake cloud agent work through Workspace; this does not keep the harness’s own native listener online continuously.

Review the completed run as a whole

Inspect the saved result, Session record, actual usage, and last confirmed save. Hosted setup, tasks, and approval waits consume Workspace compute credits. Inference and selected paid Tools have their own charges. External provider inference remains with that provider account. Record these categories separately so the next task has a realistic budget.

For a standalone sandbox, inspect its returned identity, capabilities, status, and expiry, then export needed results before authorized cleanup. Sandbox /data survives compute sleep for the sandbox lifetime, not deletion. Finish every cloud trial with the same question: what result is retained, what resource is still active, and what action starts work again?

Try it with a small example.

Before you use the result.

• The deployed path supports the required operation.
• Runtime and inference choices are verified independently.
• The saved result and confirmed state can be inspected.
• The run has ended or its continued usage is intentional.