LinJun turns a local proxy for AI coding agents into a desktop control panel

A management console for a proxy you also have to run

LinJun is a native desktop application for managing CLIProxyAPI, described in the project documentation as a local proxy server that powers your AI coding agents. The application helps you manage multiple AI accounts, track quotas and configure CLI tools in one place across macOS, Windows and Linux.

The dependency structure is worth stating first, because it defines what LinJun is. LinJun is not the proxy. The proxy is CLIProxyAPI, a separate project under the router-for-me organisation, and the LinJun documentation links it directly. What LinJun is is the control surface around that binary: it starts it, watches it, and gives it a user interface.

The stated scope is described in the README as cross-platform AI proxy management for Claude, Gemini, Codex, Qwen, iFlow, Antigravity and more. The feature list covers provider connections, quota and model visibility, provider-aware model filtering, a live dashboard of request traffic and token usage, smart routing with round robin and fill first failover, API key management for the local proxy, one-click agent configuration, system tray integration, and English and Simplified Chinese support.

The project is written in TypeScript with Electron, React and electron-vite, it is MIT licensed, the last push was on 2026-08-19, and the version in the package metadata is 1.0.7-beta.1, with a stable 1.0.7 released on 2026-04-24.

OAuth for the big names, API keys for the rest

The provider table is the most informative part of the documentation, because it makes the authentication model explicit.

Claude Code, Gemini CLI, OpenAI Codex, Qwen Code and iFlow all authenticate with OAuth. Antigravity uses OAuth through Google. A custom provider and AmpCode use an API key. That split is not cosmetic: the OAuth entries are the ones where LinJun is brokering a login on your behalf and holding a token that has to be refreshed, and the API key entries are the ones where you paste a credential and nothing else happens.

The Antigravity path has a specific requirement that shows up in the environment file. The .env.example carries GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET, with a comment that these are the Google OAuth credentials for the Antigravity service and are used to refresh OAuth tokens. The same file also holds GH_TOKEN, the GitHub token for electron-builder auto-publishing, with a note that it needs the repo scope.

The quota side is where the app earns its keep. You can track usage per account, open View All Models to browse the provider-scoped model catalog, and the model list in the quota view is filtered by provider context, so the Codex view shows Codex models and the Claude view shows Claude models. That filtering is the small detail that makes a multi-account setup usable rather than confusing.

Detecting CLI tools and rewriting their configuration

The one-click agent configuration is the feature that decides whether LinJun is worth installing.

The project lists the compatible CLI agents it can automatically configure to use the centralised proxy: Claude Code, Codex CLI, Gemini CLI, OpenCode, Amp CLI, Droid CLI and iFlow CLI. The workflow in the documentation is short. Go to the Agents tab, select a detected agent, and configure it to use the local proxy. The detection is automatic, and the utilities directory of the source tree is where CLI detection and storage live.

Routing is the other half of the control panel. The settings include a routing strategy with two options, Round Robin and Fill First, which the feature list describes as failover strategies, and a port setting that changes the proxy listening port, defaulting to 8310. There is also an auto-start option that launches the proxy when the application starts, and notifications you can toggle for quota warnings.

The system tray integration is the piece that makes this a desktop tool rather than a settings dialog, since it gives status access from the menu bar without opening a window.

The workflow the documentation describes overall is four steps. Launch LinJun and click Start to initialise the local proxy server. Then in the Providers tab, select a provider and authenticate via OAuth or enter an API key. Then in the Agents tab, select a detected agent and configure it to use the local proxy. Then read the results in the Dashboard, the Quota view and the Logs view.

Downloading a build or running it from source

There are two paths, and the packaged route is the simple one.

Releases are published on GitHub, with a different artefact per platform: an arm64 dmg for macOS on Apple Silicon, an x64 dmg for Intel Macs, an x64 exe for Windows, and an AppImage or a deb for Linux.

Building from source needs Node.js 18 or newer, Bun, which the documentation recommends, or npm, and Git. The sequence is:

# Clone the repository
git clone https://github.com/wangdabaoqq/LinJun.git
cd LinJun

# Install dependencies
bun install

# Download CLIProxyAPI binary
bun run download:binary

# Start development server
bun dev

The download:binary step is not optional in practice, because the proxy is a separate program and LinJun does not vendor it. The script behind it is download:binary in the package metadata, which points at a TypeScript script in scripts/.

Packaging is the same shape, with one script per platform family:

