Effective date: June 25, 2026. This policy covers the hosted alpha service at sleepy.run and the companion Sleepy client when it talks to the hosted service.
What Sleepy does not collect
- Sleepy does not store your LLM provider API keys.
- Sleepy does not execute your repository, tests, benchmarks, or candidate code on the hosted service.
- Sleepy does not intentionally collect local file paths, terminal history, environment variables, or secrets from your machine.
Account and workspace data
When you sign in, Sleepy stores Google OpenID Connect identity fields needed to run the workspace: provider, subject identifier, email address, email verification status, display name, and timestamps. Sleepy also stores workspace names, roles, quotas, usage counters, browser session hashes, and workspace API key hashes.
Browser session cookies and workspace API keys are shown or sent to you as plaintext once. Sleepy stores only hashes for those credentials.
Run and candidate data
Hosted runs can store source-bearing information: seed code, candidate code, diffs, run configuration, target metadata, problem descriptions, constraints, scores, benchmark summaries, lineage, winner history, generated lessons, and profile summaries you report. Treat Sleepy as a source-code-bearing service even though it does not run your code.
Sleepy uses this data to operate the service, resume runs, enforce quotas, support exports, debug incidents, and improve the evolution system. This includes using run metadata, candidate outcomes, and aggregated or de-identified learnings for service improvement and meta-evolution.
Telemetry
The Sleepy client can send anonymous usage telemetry: command, evaluator type, language, provider name, duration, generation count, convergence flag, Sleepy version, and platform. It does not send source code, file paths, run IDs, fitness scores, prompts, responses, or API keys as telemetry.
You can disable telemetry with SLEEPY_NO_TELEMETRY=1, sleepy config set telemetry false, or command-specific --no-telemetry flags where available.
Service logs and operations
Sleepy and its hosting providers may process request metadata such as timestamps, route names, status codes, IP-derived network information, user agents, error messages, and operational metrics. These records are used for security, abuse prevention, debugging, reliability, and cost control.
Subprocessors
The hosted alpha uses infrastructure and identity services including Google Cloud for hosting, databases, secret storage, monitoring, and backups; Google OAuth for sign-in; and GitHub for releases and public support issues. Your MCP client or model provider is chosen by you and is outside Sleepy's control.
Retention and deletion
During the alpha, Sleepy retains workspace and run data while the workspace is active so runs can be watched, exported, resumed, and used to improve the service. Customer deletion is handled manually for now. Request deletion through the support channel and include the workspace email and affected run IDs if you know them.
Backups and operational logs may remain until their normal retention windows expire. Sleepy may retain minimal records needed for security, abuse prevention, legal compliance, and accounting.
Security
Sleepy uses HTTPS for hosted traffic, platform-managed secret storage, managed database backups, and hashed bearer credentials. No internet service is risk-free. Do not submit code or data unless you are authorized to use it with a hosted source-code-bearing service.
Changes
This policy may change as Sleepy moves from private alpha toward paid tiers. Material changes will be reflected on this page with a new effective date.