ccfleetAlpha

Privacy

Last updated 2026-10-15

What ccfleet is

ccfleet gives you a slot on a machine we operate: your own Linux account there, with Claude Code, signed in to your own Claude account. The operator decides who gets slots. To reach the operator, write to cdcupt@gmail.com.

Think of Fleet as the desk that connects your computer to your selected account. Your computer does the file and tool work. It sends selected model context over HTTPS to Fleet; Fleet chooses one of your selected slots and uses its Claude sign-in to request a reply from Anthropic. The reply returns to your computer.

What we get from Google

When you sign in with Google we ask for your email address, whether Google has verified it, and the id Google gives your account. We keep the address and the id. We do not ask for your name, your photo, your contacts, or access to your Gmail, Drive or anything else in your Google account.

What we keep because you use ccfleet

Health and usage details

Reports include the email address and plan of the one Claude account signed in on the slot, and one-way account and bound-account fingerprints. They cannot be turned back into the account ID or email. The fingerprints detect an account used on two machines or a slot signed in to another account than its own. Reports also include the plan’s rate-limit tier, when that sign-in expires, quota readings and reset times, credential-renewal state and attempt timestamps with fixed reason codes, never tokens or raw native errors. Hourly token counts for the past week are calculated on the slot; only the numbers leave it.

Relay measurements report request counts, completed transfers and fixed error categories over seven UTC calendar days. Connection, first-body-byte and total-request timing have sample counts, means and maxima, observation time and last completed-transfer time. Validated input/output and cache-read/cache-write token totals show their completed-response sample coverage. Missing or partial usage is unknown, not zero or a bill. These metrics contain no model names, request IDs, headers, bodies, paths, email addresses or credentials. The seven-day aggregate window is distinct from how long heartbeat snapshots are retained here. We keep these reports for 30 days.

Your slot’s heartbeat reports do not include prompts, conversations, file contents, your Claude credential, or the name on your Claude account. This is separate from model traffic: the HTTPS gateway receives and processes the contents of model requests and responses.

Your Claude account and access keys

You sign in to Claude yourself, through Anthropic. The credential is written only on the machine in your slot; this server never stores it. While a sign-in is in progress, its link, the code you paste and its progress are held here for at most 15 minutes. If it fails, its reason is retained for your page, for at most 15 minutes. Account-change results follow the same limit.

When you connect the Fleet CLI, its single-use pairing code is stored only as a hash for ten minutes. Each connected computer has its own public SSH key and random Fleet access token; the server stores only the token hash. A Fleet key grants Fleet access; it is not your Claude credential.

HTTPS model access uses a separate revocable endpoint key. The server stores its hash, name, selected own slot IDs and current rental bindings in priority order, routing mode, configuration generation, creation/last-use times and revocation time. A key selects only slots held by its account, with one bound Claude account per slot. Short-lived routing hashes keep conversation affinity and failure cooldowns separately from usage statistics.

The selected slot sends supported model requests to Anthropic using its bound account. Native Claude on the slot owns credential writing and renewal. The slot credential is never returned to your computer or the gateway. Anthropic’s own terms and privacy policy apply.

Slot providers and network exits

The public slot list names the host provider and IP/exit provider separately, with the operator-declared Residential, ISP or Datacenter category and monthly rate. It uses neutral machine numbers and does not publish holder identities, slot nicknames, machine addresses or proxy credentials.

A proxy-routed slot keeps provider TLS verification enabled. The exit provider can observe connection destinations, timing and encrypted traffic volume; the proxy tunnel does not terminate the HTTPS connection to Anthropic. The slot host's administrators retain access to the slot and its credentials.

Your local work and model context

ccfleet local runs the original Claude CLI, tools, files, settings and conversation history on your computer. It does not upload your whole project. File excerpts, prompts and tool results selected as model context are sent with model requests.

HTTPS encrypts traffic in transit. TLS ends at the gateway. The gateway can read model requests and responses, including sent prompts, tool results and file contents. The selected slot and Anthropic also process that model context. Your account credential stays on the slot. Read the connection guide for setup and account selection.

Native permissions govern file and command access; the working directory is not a sandbox. Bypass mode can modify, delete or transmit local data without individual approval prompts. MCP servers, hooks, plugins, shell tools, updates and other native services may connect directly from your computer. Optional telemetry controls are not an all-traffic firewall.

The gateway and slot relay remove selected request headers and the top-level metadata field. This filtering does not redact arbitrary prompts, tool results or file contents. Native prompts may include local OS, working directory and environment details. The gateway can also see your connection IP and timing. This is not anonymity.

Native local history/settings remain in their existing location. Setup does not automatically erase existing files or saved history. Disconnecting or revoking a computer does not undo writes or erase content already received or saved in native history.

Project preferences are private local settings indexed by a directory hash. Background jobs keep prompts, options, project paths and bounded stdout/stderr logs in private files on your computer; they may contain sensitive content and are retained until deliberately removed. Job listings hide prompt and path contents. Doctor/status exports contain only allowlisted health facts and fixed recovery guidance, not job logs, credentials or project contents. Exports are saved only to your requested local file and never automatically uploaded to the operator.

What the operator can see

