Cloud orchestration, explained honestly.

Cloud orchestration is an optional mode where TokenFluid Cloud coordinates your sessions across devices and (post-beta) across team members. With it on, you can start a session on your laptop and resume it on your desktop without losing context. The cloud knows the shape of your session — repo hash, file paths, task type, privacy mode — and uses that to route correctly.

With it off, TokenFluid runs entirely on your machine. No metadata, no snippets, no telemetry is sent. The cloud account exists only for billing and API key management if you choose to use them. This is the default, and it is the right default for sensitive codebases and air-gapped environments.

The trade-off is simple. Cloud orchestration gives you cross-device features and shared team history at the cost of sending metadata to the cloud. The metadata is small and shaped by your privacy mode; it never includes source code, the local SQLite index, or the contents of your mounted working set. You can turn it off at any time.

The honest privacy note below is the canonical statement of what cloud orchestration does and does not do. Treat it as the source of truth; everything else on this page is elaboration.

When cloud orchestration is on, the cloud receives the following metadata per session. None of it is source code. None of it can be used to reconstruct your repo. The API validators enforce this in code — fields named source, code, files, content, patch, snippet, diff, text, or body are rejected before they reach the database.

• Repo hash — a SHA-256 of the repo contents at index time. Used to detect changes and route to the right session. The hash is one-way; we cannot recover repo contents from it.
• File paths — relative paths only (e.g. app/services/auth.py). Used for cross-device session resume and for usage analytics. Never absolute paths, never file contents.
• Task type — refactor, bug_fix, feature, test_add, migration, onboarding, triage. Used to bucket usage and to suggest features. Free-text task descriptions are not sent.
• Privacy mode — local_only, metadata_first, no_snippets, snippets_allowed. Used so the cloud knows what it is allowed to request back.
• Token estimates — counts only, never the tokens themselves. Used for usage analytics and quota tracking.
• Session start/end timestamps — used for cross-device resume and for usage charts.

Never sent: source code, repository files, full prompts, full chats, mounted working set contents, local SQLite DBs, patch contents, terminal logs, secrets, .env files, private keys, credentials, or raw snippets (unless your privacy mode is snippets_allowed, in which case only the cloud-requested line-ranges are sent).

Snippets are sent only if your privacy mode is snippets_allowed. In the other three modes, the cloud may ask for a snippet but your local CLI will refuse. Even in snippets_allowed mode, the cloud requests specific line-ranges from specific files — it never receives full files, and it never receives files that are not in the current working set.

1Local machine                  TokenFluid Cloud
2-------------                  ----------------
3[agent runs]
4       │
5       │  (metadata_first, no_snippets)
6       ├──────────────────►  session metadata
7       │                     (paths, task, mode)
8       │
9       │  (snippets_allowed only)
10       │  ◄────────────────  snippet request:
11       │                       file + line-range
12       ├──►  local check:
13       │       privacy mode ok?
14       │       path in working set?
15       │       range within file?
16       │  ├──────────────────►  snippet (line-range only)
17       │  │                     (never a full file)
18       │
19[agent keeps working]

The cloud uses snippets to power cloud-assisted selection features — for example, suggesting that a file outside the current working set might be relevant based on a line-range it has not seen. This is a real feature with a real privacy cost, which is why it is opt-in and clearly labeled.

Cloud orchestration will be a paid feature post-beta. Beta is free. No payment information is collected today, no billing logic runs in production, and no invoice will be sent. When paid plans ship, this section will be replaced with real pricing.

The pricing shape (planned, not final): Pro plan includes cloud orchestration for individual users. Team plan includes cloud orchestration plus shared session history for the org. Local-only mode is free forever — you do not need a paid plan to use TokenFluid on your machine, with the CLI, with any MCP-speaking agent.

Existing beta users will keep beta-tier access for a generous grace period when paid plans launch. If a future feature turns out to require a paid plan, it will be a new feature — not something we take away from you. See the pricing page for the current plan structure.

Enable cloud orchestration with tokenfluid cloud enable. The CLI checks that you have a cloud account, sets your local config to opt in, and sets your privacy mode to metadata_first if you do not already have one set. Subsequent sessions will send metadata to the cloud.

1tokenfluid cloud enable

Disable with tokenfluid cloud disable. The CLI stops sending metadata, stops accepting snippet requests, and removes the cloud registration from your local config. Existing cloud session metadata is kept for audit — it is not deleted automatically. To delete it, see the privacy docs.

1tokenfluid cloud disable

Toggling is reversible. Your privacy mode setting is preserved across enable/disable cycles. The local index, working sets, and patch approval flow continue to work in both states — disabling cloud only loses the cross-device and team features that depend on cloud coordination.

Cross-device sessions are the headline feature of cloud orchestration. Start a session on your laptop, sync, then resume it on your desktop with the same working set, the same selection reasons, and the same audit trail. The cloud stores the session metadata; the actual files stay local to each machine.

When you resume on a new device, TokenFluid Cloud sends the session metadata (paths, task, privacy mode) to that device. The CLI on that device rebuilds the working set from your local index — the cloud never transfers source files. If the new device does not have the repo at the same hash, you will be prompted to sync the repo first.

This is the right trade-off for cross-device work. The cloud coordinates; your machines hold the artifacts. No source code is transferred, ever, even in snippets_allowed mode. The cross-device feature only moves metadata.

Team sessions are coming post-beta. The planned shape: shared session history for the org, so teammates can see what an agent did on a repo without having to ask. Shared working set selections, so a teammate can pick up where you left off. Org-level audit log, so admins can see agent activity across the team.

What team sessions will not be: a way for teammates to see each other's source code through TokenFluid Cloud. The cloud stores metadata, not source. A teammate who wants to see the actual files still needs access to the repo through your normal git workflow. TokenFluid does not become a code repository.

Team sessions will ship as part of the Team plan, alongside SSO and SCIM. Pricing and feature scope will be finalized post-beta based on what we learn from individual cloud orchestration usage. If you want to be a design partner for team features, mention it in your beta signup.