A dashboard built for one proxy
CPA Usage Keeper solves a narrow problem well. CLIProxyAPI can route model requests and expose usage information, but operators still need durable history and a way to understand which model, provider, credential, or API key is consuming resources. Keeper subscribes to CPA usage, stores it in SQLite, synchronizes CPA metadata, and serves a dedicated dashboard. The proxy is the collection point.
The resulting views are practical. Overview and analysis pages cover requests, tokens, estimated cost, cache activity, success rate, RPM, TPM, latency, models, API keys, and AI providers. Request events can be filtered and exported. Auth-file and provider screens combine usage with health and quota refresh. An API-key-scoped read-only view lets a consumer see its own usage without opening the whole administrative dashboard.
This focus is Keeper's biggest strength and hardest boundary. If all traffic already passes through CPA, installation avoids application instrumentation. If it does not, Keeper has no generic trace ingestion story. Langfuse or another application observability system fits that job better.
Setup is short, dependencies are not
The recommended path is Docker Compose. The README supplies both a CPA-plus-Keeper stack and a Keeper-only template for an existing proxy. Binaries cover Linux, macOS, and Windows, while Homebrew and systemd instructions reduce service setup. Data lives under one mounted work directory, and scheduled SQLite backups are enabled by default.
Before starting, CPA must have usage statistics enabled. Keeper needs the CPA base URL and management key, plus access to the Redis-compatible usage queue. Authentication is enabled by default and requires a login password. This is better than an open dashboard, but it remains a simple access model. The documented administrative login is one shared password, alongside scoped read-only access through CPA API keys, not an enterprise identity and role system.
Network configuration requires care. A native process listens on all interfaces unless bound to localhost. Docker users can publish port 8080 only on 127.0.0.1, or put a trusted reverse proxy in front. Keeper can serve TLS itself, though the README recommends terminating public HTTPS at nginx, Caddy, or another proxy. Forwarded client addresses are accepted only from loopback and explicitly configured proxy networks, which helps preserve login rate limiting.
Collection behavior can surprise you
Keeper is only useful when its event stream is complete. The README warns that when several usage collectors share one CPA instance, all must use subscription mode. Otherwise collection can stop or become incomplete. An open question illustrates the debugging difficulty: provider and key metadata appeared while every usage page stayed empty, even though Keeper reported a successful subscription. Metadata connectivity therefore does not prove event ingestion. Operators should generate a known test request, confirm it appears, and alert on a quiet collector rather than trusting a healthy container alone.
Historical migration is the other major gap. An open request from a CPA Manager Plus user says Keeper can start collecting new events but cannot import existing SQLite history or a CSV or JSON export. The maintainer replied that a general reconstruction and migration interface may come later but has low priority. That is an aspiration, not a scheduled feature. Switching dashboards currently means running Keeper from zero if old data cannot be retained in the prior tool.
Useful estimates, not a billing ledger
Cost analysis depends on model pricing maintained inside Keeper. The project can synchronize pricing and preserve manual overrides, but the README correctly describes the output as estimates. An open issue identifies a sharper limitation: a pricing rule can match the service tier requested by the client even when the upstream response used another tier, potentially applying the wrong multiplier. The maintainer notes that users can write rules against the response tier, which puts correctness partly on local configuration.
Token presentation has a related interpretation problem. Keeper normalizes provider-specific cache semantics into a canonical input-token value. An open request says some UI areas show that total beside cache-read and cache-write values in a way that can look duplicated, while one chart segment and its tooltip use different interpretations. Chargeback owners need documented definitions, test requests, and comparison against provider invoices before trusting a total.
Retention also shapes what the dashboard can answer. Raw request events older than 90 local calendar days move to a permanently retained cold table, but normal dashboard APIs do not query that archive. Version 1.14.4 aligned custom request-event queries and exports with this window, while higher-level usage pages retain a longer custom range. This is a reasonable SQLite tradeoff, not unlimited interactive history.
Security and project health
The most important security sentence is easy to miss: browser APIs redact key-like fields, but SQLite and its unencrypted backups contain original data. Anyone who can copy the volume may obtain more than the UI reveals. File permissions, encrypted disks, protected backup destinations, and limited host access are essential. Opting into community rankings also deserves a separate privacy decision.
The project was created on April 17, 2026, so maturity should not be inferred from its fast version number. By August 13 it had more than 1,100 stars, a same-day push, eight open issues, and seven open pull requests. Release v1.14.4 arrived on August 10, four days after v1.14.3, following frequent July releases. That pace and maintainer responses show energy, but rapid releases also argue for pinning versions and testing upgrades against a copied database.
CPA Usage Keeper is easy to recommend inside its exact niche. It gives CPA operators a detailed view with minimal integration work and clear deployment documentation. Treat it as monitoring and analysis, not financial truth. If the 90-day event window, shared-password administration, fresh-history start, and unencrypted local store fit your environment, it is a very useful companion to CLIProxyAPI.