What we store
TokenFluid Cloud is a metadata control plane. It stores account, organization, API key, license, session metadata, usage, and support information. Every table in the cloud database holds metadata about your usage — not the artifacts your usage produced. If a row in our database could be used to reconstruct your source code, that row would not exist.
The list below covers every persistent table in the cloud schema. Each entry explains what is stored and why. Nothing here is a cache of your repo, your working set, or your agent's conversation history. Those artifacts live on your machine in .tokenfluid and never get copied into our database.
users
Your name, email, hashed password, role, and login timestamps. No source code, no profile data beyond what you give us at signup.
organizations
Organization name, slug, plan, and owner reference. Used to scope sessions and API keys to a workspace.
organization_members
Membership rows linking users to organizations with a role. No code, no session contents.
api_keys
SHA-256 hash of the key, a displayable prefix, scopes, last_used_at, and revocation state. The raw key is never stored.
licenses
Issued license rows — plan, seats, expiry, status. Used to gate paid features after the beta.
subscriptions
Billing subscription metadata (provider, external id, status). Stripe is not active during beta; the table exists for forward compatibility.
cloud_sessions
Session metadata: repo hash (not contents), relative file paths, task type, privacy mode, token estimates, start/end timestamps. Never source code.
usage_events
Aggregated counts — files indexed, working sets mounted, patches proposed, patches approved. Stored for analytics and quota, never source.
audit_logs
Server-side audit entries for account-level actions: signup, key creation, key revocation, org changes. Local agent actions stay on your machine.
feedback
Messages you submit through the in-app feedback widget. Treated as private, scoped to your account, deletable on request.
support_messages
Email, subject, and message from the contact form. Used to answer your question, then archived.
admin_notes
Internal notes our team writes about a support thread or account. Not visible to you, never contain source code.
beta_signups
Name, email, company, role, use case, repo size, AI tools — collected at beta signup so we can prioritize features and reach out.
invite_tokens
Single-use tokens for inviting members to an organization. Short-lived, hashed at rest, revoked on use or expiry.
What we do NOT store
This is the section that matters most. The following artifacts are never stored in TokenFluid Cloud, regardless of privacy mode, account tier, or feature flag. They live on your machine, in your local SQLite index, in your mounted working set, or in your local session logs under .tokenfluid. If you delete .tokenfluid, they are gone.
- Your source code — never, in any mode.
- Repository files or working tree contents.
- Full prompts sent to your model provider.
- Full chat transcripts between you and your agent.
- Contents of the mounted working set.
- Your local SQLite index in .tokenfluid.
- Patch contents or diffs (cloud stores patch counts, not patch bodies).
- Terminal logs or shell output captured inside the sandbox.
- Secrets, .env files, private keys, tokens, or any kind of credential.
- Raw file snippets, unless you explicitly opt into a diagnostic mode that is not enabled in the MVP.
The schema enforces this in code as well as in policy: the API validators reject any request whose body contains fields named source, code, files, content, patch, snippet, diff, text, or body. Even if a future client bug tried to send source, the server would reject the request before it reached the database.
Local-first model
By default, TokenFluid runs entirely on your machine. The local index lives in .tokenfluid/index.sqlite and contains symbols, imports, file structure, and boundaries — extracted from your repo, not from a cloud embedding service. The mounted working set lives in .tokenfluid/sessions/<id>/working_set and contains the files TokenFluid selected for the current task. Both are plain files on disk.
In local-only mode, the cloud account exists only for billing and API key management if you choose to use them. No metadata, no snippets, no telemetry is sent. The CLI works without an account and without a network connection. This is the right default for sensitive codebases and air-gapped environments, and it is what you get out of the box.
Cloud-orchestrated mode
Cloud-orchestrated mode is opt-in. When enabled, TokenFluid Cloud receives session metadata first — repo hash (not contents), relative file paths, task type, privacy mode, and token estimates. The cloud uses this metadata to coordinate sessions across devices and to surface usage analytics. Selected line-range snippets may be requested back from your machine only if your privacy mode explicitly allows it.
Cloud orchestration never uploads your full repository or your local SQLite index. The cloud does not have the contents of your working set, your patches, or your agent's chat. It has the shape of the session — enough to coordinate, not enough to reconstruct.
Privacy modes
TokenFluid exposes four privacy modes. Each mode governs what the cloud is allowed to receive and what it may request back. The default is metadata_first, which gives you cloud orchestration without snippet transmission. You can change modes at any time from the dashboard or the CLI.
No data leaves your machine. Cloud orchestration is disabled.
Cloud receives metadata (repo hash, file paths, task type). No snippets.
Cloud receives metadata only. Snippet requests are denied.
Cloud may request selected line-range snippets. Full files are never sent.
API key security
API keys are generated using a cryptographically secure random source. The full key is shown to you exactly once at creation time. We store only the SHA-256 hash of the key and a short prefix for display in the dashboard. There is no way for us to recover a lost key — you must rotate it.
Keys can be scoped (read:sessions, write:sessions, read:usage, admin:org) and revoked at any time. Revocation is immediate: the next request with that key will be rejected. We track last_used_at per key so you can spot keys that are still in use before rotating them. Keys are transmitted only over HTTPS as a Bearer header.
Data retention
The numbers below are illustrative for the beta period and will be finalized before paid plans launch. They are conservative on purpose — we would rather keep less than more.
- Beta signups are kept until processed and invited, then retained for 12 months for analytics, then deleted.
- Cloud session metadata is retained for 90 days, then aggregated into usage counts and the per-session rows are deleted.
- Usage events (aggregated counts) are retained for 13 months for trend analytics, then aggregated further.
- Audit logs are retained for 12 months, then archived to cold storage for another 12 months, then deleted.
- Support messages are retained for 24 months, then deleted unless tied to an open legal matter.
- API keys remain until you revoke them; revoked keys are purged after 30 days.
Illustrative — final retention policy will be published before paid plans launch.
Your rights
You can request a copy of the cloud metadata we hold about your account at any time. You can request deletion of that metadata at any time. Both requests go through the contact form and are actioned within 30 days, usually faster.
We can delete cloud metadata. We cannot delete local data for you — that lives on your machine in .tokenfluid and is yours to remove. Running rm -rf .tokenfluid from the repo root removes the local index, all working sets, and all session logs. The CLI also exposes tokenfluid purge to do the same thing safely.
Contact
Privacy questions, data access requests, and deletion requests all go through the contact page. For sensitive privacy or security concerns, mark your subject line clearly and we will prioritise the thread.