What Deck sends.
Usage totals.
No code, paths or prompts.
Deck uses small usage snapshots to understand which agents and features people use, whether its own updates reach people, and where to focus development. They describe participating install-days, not total installations, individual journeys or user retention.
Which version are you running?
Deck 1.1.0 and later send usage analytics automatically and have no in-app opt-out. No account is required. Releases up to 1.2.0 send every field below except updates; later releases send all of them.
The public 1.0.0 release and older Tauri builds do not send these analytics. Earlier development builds that show a “Share usage stats” setting follow that setting. This notice describes the analytics-enabled client and its receiving service; publishing it does not change an installed build.
The complete payload
Each request contains only the following fields. The service rejects additional fields.
- schemaVersion
- The payload format version, currently 1.
- dailyId · day
- A random identifier generated for each local calendar day, plus that date. It lets repeated snapshots replace the same daily record. There is no permanent installation identifier in the payload.
- version · platform · arch
- The Deck version, macOS or Windows, and ARM64 or x64 architecture.
- agents
- Daily launch counts for Claude, Codex, OpenCode, Antigravity, Gemini and Cursor Agent. All custom agents share a single “custom” bucket; their names and commands are never sent.
- surfaces
- Daily open counts for the browser, Explorer and usage dashboard.
- maxTabs · maxPanes
- The highest number of simultaneous tabs and panes that day.
- restoredSessions
- Whether any session was restored that day, as a yes-or-no value.
- updates
- Daily counts of Deck's own update steps: checks that got an answer, checks that failed, answers that offered an update, downloads that finished or failed, and installs started. Counts only — no error messages, update versions or times.
Never in this payload: code, prompts, replies, terminal output, file names or paths, repository or branch names, browser URLs, agent commands, account names, hostnames, locale, time zone, or individual action timestamps.
The receiving service adds a first-received timestamp solely to enforce retention. It does not read or store your IP address, user agent or location as analytics fields.
Small, cumulative snapshots
The client sends a snapshot after startup, roughly every 15 minutes when counters change, a six-hour heartbeat, and a best-effort final snapshot when it quits or hands an update to the installer. Later snapshots replace the same day's counters instead of adding them again.
Deck keeps up to seven daily buffers locally to retry failed delivery. The service accepts dates from the preceding 30 UTC calendar days through the following day, allowing for local time zones. Older snapshots are discarded rather than reintroduced after cleanup.
Requests travel over HTTPS to api.deck.spacevibe.dev/v1/ping. No public statistics or data export endpoint is provided. These unauthenticated counts are internal product feedback, not verified adoption figures.
A short life for daily records
Raw daily records are scheduled for deletion from the live database within 35 days of first receipt. Cleanup starts at day 34 to leave room for the daily job; a failed job can delay deletion and requires operator attention.
Before deletion, the service retains coarse totals grouped by day, app version, platform and architecture. These totals contain no daily identifier and may be kept longer for internal analysis. Aggregation and deletion happen in one database transaction.
Cloudflare D1 also maintains recovery history through Time Travel. Depending on the account plan, deleted data can remain recoverable for up to 30 additional days (7 days on the free plan). This recovery history is separate from the live database retention schedule.
Where the request goes
SpaceVibe operates the receiving service on Cloudflare Workers and D1. Worker request logging, invocation logging and tracing are disabled for this service.
Cloudflare necessarily handles network metadata, including IP addresses, while delivering and protecting requests. Disabling application logging does not remove that infrastructure processing. See Cloudflare's privacy policy for its practices.
The website hosting this notice is served by Vercel and has its own network delivery processing. See Vercel's privacy policy.
Questions or corrections?
Contact the maintainer through the SpaceVibe Deck issue tracker. Please do not include private code, credentials or other sensitive information in a public issue.
Material changes will receive a new dated notice. This September 12, 2026 notice adds the updates counts; the September 7, 2026 notice it replaces remains available.