Spatial
Start Building
Browse docs

Get Started

WelcomeQuickstartLayout modesPrompting guidelinesContext basicsFAQ

Core Concepts

Auto-compactionSubagentsMemoriesModels and capabilitiesToken costsSession hygiene

Workflows

Stash and pop promptsAttachments and contextBrowser preview workflowReview and request changesWidgets sidebarWorking with integrationsTroubleshooting

Desktop App

Settings and preferencesVoice inputMax modeCodebase indexingPopout chatPlatform supportProjects and sessionsAgent modesKeyboard shortcutsCLI toolClaude Code sessionsCodex sessions

Session Environments

Git worktreesSSH sessionsCloud sessionsLocal container sessions

Integrations

OverviewGitHubVercelRailwayLinear

Usage & Billing

Tokens and contextPricingPlans and rate limitsUpgrade subscriptionDowngrade subscriptionRefundsCancel subscription

Tutorials

Snake game starter

Session Environments

Cloud sessions

Cloud sessions run through server-backed execution mode, with stream reconnect/recovery support for resilient long-running workflows.

Execution model

  • Choosing cloud-container maps to a server-side execution mode (Daytona).
  • Streaming requests run over remote SSE sessions managed by the server API.
  • The app keeps local-to-remote session mapping so active streams can be resumed.

Why use cloud sessions

  • Reduce dependency on local runtime/tooling for remote execution loops.
  • Use reconnect/recover stream flows when renderer/app restarts occur.
  • For in-flight requests, execution can continue server-side and the app can reattach to the active stream.

Operating guidance

  • Start cloud sessions when you want more resilient long-running execution than a purely local loop.
  • In current server-streamed flows, exec/file operation confirmations are auto-approved, while question-style confirmations still require your response.
  • Use local sessions when you explicitly need direct host execution and local-first debugging.