Your dashboard belongs on your device.

Public website

This website cannot read local Codex files. It serves product information, current download availability, and a reviewed aggregate community snapshot when one is published. It does not enroll contributors or accept uploads.

Local source inventory

TiboTattle processes metadata from these local Codex sources:

• The selected session folders:
  • sessions
  • archived_sessions
• Rollout lineage: state_5.sqlite
• Service-tier settings: config.toml
• Methods of the installed Codex app-server:
  • account/read
  • account/rateLimits/read
  • account/usage/read

Local processing and storage

Source records are parsed on your Mac. Prompts and response text may exist in Codex's own rollout files, but TiboTattle does not retain them in derived state. It stores content-free indexes, settings, cached calculations, checkpoints, and prepared contributions in the owner-only Usage Monitor Application Support root. Pseudonymous identity and device credentials use the macOS Keychain.

Processes and network

The app starts a loopback-only local companion and the installed Codex binary's local app-server subprocess. Local analysis works offline.

Network access is limited to explicit capabilities such as signed update checks, contribution, device disconnect, credential renewal, and public aggregate reads. The website cannot reach the loopback dashboard. See Hosting for the services that answer those requests.

Hosting

TiboTattle's hosted service has two parts: Cloudflare at the front, and Google Cloud behind it.

Cloudflare is the front door. It handles the encrypted connections for the tibotattle.com website, admin and update hosts, serves this website and the downloads, hosts the update feed and update files, applies request-rate limits, counts downloads, and protects the admin console with Cloudflare Access. Cloudflare also keeps a small database used only for one-time values that protect publishing to the update feed. Each value is accepted for about five minutes and is deleted when a later publishing request arrives; Cloudflare's recovery history for that database can keep it for a limited time after that. These values contain no visitor or contribution data.

Google Cloud runs the service that handles contributions and holds hosted data. Accepted contributions and the figures calculated from them are stored in a Google Cloud SQL (PostgreSQL) database, which Google Cloud also backs up. Bounded, encrypted contribution objects are stored in Google Cloud Storage. The Google Cloud service has a public address, but it answers only requests signed with a Google identity token for an account we authorize: Cloudflare's front door, and a verification account that can only read the service's health and readiness status. It refuses unsigned requests.

Cloudflare sees visitors' network addresses, as any web front door does, and uses them for request-rate limits, which it computes at the edge with a keyed hash whose key exists only at the edge. Cloudflare's request analytics also record the addresses of update checks and downloads; the edge reads them there only to show the admin console counts of distinct downloading addresses, and only those counts leave Cloudflare, without reaching our Google Cloud service. The edge does not pass visitors' network addresses to our Google Cloud service: it replaces the address header it forwards with a fixed placeholder, and in a test on the tibotattle.com network no header that reached a Google Cloud test service carried the visitor's address. Our Google Cloud service stores no per-address values. This describes what reaches our service. It is not a statement about connection details that Google's own network handles on the way, including when the edge obtains its Google identity tokens.

Before the move to Google Cloud, the same hosted data was held in Cloudflare D1 and R2. Those stores are no longer written to. They are kept frozen until the service owner decides their retirement; no deletion date has been set.

Optional contribution

In the Electron app, fresh installations enable sharing automatically. No social sign-in is required. You can turn sharing off in Settings or Community; that choice persists across restarts and upgrades that preserve your app profile. Local analysis keeps working with sharing off.

• Saved sharing choices are preserved. Known off, paused, or disconnected installations stay off.
• An existing installation with no prior choice receives three visible notices while sharing stays off. Activation requires all three notices, at least seven days from the transition's start, and at least one day after the final notice.
• Choosing Share now or Keep sharing off cancels the remaining reminders. Unreadable or uncertain preference state does not enable sharing.

Shared measurements can include token counts, model labels, quota observations, and pseudonymous continuity identifiers. They exclude prompts, responses, credentials, private paths, and raw account identifiers. The public website has no enrollment or upload control. Older native Mac releases already paired through sign-in keep their review-and-approve flow until their device credential ends.

Hosted identity and data

Accountless sharing uses an installation credential to authenticate one contribution source. It does not prove a unique person, a unique provider account, or the truth of a measurement. A separate device or reinstall without retained state can become another source. Retries within one retained installation are deduplicated; independently created installations can submit overlapping history.

Sign-in with Google or Apple in the native Mac app is retired at the move to Google Cloud. Native Mac installations already paired through it keep sharing until their device credential ends; to keep sharing after that, they move to the Electron app, which enrolls without an account or sign-in. The older sign-in proved control of a login, not one unique person, and stored a keyed identity hash rather than the provider's name or email. At the move the key for those hashes is replaced, so our Google Cloud service cannot match a Google or Apple login to a hash made before the move. Accepted contributions are closed, content-free telemetry, stored on Google Cloud (see Hosting). Admin operations are exposed only on the Access-protected admin host.

Shared measurements can include opaque account and plan-era pseudonyms, evidence categories, and plan labels. These can link observations within the same enrollment and destination. Accountless sharing uses the installation's current sharing policy; older review-and-approve flows retain their consent requirements. The measurements exclude raw provider account identifiers and do not make uncertain history verified. These pseudonyms are not published in community figures.

Hosted data cannot be exported for a participant. Accountless sharing identifies an installation, not a person, so the service has no identity to export against. The earlier export for signed-in participants is retired, with no replacement.

Community publication

Eligible contributions from signed-in or accountless installations can enter the public community sample. A contribution source is an installation/account track, not a unique person or verified OpenAI account. Separate installations may submit overlapping history. Receiving an upload does not itself publish it.

