Projects, harnesses, and Sessions

Project ownership

A Project separates model credentials, Sessions, files, reusable configuration and usage. A Project key cannot access another Project, even when the same account owns both. The current Alpha is single-owner; team roles, invitations and ownership transfer are not available.

Harness and configuration

A direct request selects a supported harness, provider, model and instructions. An Agent is an optional saved preset for reusable instructions, tools and environment settings. Choose one configuration source rather than combining inline fields with a preset.

The runtime families include Claude Agent SDK, OpenAI Runtime, OpenCode and Pi. Pi is an explicit choice for compatible built-in and custom Project providers; a Project with only a custom provider still defaults to OpenCode. Compatibility depends on the provider credential, model protocol and runtime. An unavailable selection fails explicitly rather than silently switching harness or model.

Session ownership and continuity

Each Session has an isolated execution workspace. There is no Agent type to select, and no shared Agent machine for new Sessions. A Session retains its admitted configuration; changing a preset affects new Sessions.

A successful Run commits working files and native continuation before reporting completion. A follow-up uses the same Session and committed state, including after container reclamation. Running processes, sockets and temporary credentials are not durable state. Missing recovery state cannot be replaced with an empty workspace or a new Session without changing the user's task.

Formal and API-used Sessions have no recurring inactivity deadline. Archiving preserves stored state; permanent deletion removes it. Cloud debug Previews alone may use an explicitly recorded 30-day inactivity policy. Existing shared Sessions and reviewed read-only migration cohorts require their own verified transition. See Session continuity.

Thread, Run and published versions

Thread is the public API resource name for a durable Session. A Run is one execution turn with status, events, files and usage. New work uses a new Session; related follow-up keeps the same ID.

Direct v2 execution does not require publishing. With a saved preset, new v2 Sessions use its saved configuration and freeze it. The v1 compatibility API keeps published/live configuration selection and required userId. Publishing snapshots configuration for those older delivery flows; it does not change an admitted Session.