yalethom.as/txtop

Unofficial integrations

txtop supports useful data sources that are not stable provider APIs. Local coding-agent logs and credential-backed subscription limits have different risks, defaults, and support promises from provider API polling.

Support levels

Data source Support level Default
Documented provider APIs and telemetry Normal support Enabled when configured
Local Codex, Claude Code, and Gemini CLI logs Best-effort compatibility Disabled until subscription scanning is enabled
Codex and Claude Code live-limit requests Experimental Disabled

Local log scanning is passive and read-only. It can stop finding data when a client changes its file location or event format. The resulting totals are personal monitoring data, not an authoritative billing record.

Live limits actively reuse credentials stored by Codex or Claude Code and call undocumented endpoints or request patterns. They may break without notice, may be throttled, and may violate provider terms of service. Enable them only after deciding that the current value is worth that risk.

What txtop promises

Unofficial data can still be wrong while looking plausible. Upstream semantic changes are harder to detect than invalid JSON or an HTTP error, so compare important totals with the provider’s own billing or usage view.

Choose the lower-risk path

For local history without network requests, follow track local coding-agent usage and leave auth_requests_enabled = false.

For current 5-hour and 7-day subscription windows, read enable live subscription limits. That guide shows every gate and how to turn the requests off without losing local history.

For supported organization usage and reported cost, prefer provider APIs. For coding agents that publish documented telemetry, OpenTelemetry ingest can be a more stable source than log parsing, but it does not supply live subscription quota state.