# CLI Proxy API Management Center: a Web UI for the CLI Proxy API

> The repository ships only the React front end for the CLI Proxy API Management API. It gives you a browser interface for config, credentials, quotas and logs, and it forwards no traffic itself.

**router-for-me/Cli-Proxy-API-Management-Center** — This is a WebUI interface based on CLI-Proxy-API, designed to simplify configuration modifications and runtime status monitoring.

- Repository: https://github.com/router-for-me/Cli-Proxy-API-Management-Center
- Stars: 4,357 · Forks: 1,297
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/router-for-me-cli-proxy-api-management-center

## The problem: CLI Proxy API configuration lives in YAML and JSON files

The CLI Proxy API is configured through a config.yaml file, JSON credential files and a set of proxy api-keys. Editing that by hand gets awkward once you have several provider entries, model aliases and excluded model lists. This repository is the Web UI layer that talks to the CLI Proxy API Management API under /v0/management to read and update config, upload credentials and view logs. It is aimed at whoever operates the proxy: a single admin on a laptop, or a small team running one shared instance. The README is explicit that this repository is the Web UI only, that it is not a proxy, and that it does not forward traffic. Everything you see in the browser is a view onto endpoints the main program exposes. If the main program is not running, or its version is too old, the UI has nothing to talk to.

## How the UI reaches the Management API

The interface is a React 19 and TypeScript single-page app built by Vite with vite-plugin-singlefile, so the production build collapses into one dist/index.html with all assets inlined. State is held in Zustand, HTTP calls go through Axios, routing uses react-router-dom v7 in HashRouter mode, and the YAML source editor is CodeMirror 6 with @codemirror/lang-yaml and @codemirror/merge for the save diff preview. The connection model is thin: you give it an API address and a management key, and every request carries that key as an Authorization: Bearer header. The address field accepts localhost:8317, a full http or https URL, or a URL ending in /v0/management, and the UI normalizes it by stripping that suffix internally. The management key is not the same thing as the proxy api-keys you edit inside the UI. Those api-keys are what clients present to the proxy endpoints; the management key authenticates you to the management endpoints. Mixing the two up is the most common way to get a 401.

## Installing and connecting for the first time

The README recommends the bundled route. Since version 6.0.19 the Web UI ships inside the main program, so you start your CLI Proxy API service and open http://<host>:<api_port>/management.html, then enter the management key. The address is auto-detected from the current page URL, with a manual override available. If you would rather run the source, the project uses Bun as its package manager. The README gives these two commands, and the lockfile is committed, so the frozen install is reproducible:

```bash
bun install --frozen-lockfile
bun run dev
```

That starts the Vite dev server on http://localhost:5173, where you connect to your backend instance. To produce the single file instead, the README documents a build step whose output is dist/index.html, and the release workflow renames that file to management.html when bundling it into the main program:

```bash
bun install --frozen-lockfile
bun run build
```

One caveat the README states directly: opening dist/index.html over file:// can be blocked by browser CORS, so serving it through bun run preview or a static server is more reliable. Remote connections are a server-side matter. If your browser is not on localhost, the server must allow remote management, for example with allow-remote-management: true in its config. The README points at the CLI Proxy API server documentation for the full authentication rules and edge cases rather than restating them here.

## What the pages actually manage

The Dashboard shows connection status, the server version and build date, quick counts and a model availability snapshot. The Config Panel is a visual editor for common config.yaml fields plus basic settings and proxy api-keys, and it also offers raw source editing with YAML highlighting and search, with a diff preview before saving. The AI Providers page covers Gemini, Codex, Claude and Vertex key entries with base URL, headers, proxy, model aliases, excluded models and prefix, and separately handles OpenAI-compatible providers with multiple API keys, custom headers, model alias import from /v1/models and an optional browser-side chat/completions test. Auth Files lets you upload, download and delete JSON credentials with filtering, search and pagination, and it shows runtime-only indicators. OAuth starts device or OAuth flows for Codex, Anthropic/Claude, Antigravity, Kimi and xAI/Grok, polls status, and accepts callback URLs or the codes those providers display. Quota Management tracks limits and usage per provider, and Logs tails output with incremental polling, auto-refresh, search, a toggle to hide management traffic, and download of request error log files. The System page carries quick links, an update check, a request logging toggle, local login data cleanup and a grouped /v1/models fetch that requires at least one proxy API key.

## Version coupling and the features that silently disappear

The sharpest limitation is the version floor. The README states a minimum required version of 7.2.147, with the latest recommended. Below that, or against a build where an endpoint is disabled or absent, parts of the UI report themselves as unsupported rather than failing loudly. The README names the usual suspects: model lists per auth file, excluded models, and logs. That is a design choice worth noticing. A page that renders but cannot do anything is easy to mistake for a bug in the Web UI when the real cause is the backend. The Logs navigation item is a related case: it only appears when file logging is enabled in Basic Settings, so a missing Logs page is a configuration state, not a rendering fault. There is also a second floor underneath the first. The bundled route only exists from CLI Proxy API version 6.0.19 onward, when the Web UI started shipping with the main program, so on older builds you are running the dev server or a self-hosted build against a management API that may not have the endpoints you want.

