Self-host or cloud

Studio is the whole product locally. The hosted platform is for the parts a laptop cannot do, and this table is kept to exactly those. Nothing here is a feature held back to make the paid column look longer.

What you do not need an account for

This is the more useful half of the comparison, and the one most pages leave out. All of it works locally, for free, with no sign-in:

• Writing automations with your own coding agent, and editing them by hand afterwards.
• Running them, on demand or on a schedule, for as long as the app is open.
• Connecting real services, with credentials in your OS keyring and brokered on every call.
• Bringing your own model, including a server on your own hardware.
• Webhook ingress, with every delivery stored whole and replayable.
• Per-step run traces with tokens and cost, so a failure is something you read.

Why the cloud rows are what they are

Schedules and webhooks come down to one fact: the dispatcher lives in the app, and a machine that is off cannot fire anything. No amount of local software fixes a shut laptop.

Integrations differ in setup rather than in trust model. Studio brokers 13 services using OAuth apps you register yourself, which is more work and leaves nothing depending on a client id we control. The hosted catalog is larger and you sign in with the service instead. Both broker every call, and neither hands a credential to an automation.

Sharing, teams and the marketplace are about other people having access to something, which is not a thing a single machine can offer.

Moving between them

An automation is a portable artifact: a git repo with an intelligence.yaml that the published runtime executes. docker compose up runs it without Studio. Your own server runs it. So does the hosted platform. Starting locally does not commit you to anything, and moving up does not rewrite the automation.

Nothing in it changes between the two. That is worth stating as a test rather than a promise: if an automation needs editing to be hosted, something in it was wrong locally too. Four things are usually what that turns out to be.

• A declared trigger. Locally you can press Run. Hosted, a workflow with no trigger never fires on its own. It is reachable by webhook or by hand and nothing else.
• Integrations declared, not hardcoded. A hosted run gets its credentials from the broker. A tool that reads os.environ["GMAIL_TOKEN"] works on the one laptop that has that variable and nowhere else.
• No machine-local paths. Anything written to a path that only exists on your laptop is lost. Use the app's data directory or a storage tool.
• A manifest that verifies clean. A dangling reference fails a hosted deploy the same way it fails claritty-seed-verify.

Before handing one over, prove it where you can watch it. Simulation checks the wiring, not the integration, so an automation that has never completed a real run has not been tested:

claritty-seed-verify .                    # clean, no dangling references
clarity-studio run --native --simulate    # the whole workflow, end to end

Then run it once for real, locally. Every automation ships the run-on-clarity skill, so the coding agent in that folder can walk the same list with you.

What a run costs, in each place

Locally, model calls spend whatever key is in your vault, and Studio shows the cost per run so it is never a surprise. Hosted, runs are metered against the workspace. Same accounting, different payer, which is why the run timeline reports tokens and cost in both.

Authoring is separate from either. Writing the automation happens in your own coding-agent session on your own plan. It does not touch the automation's key and does not draw on its run budget.