Privacy and network behavior

• OpenCode data is read locally from SQLite in read-only mode.
• The local-model journal (--record-ollama, --record-usage, --record-event) stores usage metadata, not prompt or response content. --record-event also stores the project path and session id, when the adapter sends them.
• Routing events contain only the JSON fields supplied by the caller.
• An LLM agent you point at the tool (--summary-json, the Claude Code skill) reads token counts, model names, costs, project paths and session ids. Those travel to the model provider that agent runs on, as anything in its context does — that is your agent’s data flow, not this tool’s, which still transmits nothing. Nothing from your prompts or transcripts is in any export.
• Prompts, completions, API keys, credentials, and interaction content are not collected.
• Claude Code session transcripts contain source code and secrets; only the usage block of each line is parsed. A test plants a fake credential in a transcript and fails if it reaches a usage record.
• ~/.claude.json is read to decide billing — only whether oauthAccount is present and its userRateLimitTier / organizationRateLimitTier strings — and for the cached rate-limit windows under cachedUsageUtilization, as the Subscription limits section itemises. The file also holds the account’s email, name, organisation, and per-project prompt history; none of that is retained or logged, and the parsed document is dropped at once. .credentials.json and settings.json are never read.
• --statusline reads Claude Code’s statusline payload from stdin, and from it only the three rate_limits windows’ used_percentage and resets_at. The session id, transcript path, working directory, model and session cost in the same payload are never deserialised. It writes one file in the data directory, statusline-limits.json, holding those figures and the time they arrived, and nothing else. The environment is checked only for the presence of ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, CLAUDE_CODE_USE_BEDROCK, and CLAUDE_CODE_USE_VERTEX; their values are not read.
• Copilot’s CLI store and session logs contain prompts, completions and tool arguments in their turns table and user.message / assistant.message records; only the assistant_usage_events columns and session.shutdown aggregates are parsed, under the same planted-credential test as Claude Code.
• Cursor’s state.vscdb is never opened. See Why there is no Cursor collector.
• Codex rollouts contain prompts, tool-call arguments and outputs, and reasoning summaries; only session_meta, turn_context, and the token_count block (token counts, and the rate_limits windows beside them) are parsed, under the same planted-credential test as Claude Code. ~/.codex/auth.json is a credential file and is never opened; the environment is checked only for the presence of OPENAI_API_KEY and CODEX_API_KEY.
• Omarchy’s agents-panel records are read-only display data: six fields per record (id, name, updatedAt, ready, tierLabel, usageStatusText, limits). The agents’ credentials, Omarchy’s probe cache, the record’s authHelpText and token tallies are never read, no network request is made, and the reader writes nothing into the directory.
• --omarchy-record is the one write into Omarchy’s directory, and only that explicit action performs it: <id>.json (opencode by default) holding token counts, model ids, request and session counts, and budget figures — never content, never a path. Ids that would overwrite Omarchy’s own files (claude, codex, fireworks) are refused; the file is written atomically with mode 0600.
• Per-project attribution records the working directory path of each session, so ~/a/build and ~/b/build stay separate projects. The dashboard shows only the shortest name that distinguishes them, but --json and --csv export the full path — worth knowing before pasting an export into a ticket.
• Normal dashboard and export operation does not require a network request, and nothing is written outside the tool’s own data directory unless --omarchy-record is run.
• --refresh-pricing, --refresh-zen, and an enabled zen_pricing background collector make outbound requests to OpenCode/Zen endpoints.
• Two commands ask GitHub for the latest release tag, and nothing else does: --check-update, whose only job is to ask and cache, and --doctor when [update] check = true. Off by default, never automatic, and never on the dashboard’s refresh path. It is a plain GET of a public endpoint: no usage data, no identifiers, no query parameters. The User-Agent names the tool and its version because GitHub’s API requires one.
• That answer is cached in the tool’s own data directory, and the dashboard reads it once at startup to show a newer release in its header. The cache is what keeps the header offline: it redraws several times a second and never makes a request or reads a clock. Only those two commands write it, so with neither run the header stays silent — except for an answer an earlier run already left, which --doctor discloses.
• A recurring check is yours to schedule, not the dashboard’s to make: contrib/systemd/user/ai-usage-update.timer runs --check-update daily, and any other scheduler can run the same command. The dashboard process itself never makes the request, whatever the config says.
• Reporting how this copy was installed and how to upgrade it needs no network at all. --doctor reads it off the running binary’s own path, so it is always on and works offline.

Default local storage paths (when the corresponding XDG variable is unset):

Everything under ~/.local/share/ai-usage-tui/ is created readable and writable by you alone (0600), the journal’s SQLite side files and the diagnostic log included. A file that is already there keeps the permissions it has: a journal made by an earlier release stays as wide as it was, --doctor says so, and chmod 600 is yours to run.