Tokrate clients
npm CLI
The dependency-free tokrate npm CLI provides native setup and diagnostics.
Run npx tokrate@latest connect for guided native desktop setup or installation
through the existing verified Debian headless installer.
status and doctor provide local diagnostics. Installing the npm
package alone does not start monitoring or enable sharing; the existing native
consent flow and saved OFF preference still apply. Node.js 22+ is required.
See the CLI usage, platform limits and publishing instructions.
Native clients
For Debian servers without a desktop, see the headless Linux client: shared Rust monitoring core, first-run sharing choice, JSON CLI status and systemd services with encrypted signing credentials. This is separate from the Linux desktop alpha and ships native amd64/arm64 release packages. From 0.1.28 it has independent daily update checks, check-update, and an explicit update command (also available with U in the terminal monitor).
Tokrate has a native macOS menu-bar companion and a shared Windows/Linux tray client. The 0.1.22 clients add optional request-outcome counts for Claude Code, Codex, OpenCode, and Kimi Code: successful requests and clearly classified provider overloads or server errors, grouped by model and five-minute period. Error text is inspected in memory and discarded; failures that may come from the user's own limits, request, or connection are excluded. From 0.1.23, when sharing is on, relevant aggregate provider-error alerts from other contributors appear beside the user's own recent provider errors. Alerts require three contributors, or one during early-data mode, and do not establish provider health. Sharing still requires an affirmative choice; “Only for local use” keeps it off, and saved OFF remains OFF. Automatic software update checks have a separate switch and work with community sharing OFF. From 0.1.28 this also includes Linux desktop .deb and headless clients; installing an update remains a separate action. Windows/Linux remain alpha while hands-on desktop acceptance is pending; see GitHub Releases. Prompts, responses, code, and raw error messages are never retained in measurement history.
Tokrate measures speed, not your conversations: it reads local session logs to time each answer, and if you opt in it uploads only documented numeric measurements and request-outcome counts, never prompts, responses, code, file paths, or error messages.
Click the menu-bar icon to open a compact popover immediately: the live response speed on a gauge (output tokens per second while the model is responding, with tools and your own time excluded; the median of the model's last five responses in the last ten minutes) with its change against your own 24-hour response-speed median, a 24 h / 7 d trend, a short list of your models, and a community line when sharing is on. One model picker in the header selects the model, or Compare all models; coding-tool and provider filters live in the same menu. Period comparisons, the personal speed signal, community details and definitions sit under Details. The gear menu opens Settings (General, Sharing, Sources, Updates), the full history window with the same gauge and chart plus the latest 500 per-turn rows, and pause/resume. First launch opens a three-step welcome (detected sources, the sharing choice with a sample of exactly what is sent, where to find Tokrate). The dashboard separates coding tool, inference provider, model, reasoning effort and measurement definition. Response speed is the primary metric for Codex and Claude Code (Grok Build does not expose per-response timing and shows its work-turn speed instead); turn speed stays as a secondary metric: Codex uses completed-turn speed, Claude Code transcript-observed turn speed (subagent turns separately), and Grok Build work-turn speed including nested agent output. First-token time is currently available only when Codex reports it. These are not streaming generation rates or answer-quality scores.
Privacy: performance statistics only
No prompts, responses, code, file paths, names or account details are uploaded. The client includes no advertising or behavioral analytics SDKs and sends no separate usage-tracking events. Only the documented performance measurements are shared; switching sharing off stops its community network requests.
A random identity in the operating system’s credential store links reports from this installation (macOS Keychain, Windows Credential Manager or Linux Secret Service). The backend retains a hash of its public key and first/last reporting times to count reporting installations and limit duplicate influence. It does not know about installations that never report. This is pseudonymous, not a claim of perfect anonymity: infrastructure receives your IP to serve requests, and the stable key can link your contributions. Server samples expire after 30 days; the minimal installation registry remains for lifetime reporting counts, and backups may retain data longer.
The public board normally requires 10 contributors and 50 eligible turns. During launch, labelled Early data may show aggregates from just one reporting installation and one eligible turn. Contributor keys are never public; small-cohort numbers can still reflect a single installation. Slowdown alerts retain the stronger evidence gates.
Check it yourself—or ask your AI agent to inspect the code :) Start with the upload allowlist, network transport, and sharing lifecycle. The clients are MIT licensed; the website backend is proprietary. See the service privacy page for server retention and infrastructure details.
T3 Code compatibility (0.1.25)
T3 Code appears as T3 Code (t3-code, chip T3) in local history, live values, tool selections and community reports. Its official blue accent is #319CFC (from oklch(.68 .17 250) on t3.codes). The model/provider and underlying runtime parser, metric definition and runtime version remain separate, so Codex first-token timing and each runtime's measurement limits stay intact.
- Codex: read the normal
~/.codex/sessions rollouts; exact T3 originators identify T3-originated sessions.
- Claude Code: read the configured Claude projects directory. SDK entrypoints alone do not identify T3: the metadata index extracts strong native session references and matching turn intervals from T3's state database. Other SDK use and turns outside those intervals remain Claude Code.
- Antigravity: read compatible conversation databases in
~/.t3/userdata/providers/antigravity/<profile hash>/antigravity-acp/conversations, alongside the native stores. Default T3 paths can be changed in Sources. A custom native Antigravity source confines that reader to the selected source.
T3's root defaults to ~/.t3/userdata; only the known state database's native-reference/time columns and the validated Antigravity conversation stores are read. Profile discovery skips symlinks and is bounded to 1,024 entries/128 profiles. Metadata attribution is bounded to 20,000 recent turn intervals; missing or ambiguous evidence stays unclassified as T3. Raw titles, messages, provider debug logs, credentials and settings are never measurement fields. The idle-WAL fallback uses a capped, checked memory copy, never a raw database artifact or source-file modification; uncertainty defers the read. It is observational capture, not a SQLite-atomic snapshot guarantee.
Native record IDs and delegation links are preserved. Upgrades replay local history under the new attribution revision without sending pre-launch historical samples as new contributions. Already uploaded data is not relabeled. T3 Codex and Claude Code report classified request outcomes; T3 Antigravity does not. Sharing OFF remains OFF. Other T3 runtimes are not claimed as supported by this integration.
Software updates (from 0.1.10)
Mac uses Sparkle; Windows NSIS and Linux AppImage use Tauri's signed updater. Linux .deb installations link to the download page for package-manager installation. Automatic checks have their own switch, on by default. Check for Updates checks immediately; installation requires your action. Sharing OFF does not disable software update checks. Checks contact tokrate.dev, and package downloads contact GitHub; they send no contribution key, measurements or agent content. Since 0.1.20 both clients accept a package only from this repository's GitHub release assets. Update requests follow ordinary HTTP redirects (GitHub serves release assets from its own download servers), so the host that answers can differ from the one named; a package is installed only if its signature matches the key built into the app. Sparkle system-profile reporting is disabled. Disable automatic checks as well as sharing if you want neither background request type.
Mac stable and Windows/Linux alpha feeds are separate. Public verification keys are embedded in the clients; private release keys are never shipped. Update signatures do not replace macOS notarization or Windows Authenticode. Existing 0.1.9 installations need one manual installation of an updater-enabled release. Native CI is not proof of an installer upgrade on every desktop; Windows/Linux remain alpha.
Repository layout
macos/: shipping SwiftUI app, UI tests, packaging and signing scripts.windows/ and linux/: platform guidance for the new Tauri tray clients; no stable releases yet.desktop/: Windows/Linux Rust core, shared dashboard, native host and CI packaging (0.1.11 public alpha). See desktop setup and release gates.shared/: current Swift metric core, contribution logic, CLI and core tests. Portability beyond macOS is not yet verified.- Root
Package.swift, docs/, and LICENSE: package assembly, cross-client contract and MIT license.
Build
Requires macOS 14 or newer and Swift 6.
swift build
swift test
To stage and launch the menu bar app as a macOS bundle, run ./macos/script/build_and_run.sh. The script builds macos/dist/0.1.24-debug/Tokrate.app first, including the app icon rendered from the Tokrate mark (macos/Resources/tokrate-mark.svg, macos/script/make_app_icon.sh). The command-line client is available with swift run tokrate inspect <session.jsonl>.
Local data
The app reads ~/.codex/sessions automatically on launch, or a folder you select after pausing. Pausing stops reads. Completed-turn metrics are stored in Application Support and retained for seven days while Tokrate runs (expired turns are removed within the hour, also while monitoring is paused); after you quit or uninstall it, the history file keeps the last seven days until you delete the Tokrate folder in Application Support. See the metrics contract for fields, definitions, and privacy boundaries.
Optional community sharing
The app launches as a menu-bar utility. Click its icon for the dashboard; choose Full history… from the gear menu for the larger window and folder controls. Monitoring starts automatically on every launch. Sharing starts only after you choose “Yes, let's contribute” on the current sharing notice (version 6); contributions accepted under older notices pause until reconfirmed, while a saved OFF remains OFF. The Share with community toggle appears in both the compact dashboard and full history window and remembers your choice. Switching it on shows the notice; switching it off takes effect immediately, without a confirmation dialog. Pausing monitoring leaves already-queued sharing active; turn Share with community off to stop all community requests.
While sharing is on, the app creates or reuses a random Ed25519 identity in the macOS Keychain and sends only new completed-turn measurements to https://tokrate.dev/api/public/v1/samples. From 0.1.22 each signed request uses an envelope like { "schemaVersion": 2, "sentAt": <send time>, "samples": [ … ], "requestCounts": [ … ] }; it may contain up to 50 sample records and 50 request-count entries, with at least one item in total. Sample records retain their own schema version 1. Request counts contain only allowlisted tool/model/provider/version fields, a five-minute timestamp, and succeeded/overloaded/server-error totals; error text is never included. The public key identifies this installation pseudonymously; no account registration is required. The server sees the source IP during each connection. Community statistics and alerts are fetched only while sharing is enabled, at most every 30 seconds. Requests are signed with the installation key: X-Tokrate-Key carries the public key and X-Tokrate-Signature the signature of the body. Both clients send User-Agent: Tokrate/<app version> (for example Tokrate/0.1.24) with their community requests instead of the default, which would add the macOS CFNetwork and Darwin versions or the HTTP library's name and version.
Uploads contain model/provider (the model name exactly as the coding tool reports it when it consists of letters, digits, ., _ and - and is at most 80 characters, otherwise unknown, so a custom deployment name is shared as is; plus the inference-profile region for Claude on Amazon Bedrock), explicit allowlisted reasoning effort (or unknown), source kind, the coding-tool surface as a category (command line, desktop app, editor extension, SDK or automation, other; never the name of the app or editor it ran in), client/app/parser/metric versions, output and reasoning counts, delegated output tokens (from 0.1.16: the output tokens of subagent work a primary turn started, null for subagent records; a primary turn is uploaded once this total is final), whole-turn duration, response-speed totals (output tokens, seconds and count of the turn's qualifying responses, null when unavailable), optional Codex-reported TTFT, the turn's input token count and how many of those tokens were read from or written to the provider's prompt cache (inputTokens, cacheReadInputTokens, cacheWriteInputTokens; null when the tool does not report them), a five-minute UTC time bucket, and a random sample UUID. From 0.1.14 the server derives your continent from the connection's country at upload time (via Cloudflare); only the continent is stored, never the country or IP address, and a region is shown publicly only with at least 3 contributors. The app does not send a region. The sharing notice is at version 6: version 2 added the response-speed totals, the Bedrock region and the server-derived continent, version 3 the delegated output tokens, version 4 the surface category and the prompt-cache token counts, version 5 request outcomes, and version 6 provider throttling counts. When the notice changes, anyone who had sharing on is asked to choose again before sharing resumes; a saved OFF stays OFF. They never contain prompts, responses, code, paths, session/account IDs, or the local deduplication hash. Historical turns are never backfilled: only completions after this launch or the latest switch-on are eligible. Turning sharing off cancels the network loop, clears pending uploads, and immediately hides community statistics. Already-received samples cannot be recalled by this switch. The installation key remains in Keychain for reuse.
From 0.1.27, uploads are grouped after five-minute UTC buckets close. Each group waits one minute, then a shared random delay of up to one minute, so normally collected completed turns arrive about 1–7 minutes later. The usual 30-second delegation settle fits this grace. Late-ready turns join a later fixed slot; they never upload after an individual per-turn random timer. Completion timestamps remain rounded to five minutes; the shorter grace gives less tolerance for unusually delayed collection than the older 5–11-minute schedule. Sleep, offline collection and outstanding subagent work can take longer. Offline retries use the same memory-only queue, capped at 1,000 samples and 24 hours; quitting loses that queue. Retries retain the random sample UUID and are sent in a new envelope with a fresh sentAt. Requests use an ephemeral URL session without cookies/cache and reject redirects. Local history is retained for seven days, capped at 50,000 turns. Recent files are read incrementally outside the main actor, with bounded parser state. On macOS, FSEvents watchers on the source folders wake the poll when a session file changes, so a finished response is read within about a second; polls are at least 2 s apart, idle polls happen every 30 s, and a full folder enumeration runs only for new files and as a five-minute safety net. macOS allows at most 1 MiB per source per poll; the portable monitor shares a 1 MiB aggregate budget across its three sources. A separate cursor reads recent events first while older history catches up; up to 768 KiB is reserved for live reads, with at least 256 KiB available for historical replay. Local history contains only normalized numeric/timestamp/version/model fields and a SHA-256 deduplication pseudonym, never the raw session/turn identity.
Release packaging
./macos/script/package_app.sh release
This builds a native-architecture macos/dist/0.1.30/Tokrate.app (macOS 14+, bundle ID dev.tokrate.mac, version 0.1.30, build 31). It does not sign, notarize, publish, or launch. Release ownership must separately sign with Developer ID and hardened runtime, verify, submit and staple notarization, then archive the final bundle. ./macos/script/build_and_run.sh --verify stages a debug bundle and checks the launched process. Debug packaging refreshes its generated bundle; release packaging refuses to overwrite an existing release bundle or archive. Sign only after the final build. The Mac app embeds Sparkle for signed software updates; the metric core has no third-party dependencies.
Validation: swift test --build-system native -j 2 exercises parser timing, cumulative counts, malformed input, incremental file reading, retention, no requests/identity while sharing is off, legacy default-on settings paused until consent, persisted-off preferences, allowlisted signed bytes, five-minute buckets, no historical backfill, stable retries, polling rate limits, bounded queue expiry, and opt-out during a suspended upload. Tests use mocks and do not contact production.
To sign the already-built bundle, use ./macos/script/sign_release.sh "$DEVELOPER_ID_IDENTITY". The script applies hardened runtime and a secure timestamp, verifies the signature, and stages macos/dist/Tokrate-0.1.30-macos-arm64.zip on Apple Silicon. It signs embedded Sparkle helpers inside-out and preserves their required entitlements. Before notarization, verify the TokrateNotary profile with xcrun notarytool history --keychain-profile TokrateNotary --output-format json >/dev/null using the default user Keychain lookup outside the sandbox; avoid pinning a Keychain path, which may resolve different credential storage. To submit, wait for acceptance, staple, verify Gatekeeper, and recreate the final archive, pass TokrateNotary as the second argument. No credential value belongs in the repository. The archive hash changes after stapling; publish only the final verified archive. In an environment that blocks SwiftPM's nested sandbox, ./macos/script/package_app.sh release --disable-sandbox uses the same local build without SwiftPM's inner sandbox.
Version 0.1.1 replaces the automatically updating relative timestamp in the native menu with a static completion timestamp. This avoids recursive SwiftUI menu refreshes observed with saved turn history.
Version 0.1.2 reads recent events independently of historical replay, so large existing Codex logs cannot delay new-turn capture for hours. Both readers share local deduplication identifiers; sharing still permits only turns completed after this launch or after sharing was enabled.
Historically, version 0.1.3 started monitoring and default-on sharing. Version 0.1.11 replaces default-on sharing with affirmative consent before sharing-key access or community requests. A saved off choice prevents identity access and all community requests. If Keychain access fails, the switch retains your preference, the app reports that sharing could not start, and Retry sharing is available; local monitoring continues.
The 0.1.7 dashboard uses native adaptive materials and static blue/teal gauges, with no continuous animation or ticking date views. Choose a model/provider/Codex-version/reasoning-effort cohort to scope the latest-turn gauge, chart, summaries, history and menu-bar value together. All models lists separate comparisons without a pooled headline rate. Rolling 24 hours and 7 days show individual-turn medians and observed min/max, with separate throughput and TTFT coverage. Throughput summaries require at least 20 output tokens; missing TTFT remains unavailable. These are observations of different workloads, not a benchmark or quality score. Reasoning effort is read only from explicit Codex turn metadata; missing, invalid or conflicting values remain unknown. Each effort setting has its own comparisons and personal baseline. Fast/service mode is not captured or controlled.
Personal change signals compare the selected cohort’s last 24 hours with the preceding six days. They need 5 recent eligible turns, a last observation within 60 minutes, and 20 baseline turns across two days. A throughput decline needs at least 30%; a TTFT increase needs both 50% and one second. Sparse/stale baselines are labelled. Your workload may have changed: this does not establish provider intent. These local features work with sharing off. While sharing is on, community rows and alerts match the selected cohort and show early-data or stale context.
For offscreen UI previews, DashboardSnapshot(records:range:now:calendar:) accepts supplied TurnMetric values and a fixed date. ThroughputGaugeView(metric:compact:), TrendChartView(snapshot:range:compact:), and SummaryView(snapshot:) are presentation-only views and do not construct a history store, read logs, access Keychain, or start network requests. Include DashboardStyle.swift when compiling these components separately. Use an explicit light/dark color scheme in a SwiftUI renderer. TOKRATE_RENDER_PREVIEWS=1 swift test --filter PreviewRenderTests renders the popover, onboarding, Settings and history views (light and dark, synthetic data only) to PNGs in TOKRATE_PREVIEW_DIR.
Version 0.1.4 adds Open global stats to the dashboard and full history, opening the canonical https://tokrate.dev website in your browser even when in-app sharing is off. The gear menu includes Show speed in menu bar and (from 0.1.14) Show provider badge, both on by default and persisted. Turning the speed off leaves only the speedometer icon. From 0.1.14 the menu-bar value is the live response speed: the median of the last five responses (at least 200 output tokens each) of the model you are using within the last ten minutes, updated as responses finish; it is not a streaming-speed measurement. When no response finished recently it shows the response speed of the model's latest turn (the same value as the popover gauge), and a dash only means there is no measurement yet or monitoring is paused. Grok Build reports speed per turn, so each completed turn feeds the live value as one entry. The model is chosen automatically ("Auto (most active)", or "Auto within a coding tool") from the response stream, following the model with the most output in the last three minutes (a new leader takes over after 30 seconds), or you can pin one in the model picker; the letter badge shows the model's maker (A Anthropic, O OpenAI, X xAI, G Google, M Moonshot AI; other providers get a grey dot) and a small chip shows the coding tool (CX Codex, CC Claude Code, GB Grok Build, AG Antigravity, OC OpenCode, KC Kimi Code); both can be switched off (Show coding tool chip in Settings and the gear menu).
The 0.1.7 decision panel adds recent 15-minute observations, current and previous 24-hour comparisons with per-metric coverage, and responsiveness ordering. Percentage changes require five eligible values in each period and a nonzero previous median. Previous seven-day comparisons are unavailable with seven-day local retention. Community evidence distinguishes an insufficient baseline, stale processing, and a qualified signal; neither missing alerts nor fresh processing establishes provider health. Geographic coverage and answer quality remain unmeasured.
Claude Code and Grok Build (0.1.9 source)
Claude Code uses ~/.claude/projects or CLAUDE_CONFIG_DIR/projects. Grok Build uses ~/.grok/sessions or GROK_HOME/sessions, reading session events, usage summaries and the session summary's reasoning-effort setting only. The Windows equivalents are relative to your user profile; source folders can be configured for nonstandard or WSL installations.
Antigravity (0.1.18 source)
Antigravity (the desktop app, the IDE and the agy CLI) keeps one SQLite database per conversation under ~/.gemini/antigravity, ~/.gemini/antigravity-ide and ~/.gemini/antigravity-cli (conversations/<id>.db); the Mac app reads that data folder, which Settings > Sources can change ("Antigravity data folder"). Databases are opened read-only and only when they changed; legacy .pb conversations (encrypted) and databases of subagent trajectories are ignored, and only numeric usage, timestamps, the model id and its effort suffix are read, never prompts or responses. One finished agent run (prompt through final answer, including tools and waiting) is one turn with turn speed, and each model call is one response for response speed, including the live readout. Gemini models report the inference provider Google; the badge is a blue "G". Turns that started subagent work are shown locally but not shared yet. The rules are in the metric contract.
OpenCode (0.1.18 source)
OpenCode (the TUI, opencode run, its desktop app and IDE integrations) keeps all sessions in one SQLite database, opencode.db, in its data folder ($XDG_DATA_HOME/opencode, else ~/.local/share/opencode; Settings > Sources can change it as "OpenCode data folder"). The database is opened read-only and only when it changed; a few JSON fields of each message (role, model, provider, effort, finish state, timestamps and token counts) are extracted in SQL, and the part table with prompts, responses and tool output is never read. One user prompt through its final answer, including tool steps and waiting, is one turn with turn speed, and each model step is one response for response speed, including the live readout. Only sessions from OpenCode 1.14 on are measured, because earlier versions count reasoning tokens differently. Subagent (task tool) sessions are not turns of their own: their output is added to the turn that started them. OpenCode is multi-provider: the provider is shown as recorded (for example openrouter), but only turns with the provider Anthropic, OpenAI, Google or xAI are shared. The rules are in the metric contract.
Kimi Code (0.1.21 source)
Kimi Code (Moonshot AI's kimi CLI and the Kimi desktop app, which runs the same engine) writes one event log per agent of a session, sessions/<workspace>/<session>/agents/<agent>/wire.jsonl, in its home folder: $KIMI_CODE_HOME or ~/.kimi-code for the CLI, and kimi-desktop/daimon-share/daimon/runtime/kimi-code/home in the app's data folder for the desktop app (~/Library/Application Support on the Mac; Settings > Sources can change both, as "Kimi Code folder" and "Kimi desktop folder"). Logs are read incrementally like Claude Code transcripts, and only event types, timestamps, step finish reasons, token counts, the model, its provider type and the thinking effort are kept, never prompts, responses, tool output or paths. One user prompt through the main agent's final answer, including tool steps and waiting, is one turn with turn speed, and each model call is one response for response speed, including the live readout; a response's time includes the wait for its first token, as for every tool. Output tokens include thinking, which Kimi does not count separately. A turn with a failed, interrupted or unlogged model call produces no measurement (the desktop app logs nothing for a call that failed, for example when Kimi is over capacity), the desktop app's chat-title calls are ignored, and logs of older desktop builds (wire protocol 1.3, whose model is only an alias) are not measured. Subagents are not turns of their own: their output is added to the turn that started them. Kimi models served by Moonshot report the inference provider Moonshot AI; the badge is a violet "M". The rules are in the metric contract.
Coding tools and inference providers are separate filters. An unknown provider is intentional when local records do not establish the routing provider. Grok historical summaries without a single-model usage breakdown remain model Unknown. Claude/Grok first-token timing stays unavailable. From 0.1.12, and with parser claude-transcript-v3 from 0.1.13, Claude Code turns follow these rules: a message sent while Claude is still working continues the turn instead of restarting it (within a 30-minute gap), interrupted turns and client-generated synthetic messages produce no measurement, background notifications (user records whose origin is not a human or subagent-coordinator prompt) never start or continue a turn, a monitor that starts in the middle of a transcript skips the partial turn it joined and measures the next full one (Codex turns likewise require an observed start), and Sonnet or other subagent work under subagents/ is measured as separate "Subagent turn speed" cohorts (task prompt to final answer, including tools and waiting). Different measurement definitions keep separate histories and baselines; see the complete metric contract.
Response speed (0.1.14). Response speed measures one API response at a time: from the request that triggered it (a prompt, a tool result or a notification) to the response's last output. Claude Code uses one message.id per response; Codex one model response ending in a token-usage record. Only responses with at least 200 output tokens and a duration up to 10 minutes count, so tiny automated check-ins and stalled requests do not skew it, and reasoning tokens are included as in turn speed. Subagent runs, which looked slow as whole turns because of tool work, show their real decoding speed. From 0.1.15 Grok Build also has a response speed, but Grok records output tokens per turn rather than per response, so it is a whole-turn average: the turn's output tokens divided by the time its model calls spent generating (tool runs and permission waits excluded). Short calls are included, so it can read lower than per-response measurements from Codex and Claude Code, and turns with nested agents are not counted; see the metric contract. Live response values are kept in memory only and are never saved or shared; saved turns and uploads carry only per-turn totals. See the metric contract.
Efficiency indicator (0.1.16). The efficiency indicator is a heuristic indicator, not a benchmark: it compares the median output tokens a model spends to finish one request, reasoning and delegated subagent work included, with the median across all requests in the same period. 100 is typical; 200 means half the tokens. Subagent work (Claude Code subagents, Codex spawned child sessions) is counted for the request that started it; Grok Build's output already includes it. Background subagents still running 30 minutes after the request ends and Codex approval-review ("guardian") sessions are not counted, requests under 200 tokens are left out, and answer quality is not measured. See the metric contract.
From 0.1.13 Claude Code turns report their inference provider when the transcript shows it explicitly: Anthropic's own API, Amazon Bedrock or Google Vertex AI (identified from the response message IDs, never from the model name). Turns without clear evidence stay Unknown. Bedrock and Vertex model IDs such as us.anthropic.claude-sonnet-4-5-20250929-v1:0 or claude-sonnet-4-5@20250929 are shown as the plain Claude model name; custom Bedrock ARNs and application inference profiles stay Unknown. From 0.1.14 the inference-profile region that the plain name drops (us, eu, apac, global, jp, au, ca, us-gov, otherwise unknown) is kept as the turn's provider region and is part of its local cohort. Subagent turns are only measured for Claude Code versions that write <session>/subagents/agent-*.jsonl; older layouts that keep agent-*.jsonl directly in the project folder still measure primary turns only.
Apps opened from Finder do not see shell variables such as CLAUDE_CONFIG_DIR, GROK_HOME or KIMI_CODE_HOME. On the Mac, Settings > Sources can Choose folder… for Codex, Claude Code (projects folder), Grok Build (sessions folder), Antigravity (data folder, default ~/.gemini), OpenCode (data folder, default $XDG_DATA_HOME/opencode or ~/.local/share/opencode) and Kimi Code (CLI home, default $KIMI_CODE_HOME or ~/.kimi-code, and the desktop app's Kimi Code home) while monitoring is paused, and Reset to default returns to the default or environment-variable location. The choice is remembered across launches.
Request prompt-size collection (0.1.30 source)
The new clients collect numeric request counts and input/cache-read totals in six prompt-size ranges where logs provide complete individual request usage. Input includes cached context. Turn totals are separate; speed-qualified response counts are never a prompt-size denominator. Grok Build's aggregate ledger cannot provide this breakdown. No prompt content or raw request IDs are uploaded. Sharing notice 7 describes these additional aggregates; earlier opt-ins pause for acceptance, while saved OFF stays OFF. No historical measurements are backfilled. See the metric contract. Release assets and update feeds require the existing native packaging, signing and acceptance gates; these source changes alone do not mean 0.1.30 has been published.