## The OpenAI provider test can fail for reasons that are not the server

The optional chat/completions test on the OpenAI-compatible provider page runs in the browser. Its result depends on the provider endpoint's network reachability and CORS policy from your machine, not on whether the proxy server can reach that provider. The README says this plainly: a failure here does not always mean the server cannot reach it. Treat the test as a browser-side diagnostic and verify from the server side before you change provider configuration because of a red result. The same caution applies to remote access generally. The README advises using a dedicated browser profile or device for management and evaluating the exposure surface before enabling remote management, and it notes that repeated authentication failures can lead the server to temporarily block remote IPs. That last behavior is server-side, but it shapes how you should test credentials: a burst of wrong management keys from one address can lock that address out for a while.

## Where the management key is stored, and what the MIT licence covers

The management key is kept in browser localStorage in an obfuscation format the README writes as enc::v1::..., described as lightweight and intended to avoid plaintext storage. The README itself says to treat it as sensitive. Obfuscation on the client is not a secret store: anyone with access to that browser profile can recover the value, which is why the dedicated-profile advice exists. The System page includes a local login data cleanup action for clearing it. On licensing, the repository is MIT, which is permissive and imposes no copyleft obligation on the UI code. That says nothing about the main CLI Proxy API project, which is a separate repository with its own licence, and nothing about the terms of the upstream providers you configure through the UI. Those are separate questions, and this article is not legal advice. Maintenance is visible in the release history: v1.24.2 was tagged on 2026-09-22, two days after v1.24.1, with v1.24.0 before it on 2026-09-18. The repository is not archived, and the last push was on 2026-09-22. The upgrade cost for the UI itself is low, since the bundled route means a new main program release carries the new management.html. The real upgrade risk sits on the server side, where a newer UI may expect endpoints an older backend does not expose.

## Alternatives and the difference in approach

The most direct alternative is editing config.yaml and the JSON credential files by hand and reading the server's log output directly. That approach has no version floor, no browser, no localStorage copy of a management key, and no CORS questions, and it works against any build of the main program. What it does not give you is the save diff preview, the visual editor for nested provider entries, the OAuth device flows with status polling, or the incremental log tail with search and a hide-management-traffic toggle. The trade is between a text editor and a stateful UI that has to match the backend's endpoint surface. Choose the file-editing route if you change configuration rarely or run an older CLI Proxy API build; the Web UI only pays for itself once the endpoints it depends on are present and you are changing providers, credentials or quotas often enough that hand-editing becomes the slow part.

## Conclusion

Adopt it if you already run the CLI Proxy API and want a browser surface for config.yaml, auth files, OAuth flows and log tailing instead of editing YAML by hand. Skip it if you need a proxy or a multi-tenant control plane, because this repository is the front end only and stores the management key in localStorage. Before rolling it out, confirm your server build is at least 7.2.147, decide whether allow-remote-management should be on, and check whether file logging is enabled, since the Logs page only appears when it is.

## FAQ

### Where can I find the CLI Proxy API Management Center management key?

The Web UI does not generate it. The management key is issued by the CLI Proxy API server, and the README points to that project's server documentation and config comments for the authentication rules. Note that it is not one of the proxy api-keys you edit inside the UI.

### Is the CLI Proxy API Management Center a proxy itself?

No. The README states that this repository is the Web UI only, that it talks to the Management API under /v0/management, and that it is not a proxy and does not forward traffic.

### How do I install the CLI Proxy API Management Center?

The recommended route is the Web UI bundled in the main program: start your CLI Proxy API service and open /management.html on the API port. Alternatively, clone the repository and run the Bun install and dev or build scripts the README documents.

### Why does a page in the CLI Proxy API Management Center say a feature is unsupported?

The README attributes this to a backend that is too old or an endpoint that is disabled or absent, naming model lists per auth file, excluded models and logs as common cases. The UI requires CLI Proxy API version 7.2.147 or newer.

### Why is the Logs page missing from the CLI Proxy API Management Center?

The README says the navigation item is shown only when file logging is enabled. Turn on Logging to file in Basic Settings and the Logs page becomes available.

### Can I connect to the CLI Proxy API Management Center from another machine?

Only if the server permits it. The README says a non-localhost browser requires the server to allow remote management, for example with allow-remote-management: true, and points to the CLI Proxy API server documentation for the full authentication rules and edge cases.

## Sources

- [Issues](https://github.com/router-for-me/Cli-Proxy-API-Management-Center/issues)
- [License: MIT](https://github.com/router-for-me/Cli-Proxy-API-Management-Center/blob/main/LICENSE)
- [README](https://github.com/router-for-me/Cli-Proxy-API-Management-Center/blob/main/README.md)
- [Releases](https://github.com/router-for-me/Cli-Proxy-API-Management-Center/releases)
- [router-for-me/Cli-Proxy-API-Management-Center on GitHub](https://github.com/router-for-me/Cli-Proxy-API-Management-Center)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/router-for-me-cli-proxy-api-management-center