The missing operations layer for CLIProxyAPI
CPA Manager Plus, or CPAMP, is easy to misunderstand from the name. CPA here means CLIProxyAPI, the separate gateway that exposes multiple AI providers through compatible endpoints. CPAMP does not carry model traffic. It manages that gateway and turns its usage queue into a persistent operational record.
If CLIProxyAPI is not already part of your stack, CPAMP has nothing to manage. If it is, the panel answers questions the basic upstream interface cannot answer well over time: which models or accounts are failing, where estimated cost is accumulating, which client key produced a request, how quota windows look, and whether a credential appears healthy.
Provider management covers Gemini, Codex, Claude, Vertex, xAI, and OpenAI-compatible services. Operators can work with auth files, OAuth logins, API keys, aliases, priorities, plugins, logs, and system settings. The dashboard then connects configuration to calls, tokens, latency, failure status, cache behavior, projects, channels, accounts, and credentials. That is a practical combination for a small internal gateway team.
Lightweight and Full Mode are different products
CPAMP offers a lightweight panel that replaces CLIProxyAPI's management page on port 8317. It adds no service or database, making it the sensible option when the goal is a different interface. The upstream CLI Proxy API Management Center remains an even more conservative choice because its UI stays maintained with the gateway project.
Full Mode runs a Manager Server, normally on port 18317, alongside CPA. This is where persistent request history, cost analytics, scheduled inspection, automation, and local SQLite storage appear. The supplied Compose example runs two containers with separate persistent volumes. After launch, you retrieve a CPAMP Admin Key from the Manager Server log and enter the CPA address and Management Key during setup.
That quick start still leaves an operator with two versions, credentials, health states, networking, and storage. The README recommends CPA v7.1.39 or newer and requires at least v6.10.8 for the HTTP usage queue. Upgrade planning must consider that compatibility instead of blindly pulling both latest images.
Monitoring is the reason to install it
Full Mode persists CPA usage events in SQLite and makes them searchable by account, client API key, and realtime request views. Failure evidence is redacted, and normal APIs and JSONL exports do not expose stored raw failure bodies. History can be imported or exported as JSONL, which is useful for migration and incident work.
Cost analysis is unusually detailed. It groups calls, tokens, estimated cost, latency, and failures across model, provider, account, credential, API key, project, channel, and time. Pricing can sync from models.dev, with LiteLLM and OpenRouter fallbacks, and local overrides handle aliases or internal models. The word estimated matters: this is an operational view, not the provider's invoice.
An open request exposes a boundary. Its price rows were based on dollars per million tokens and could not represent per-image or per-video-second billing metadata. A matching pull request was active, but users should test the released behavior for non-token models. Finance reconciliation still belongs against provider billing records.
Account views add credential state, available quota signals, reset evidence, workspace state, and provider-specific health information when available. Controlled cooldowns and an account action queue can help recover from quota or credential failures. These are valuable operator tools, but provider OAuth behavior remains outside CPAMP's control. One open Windows report shows Codex browser authorization succeeding before the token exchange returned a country or region 403.
Local data brings privacy and chores
The project says it requires no account registration, contains no telemetry SDK, and keeps request history, configuration, model prices, inspection history, and automation state in local files. External requests are limited to CPA and integrations an operator configures or triggers, including OAuth, provider checks, plugin releases, and price synchronization. CPA Management Keys are encrypted before SQLite storage.
The encryption key creates a backup obligation. The latest release notes tell operators to copy usage.sqlite, usage.sqlite-wal, usage.sqlite-shm, and data.key together, and not to delete an active WAL. Lose data.key and the encrypted management keys cannot simply be recovered from the database. Large databases may also consume extra CPU, I/O, and disk while an upgrade backfills derived monitoring data.
Version 1.11.12 added better SQLite status reporting, bounded non-blocking WAL checkpoints, and rebuildable derived data for seven-day and thirty-day queries. Even so, an open report from that version describes a malformed 5.3 GB database that made the container exit before binding its HTTP port, producing an endless restart loop. The report concerns one installation and suspected damage in derived tables, but it is enough reason to monitor database checks, use appropriate storage, and rehearse restore procedures.
Access control has another boundary. An open request explains that assigning a subscription account exclusively to selected client API keys cannot be enforced by the panel alone because routing happens in CLIProxyAPI. Existing model-prefix routing provides only soft separation. Do not mistake a management view for tenant isolation. Likewise, put the panel behind your own firewall, private network, or authenticated reverse proxy rather than waiting for dashboard-level IP blocking.
Active, focused, and still young
CPA Manager Plus had about 2,600 stars and 41 open issues and pull requests on August 16, 2026. The repository was pushed August 15, release v1.11.12 arrived August 7, and issues and pull requests were active through August 16. That is strong momentum. The MIT license, native packages, container images, amd64 and arm64 support, and detailed English and Chinese documentation all lower adoption risk.
The project is moving quickly enough that production users should pin releases and read upgrade notes. Its current rough edges involve meaningful areas such as storage recovery, provider authentication, and access policy, not merely styling. Still, its scope is disciplined: it observes and manages CPA instead of pretending to replace it. For teams committed to CLIProxyAPI, that focus makes CPAMP worth running. For everyone else, a gateway-native dashboard or general observability platform is the cleaner purchase.