The machines are ours, and their administrators have root. They can technically read any slot's files, and its Claude credential. The operator console does not expose these contents, but root access can inspect or alter model requests and responses. Altered replies may influence local tool actions. Use the service only if you trust the operator and slot host.

The console shows your email address, allowance, held slots, last visit and recorded payments.

Public usage ranking

The homepage ranking is visible to everyone. It publishes each contributing user's measured token totals, a compact model breakdown and an estimated standard API-equivalent USD value over seven UTC calendar days. Only a partly masked nickname chosen by the user is shown; short nicknames are fully masked. Users without a chosen nickname receive a generic label. An email address or account ID is never used as the public name. Masking is not anonymity: a nickname or activity pattern may still identify someone. The ranking can include one contributing user.

The ranking uses validated usage totals from current, fresh, account-bound slot reports. Existing aggregate tokens can be shown without model prices; model details and cost estimates use only new model-aware observations. Eligible native, bridge and gateway model calls are counted at the node once. It is not a complete record of all Claude activity. Missing, partial, oversized or older observations are not reconstructed or treated as zero. Measurement and pricing coverage are shown, and unknown or unpriced usage stays unknown. No prompts, response content, raw errors, hostnames, IP addresses, login accounts or individual request timestamps appear in the ranking.

API-equivalent value is an estimate using the listed standard model prices and cache-pricing assumptions. It is not a Claude Pro/Max subscription bill, an amount paid, a quota balance or a promise of savings. Partial pricing covers only observations with enough known model and cache information; it does not assign $0 to the rest. The primary ranking token total and estimate use the same priceable cohort; broader reported totals and older/unpriced usage appear only in expanded details under a separate scope. Output and reply counts remain in the detailed breakdowns. Processed totals include cached context counted again per request; they are not generated or unique text. Estimates follow reported model labels, and these aggregates alone cannot reliably reprice older usage.

Public performance measurements

The public Status performance panel combines existing numeric relay measurements from current, fresh slot reports. It shows transfer completion and average slot-side timing over seven UTC calendar days, including today. A separate streamed output rate combines matched native/bridge node streams and HTTPS gateway observations over the same window, without counting gateway traffic twice. This performance panel does not split measurements by user or slot or publish names, emails, prompts, credentials or response contents.

Machine availability is shown separately in a compact table under stable neutral labels such as Machine 1, with status and the last report. Your own slot card links to its machine's public label. Operators can also see actual machine names beside those labels after signing in; those names remain hidden from other public viewers. Status describes machine health only; the table has no detailed reasons or per-machine uptime cards.

Traffic figures appear after at least twenty observed attempts. Published aggregates can include only one contributing Fleet user, so a total or average can reflect that user's traffic. Each timing separately needs twenty samples, which can all come from one user. Until enough fresh measurements are available, the panel shows that more aggregate data is needed. A completed transfer requires a successful HTTP reply (2xx) delivered in full; error replies, cancellations and interrupted transfers are not successes. These sampled relay attempts can include a backup attempt for one request; they do not cover gateway failures before a slot is reached or measure answer quality. Viewing Status makes no extra model request.

Streamed output rate is provider-reported output tokens divided by first-to-last response-body chunk time, summed across successful, fully delivered /v1/messages streaming replies observed at a node for native/bridge traffic or at the HTTPS gateway. A sample needs valid usage, at least two chunks and at least 100 ms of delivery time. Single-chunk or too-short replies are excluded; buffering can affect the observed rate. This observed delivery rate excludes the initial wait and includes stream pauses, network delivery and any thinking or tool output included in the provider's output count. Compare only similar models and workloads; it is not a pure model benchmark. At least twenty eligible replies are needed independently of slot-relay measurements. Node observations stay in a private account-bound seven-day relay file and allowlisted numeric heartbeats. Gateway storage contains only anonymous daily sample counts, output-token totals and delivery-time totals for seven UTC calendar days. The public output-rate measure shows no model breakdown, input/cache token totals or individual request timestamps. Older traffic is not backfilled.

Public machine resources

When the operator enables it, Status also shows Fleet's dedicated gateway-VPS CPU, memory and data-filesystem capacity, plus Fleet's own container CPU and memory consumption against its limits. Host figures cover the whole VPS, including system services. They do not list processes, users, IP addresses, individual requests or their contents.

The service samples these numeric kernel counters every fifteen seconds and keeps the latest observation in memory. Values older than one minute are hidden; restarting resets the observations. These infrastructure figures are separate from user traffic and do not require relay attempts or timing samples. Viewing them makes no model request.

Cookies and language

Two necessary cookies support sign-in: your session cookie and the one that ties Google’s reply to the browser that requested it, which lasts 10 minutes; the server keeps a matching record for the same time. We do not use browser-tracking analytics, advertising or third-party scripts. Page language is selected by the English or Chinese URL.

Sharing, keeping and deleting

We do not sell what we keep. If you choose outage emails, your address and slot name go to Resend for delivery only when there is an outage or recovery to report. Servers run at hosting companies we rent from. Google and Anthropic handle your use of their own services: Google sign-in and Claude.

Giving a slot back deletes its Linux account and every file in it, not your local files or Claude account. Your Fleet account and recorded payments remain while that account exists. To delete it, contact the operator: deletion is done by hand after all held slots have been returned and wiped. If these practices change, we update this page and its date.