> ## Documentation Index > Fetch the complete documentation index at: https://continuum-three-olive.vercel.app/docs/llms.txt > Use this file to discover all available pages before exploring further. # Organization & Cloud > Connect a device to your company, opt work accounts into usage reporting, and govern hosted inference: model allowlists, spend caps and comped seats. Continuum has an optional organization layer. It does two distinct jobs, and it is worth keeping them apart in your head because they have different consent models and carry different data: 1. **Usage reporting** — a local collector on each developer's Mac rolls their token usage and cost up to admins. Off until an employee explicitly opts each work account in. 2. **Inference governance** — if your team is on [Continuum-hosted inference](/docs/features/hosted-inference), admins decide which models each person can use and how much they can spend. Enforced server-side. Usage reporting is a cost-reporting layer, not a code-sharing one. The collector uploads **token counts, model names, and repo folder names** — never prompts, responses, code, or diffs. See [What the collector uploads](#what-the-collector-uploads) for the exact contract, and [Privacy](/docs/privacy) for how this differs from signing in to a personal account. ## Connecting your Mac The collector lives in the Mac app, because it reads the on-disk usage files of Claude and Codex logins it can attribute to a single work account. **Settings → Your Organisation** is always present there. When you are not connected, it shows a single **Sign in on the web** button. Continuum opens your browser to the hosted sign-in and shows a short **verification code**. The app validates that the link the server returned is `https` with a real host before opening it — it will never be sent to a `file://` URL or a custom app scheme. Sign-in runs through your organization's identity provider via WorkOS hosted login. Your password is entered in the browser and **never touches Continuum** — the app only learns that the device was authorized. Once the browser flow completes, the app receives an org-scoped upload bearer, stores it in the macOS Keychain, and shows **Connected**. The bearer is the only org secret on the device and is **never** iCloud-synced. This is a standard device-authorization flow: the app polls the backend while you finish in the browser, and times out gracefully if the request expires or sign-in is declined. If you are not yet invited to the organization, sign-in is declined with "you're not invited to this organisation yet." An admin invites you from **Settings → Your Organisation** (see [Invites](#invites)). ## Choosing which accounts upload Linking uploads **nothing on its own**. In the connected state, a **Work accounts to upload** list shows every Claude and Codex account on the Mac — your default plus any [secondary accounts](/docs/features/multi-account) you configured. Each has an off-by-default switch. * Turning a switch on is what authorizes uploading **that account's** usage. The bound set starts empty, so linking can never silently upload a personal account. * Only Claude and Codex accounts appear here, because those are the two whose on-disk usage files can be attributed to a single "work" login. Other providers are excluded from upload rather than risk mixing in personal usage. Once you have at least one account bound, **Generate & upload report now** collects and uploads immediately, and the device also refreshes the report periodically on its own. With no accounts bound, upload is refused outright. ## What the collector uploads The collector reads the bound work accounts' on-disk usage files with the same parsers the [Analytics](/docs/features/analytics) layer uses, then emits **normalized per-event records**. Each record carries: | Field | Value | | ---------------- | --------------------------------------------------------------------------------------- | | Token counts | input, output, cache-creation, cache-read, reasoning, request count | | Model | e.g. `claude-sonnet-5`, `gpt-5.6-sol` | | Repo folder name | the **last path component only** (e.g. `defx-v3`) — a display label, not a path | | Repo key | a **SHA-256 hash** of the repo path — the raw path never leaves the device | | Rail observation | whether the provider was on a **subscription** or **API** rail, with a confidence level | | Timestamps | the UTC event time and capture time | **No prompts, responses, code, diffs, or full file paths are ever uploaded by the collector.** The record and session types are a strict allowlist with no free-form field that could carry content. Cost is also **not** uploaded — the device's price guess is dropped and the server reprices every record from its own rate card, so a device-side pricing bug can't poison org numbers. The connected screen also shows a **What leaves this device** panel that lists every egress with its live on/off state: | Egress | State in org mode | What it is | | ---------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Organisation upload | **active** | Normalized usage records to your organization (above). | | Personal iCloud mirror | **off** | Your detailed per-repo analytics normally sync to your own iCloud so your iPhone can show them. In org mode this is **gated off**. | | Product analytics | active | Aggregate per-provider token/cost/session totals. Never per-repo, per-day, or path-level. Unaffected by org mode, but always disclosed. | Uploads run through a queued outbox with retry, so a flaky connection leaves a report **pending** rather than dropping it. The card shows queue depth and a **Retry queue** button. Each report re-uploads your full usage history under a stable coverage key, so a re-upload replaces the prior set rather than duplicating it. Upload provenance is org-scoped by construction: the device identifier attached to a report is an HMAC of your organization id and the install id, so a consultant linked to two organizations stays isolated between them. ## Disconnecting **Disconnect** clears the org bearer from the Keychain, turns org mode off, clears the upload queue, and **resumes** your personal iCloud analytics sync. Disconnecting stops future uploads from this device; ask your admin if you need data already uploaded removed. ## The admin surfaces Org administration lives in **Settings → Your Organisation** in the web app at [continuumcode.ai/app](https://continuumcode.ai/app) — and therefore also in the Windows and Linux desktop apps, which render the same code. The group is hidden entirely for accounts that aren't part of an organization. It shows your organization name, your role (**Admin** or **Member**), an invite form for admins, and a **Hosted inference** row with a **Manage** button. The Mac app's pane of the same name is the collector described above — sign-in, work-account opt-in, upload, and the egress panel — not the admin console. The rollups the collector feeds are served by the org reporting endpoints — `/v1/admin/summary`, `/v1/admin/spend/*`, and the per-member `/v1/me/usage`. Treat those as the stable interface for spend, vendor, and rail reporting; the admin screen that is mounted and supported in the app today is hosted-inference governance, below. ### Invites Admins get an **Invite a teammate** field and a **Send invite** button. The invitation is issued through WorkOS and the invitee receives a standard organization-invitation email; the local record is only written after WorkOS accepts, so a failed send never leaves a phantom member. Invited people join as **members**. Non-admins see "An organization admin can invite teammates from this pane." ### Hosted-inference governance **Settings → Your Organisation → Hosted inference → Manage** is the control plane for team spend on [Continuum-hosted inference](/docs/features/hosted-inference). It is visible to admins and team leads; members are told the screen is admin-and-team-lead only. A model allowlist with a scope switch for **Org**, **Team**, and **Member**. Toggle each hosted model allowed or blocked at that scope, then **Save**. A blocked model is refused at the gateway, not just hidden in the UI, with *"\ is not permitted for your team by your organization admin."* The block still applies to organizations whose own subscription has lapsed to Free. A table of caps by **Scope / Cap / Period / Soft / Spend vs cap**, edited through a **New hosted cap** sheet: scope (Org, Team, or Member), a cap in USD, a **weekly** or **monthly** period, and a soft-alert threshold. Caps at different scopes bind independently and the **smallest applicable cap wins** — the editor previews which one that is. Soft alerts are configurable at 50%, 80%, and 90%; a 100% alert always fires whether or not you configure one, and alerts are deduplicated per budget, period, and threshold so a busy week doesn't spam the org. A per-member table showing live hosted spend against each person's allocation, with three admin controls: * **Comp** puts a member on a hosted tier the organization pays for (or that Continuum comps), rather than their own card. * **Overage** decides whether a member may keep working past their cap, billed to the organization. With overage off, a capped member hard-stops at their allocation. * **Budget requests** from members arrive in this section with approve and deny actions, so raising a cap doesn't require a side channel. Every one of these is enforced by the inference gateway itself. A blocked model returns a `403`; an exhausted allocation or budget returns a `429` with the specific reason. Because enforcement is server-side, an older or modified client cannot route around it. ## How the backend is built Continuum Cloud runs on Continuum-operated infrastructure backed by **Postgres**. The public-facing properties that matter: * **Records in, server-rolled.** The collector POSTs normalized records to `/v1/ingest`; the server owns costing, timezone bucketing, deduplication, and attribution. The device never gets a vote on what a token costs. * **Tenant isolation by construction.** Tenant tables have Postgres **row-level security** enabled *and forced*, with policies keyed on the requesting organization. Forced RLS means the policy applies even to the table's owner, so an application bug cannot read across tenants by forgetting a predicate. * **Content is sealed at rest.** Mirrored transcript pages are encrypted with a per-member AES-256-GCM key. Removing a member destroys that key, which renders their stored content permanently unrecoverable without hunting down every row — see [Privacy](/docs/privacy#account-sync). ## Two different clouds, one account The most common confusion is treating org reporting and personal cloud sync as the same thing. They are separate paths with separate data: | | Org usage reporting | Account cloud sync | | --------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Turned on by | Binding a work account in **Your Organisation** | Signing in to your Continuum account | | Default | Off | On once signed in | | Who can see it | Your org's admins | You — plus an audited internal path, see [Privacy](/docs/privacy#prompt-inspection) | | What it carries | Aggregate token counts, models, repo folder names, hashed repo keys, rail | Your workspace state and a rolling 30-day transcript mirror, encrypted per member | | Prompts / code | Never | Yes — that is what a transcript mirror is | If you sign in to a personal Continuum account, cloud sync applies whether or not your machine is connected to an organization. [Privacy](/docs/privacy) enumerates both paths byte by byte. ## Device mesh (separate toggle) **Settings → Account** carries a **Device mesh** switch, separate from usage upload — toggling it never changes upload consent. It enrolls your devices through the cloud relay so they appear in **Settings → Devices** and can run agents without Tailscale. Signing in turns it on. See [Remote devices](/docs/features/remote-devices) for how enrolled hosts run sessions. ## See also What the governance screen governs: plans, weekly budgets, and hosted models. The full breakdown of what leaves your machine on each data posture. Trust tiers, tenant isolation, and the cryptography behind the relay and upload channels. Configure the work accounts you can opt into org upload.