The daily view publishes activity totals and API-price-equivalent allowance estimates, including comparisons by plan and model. Estimates and visible sample counts may be based on a single source. Small samples are uncertain and can reveal that source’s estimated capacity, even though no source identifiers are published. This is not a guarantee of anonymity.

Daily publication has no minimum source count or per-source cap. Plan and model comparisons use closed UTC dates and omit stale, incomplete, or unstable estimates. Previously released sealed weekly snapshots retain their original eligibility rules, delay, account thresholds, per-account caps, and rounding. Those rules do not apply to the daily view.

Recalculated history. The move to Google Cloud recalculates the published community history from stored contributions instead of copying the figures the earlier service published. Recalculated past values can differ from the earlier published values, for example because of evidence that arrived late or the differences described below. Days published before the move are recalculated over the sources taking part when Google Cloud first publishes, so a source that had stopped sharing before then is left out of those days, and their source counts can differ from the earlier ones.

Frozen interim figures. After the move, and until the first Google Cloud publication completes, the daily view serves an unchanged copy of the figures the earlier service last published. Each day in the copy keeps the release time the earlier service gave it. After the first Google Cloud publication the copy is kept in the database, unchanged, and our service no longer serves it, although web caches can still hold it for up to five minutes. A browser that showed the copy can also show its own saved copy, labelled with its age, for up to seven days when it cannot load the current figures.

Model comparisons. Model-by-model figures are published one date at a time. If a source's calculation for a date cannot be completed, that source is left out of that date and counted in a visible number of sources that could not be evaluated. Evidence that could not be evaluated is never counted as zero. The allowance preview, and the model dates shown in it, are withheld while any source's current fit is missing, and the allowance then shows as temporarily unavailable. The earlier service held back a whole block of model dates until every source had a result, so Google Cloud can show model dates earlier than the earlier service did.

Large sources. Calculations read each source's evidence in bounded batches, and Google Cloud's batches are larger than the earlier service's. For a source with an unusually large amount of evidence, Google Cloud can therefore publish daily values, fits and model dates that the earlier service could not compute, so a figure for the same day can include a source that the earlier figure left out.

Cache-retention figures. These are calculated over all eligible evidence. The earlier service's cache calculation could stall for later days when an earlier day was blocked by conflicting evidence, and could leave very large days unbuilt, so Google Cloud may show values for days where the earlier site showed none or older values.

Model names. Public figures show only the models, speed modes and plans that TiboTattle's reviewed model catalog names. A contribution that reports another name is still stored and counted, but that name is not shown publicly until the catalog adds it.

Past contributions stay. Turning sharing off in the app, disconnecting a device, a credential expiring, and a security block each stop future uploads from that installation. None of them removes contributions already accepted. After the move to Google Cloud, none of them by itself changes figures already published: each day published on Google Cloud keeps a record of the sources it was published with, and any later recalculation of that day uses the same sources, so a source that stops sharing after the move still counts in the days it contributed to. A source that had stopped sharing before the move is the exception described under Recalculated history: it is left out of the days published before the move. An erasure carried out by the service owner is different; see Retention and deletion.

Retention and deletion

The local display window is not a retention limit: accumulated owner-only evidence remains until you run an explicit local erase. Local erase and Keychain identity reset have separate consequences. Turning sharing off stops future automatic delivery; a request already sent may have reached the service. It does not delete previously accepted hosted history or local analysis, and after the move to Google Cloud it does not change published figures (for sharing turned off before the move, see Recalculated history). In the older sign-in flow, Disconnect this Mac stops that device's uploads; signing out only ends the hosted session and does not disconnect the upload device.

Accepted hosted contributions and the figures calculated from them have no blanket short retention limit. Hosted erasure is handled by the service owner, not an in-app deletion control, and there is no hosted data export.

Backups and logs. On Google Cloud, the hosted database is backed up automatically. The service also keeps point-in-time recovery data, service logs, and copies made before changes, for example before a database update. All of these are kept only for a limited period, for recovery and operations, and are then deleted: some automatically, others by the service owner. Service logs never include upload contents. A backup is a copy, so data removed from the live database can remain in backups until they are deleted. Google Cloud's own records of administrative changes to the service follow Google's fixed retention and contain no contribution data.

Copies from the move. Working files made for the move, including the sealed export, are kept only for a limited period and then deleted by the service owner. The earlier Cloudflare D1 and R2 stores are kept frozen until the service owner decides their retirement. A deletion record is retained so that participants erased on the earlier service do not reappear: before a backup, a frozen store or a copy is restored or reused, its content-free deletion digests are applied first.

Retained delivery records. Participants erased on the earlier service before the move are not carried over as active participants or as contribution records. Minimal pseudonymous records needed for ordered delivery, such as delivery cursors and erasure receipts, can remain. They are not claimed to be erased, anonymous or unlinkable.

How privacy and erasure requests for hosted data are handled will be decided after the move to Google Cloud. Until a procedure is documented here, we make no commitment about a channel or a deadline.

For privacy, rights, or erasure requests, see the project support guidance: SUPPORT.md

A dedicated private privacy-request intake channel is not documented there. Do not post account identifiers, credentials, or private records in public issues.

Uninstall boundaries

Ordinary app or Homebrew uninstall preserves local analysis state. Uninstalling with Homebrew's --zap option removes the app's Application Support, cache, WebKit, and preference state. It does not remove the Codex folder ~/.codex or Keychain identities, and it does not remove data already contributed.

Use the explicit local identity controls for Keychain state. For hosted data, see Retention and deletion. Uninstalling or disconnecting does not erase hosted history.