bun run build:mac      # macOS (dmg, zip)
bun run build:win      # Windows (nsis)
bun run build:linux    # Linux (AppImage, deb)
bun run build:all      # All platforms

Each of those runs an electron-vite build and then electron-builder for the target, and there are matching release scripts that add the publish flag.

Electron main, a preload bridge and a React renderer

The architecture section of the README is a directory tree, and it explains the design decisions without a paragraph of prose.

LinJun/
├── src/
│   ├── main/                    # Electron main process
│   │   ├── index.ts            # App entry point
│   │   ├── tray.ts             # System tray integration
│   │   ├── proxy/              # CLIProxyAPI management
│   │   │   ├── manager.ts      # Process lifecycle
│   │   │   └── api.ts          # Management API client
│   │   ├── ipc/                # IPC handlers
│   │   ├── quota/              # Provider quota services
│   │   ├── logging/            # Request logging
│   │   └── utils/              # CLI detection, storage
│   ├── preload/                # Context bridge
│   └── renderer/               # React frontend

The proxy directory is the heart of it. manager.ts is the process lifecycle, so the desktop app owns the proxy process, starts it and stops it. api.ts is a client for the proxy's own management API, which means LinJun does not reimplement proxy behaviour, it calls it.

The renderer side is a React application with components, Zustand stores and custom hooks, and the preload layer is a context bridge, which is the standard way to keep the renderer from reaching Node APIs directly. The IPC handlers in main are the seam between the two.

On the dependency side, the choices are legible: @tanstack/react-virtual for the virtualised log table, Radix primitives for popovers and selects, cmdk for a command palette, electron-log and electron-store for logging and persistent settings, and lucide-react and @lobehub/icons for the icon set.

Keeping the logs page usable with a lot of traffic

Two performance decisions are called out in the feature list, and both are about the same thing, which is data volume in a desktop interface that polls a running server.

The first is the virtualised log table. Rendering every request log as a row in a table is fine for a demo and unusable in production, so the table virtualises, which means only the visible window of rows is in the DOM. The second is incremental polling, so the Logs page refreshes by asking for what changed rather than refetching everything, and the documentation says the combination keeps the page responsive for large datasets.

The same consideration shows up in the dashboard, which reports request traffic, token usage and success rates. Those are aggregates, so the cost of computing them is on the proxy side, and the app's job is to display them without the interface becoming the bottleneck.

The trade-off is that a virtualised table changes what a user can do with the data. Select-all across a million rows, or a find in page that spans rows you cannot see, behave differently when the rows are not in the DOM. The documentation does not describe how selection or export works across the full set, so that is worth checking on your own data rather than assuming the desktop app does what a web table does.

Two lockfiles, a beta line and a proxy you did not write

The maintenance and packaging picture has a few rough edges that a user should know about.

The repository carries both bun.lock and pnpm-lock.yaml, and the scripts are written around Bun, with a download:binary script that runs ts-node rather than the runtime itself. The documentation lists Bun as recommended with npm as an alternative, and the fact that both lockfiles exist suggests the two paths have drifted.

The release history is mostly betas. The recent tags are v1.0.7-beta.1 from 2026-06-14, v1.0.7 from 2026-04-24 and v1.0.6-beta.16 from 2026-04-20, so the 1.0.6 line went through sixteen betas before 1.0.7. The last push was on 2026-08-19, and the project has a site of its own at linjun-site.940703.xyz, with a Chinese README alongside the English one.

The structural point is the last one. LinJun is a front end for a binary it downloads, so the behaviour you actually get depends on two projects and two versions. The download:binary script pulls the proxy at build time, which means the proxy version is not pinned by LinJun's own version numbers, and an update to the proxy changes what the interface is talking to. For a tool that holds your provider credentials and writes to the configuration of your coding tools, that is the part to understand before you trust it with a machine you care about.

The licence is MIT, and the repository also carries a CHANGELOG.md, an AGENTS.md, a CLAUDE.md, an ESLint configuration, Prettier, Tailwind, a components.json and a vitest configuration, with lint, format, typecheck and test scripts in the package metadata.

Editorial conclusion

LinJun suits a developer who juggles several coding agent accounts and wants one place to see quota, route requests and reconfigure CLI tools, and it is the wrong choice for someone who only needs one provider on one machine, since a single account and a single CLI need none of this. Before adopting it, check which agents it detects on your system, because the automatic configuration writes to the configuration of the tools it finds, and note that the OAuth path stores provider credentials in the local proxy it manages rather than in your editor.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wangdabaoqq/LinJun on GitHub