Proxima: an Electron desktop gateway that puts browser AI sessions behind one MCP endpoint

The problem is API cost, and the workaround is a browser session

The origin story in the README is specific rather than ideological. In late 2025 the author was hitting two problems with AI coding tools: models built on stale training data guessing wrong and damaging codebases, and API calls that produced mediocre answers while running up a bill per prompt. MCP setups had not fixed either.

The idea that produced Proxima was to turn actual web-based models, ChatGPT, Gemini, Claude and Perplexity, into local MCP servers by routing queries through logged-in browser accounts. In the README's own framing, the point is reaching frontier models without an API bill.

The listed pain points are a fair summary of who this is for: subscription fatigue from stacking several AI subscriptions, credits draining when an editor extension queries raw endpoints, and the fragmentation of switching between browser windows, terminals and editor panels.

Session routing versus bringing your own key

The README's table of contents names two routing modes, and the difference between them is the single most important thing to understand before you install anything.

Session routing is the default. It drives the free, logged-in browser session. Bring Your Own Key routing is the alternative: direct API key support for ChatGPT, Claude, Gemini, Perplexity, DeepSeek and any OpenAI-compatible endpoint. The v5.0.0 notes add that BYOK uses native OS keychain encryption through SafeStorage, offers multi-model selection and includes connection testing.

So the project supports both the thing its origin story is about and the conventional approach, and the second one is the one with none of the ambiguity attached. If you have an API budget and a need for predictable billing, BYOK is the mode to start in.

Session routing also implies something the README does not spell out. Automating a logged-in web account is not the same as calling a documented API, and whether that is permitted is governed by each provider's own terms. The repository does not discuss provider terms of service anywhere, so that question is yours to answer before you point session routing at an account that matters to you.

Forty MCP tools, an OpenAI-compatible API and a WebSocket

The surface area is large and the transport options are conventional. Proxima listens on `127.0.0.1` and acts as a single standard local endpoint for multiple providers and offline engines, translating protocols and handling session routing in the background.

The REST layer arrived in v3.0.0 as `POST localhost:3210/v1/chat/completions` in an OpenAI-compatible format, which means an existing OpenAI client can point at Proxima with a base URL change. v4.1.0 added a WebSocket at `ws://localhost:3210/ws` for bidirectional streaming with status updates and keepalive, and a CLI with `proxima ask`, `proxima fix` and `proxima debate` subcommands, supporting pipe input, file context and JSON output.

The MCP side is where the bulk of the work went. v4.1.0 alone added 15 tools including `chain_query`, `solve`, `debate`, `security_audit`, `verify`, `fix_error`, `build_architecture`, `write_tests`, `convert_code` and `explain_error`. The README's table of contents puts the total at 40, grouped into core orchestration tools and a wider tool catalog.

There are also Python and JavaScript SDKs. v3.0.0 describes them as drop-in files with no pip install and no npm install, and the tree confirms a `sdk/` directory alongside `docs/`, which holds an OpenAPI document that the Electron build packages explicitly.

The Python agent is a separate subsystem, not a module

GitHub reports JavaScript as the primary language, but v5.0.0 introduced what the notes call a standalone local Python platform, and the tree has a `proxima-agent/` directory sitting beside `electron/`, `src/`, `cli/` and `sdk/`.

Its capabilities are specific: browser automation through the Chrome DevTools Protocol, code execution in sandboxed workers, desktop commands and management of local environments. There is an interactive terminal console called `proxima-agent` for running, monitoring and switching models and checking logs.

Two safety mechanisms are named in the README's table of contents and worth looking for when you read it: a section on gated execution safety, and the existence of a Sponsor Wall. Neither is explained in what the README covers about architecture, so what the gate covers and what the wall restricts are not things you can learn without installing.

The v5.0.0 notes also describe the MCP layer being re-architected onto the official SDK with Zod schema validation, task-aware smart routing using EMA latency weighting, ONNX semantic memory vector lookup, a Context7 live documentation helper, and a SQLite-backed token and transaction cost auditor keeping a local ledger across all models. The cost ledger is the feature to look for first if you are worried about spend.

Three different licence statements, none of them MIT

Here is a contradiction you can resolve in about a minute. The repository's licence field reports no recognised licence, which the metadata records as NOASSERTION. The README badge reads License: Non-Commercial and links to a `LICENSE` file. The `package.json` says `SEE LICENSE IN LICENSE`.

Those three can all be true at once, and the likely resolution is that the LICENSE file contains a non-commercial terms document that GitHub's detector does not recognise, since almost no standard OSI identifier matches non-commercial use. But that is an inference. If you need to know whether you may use Proxima in a commercial setting, open the LICENSE file and read it, because none of the machine-readable signals will tell you.

The one clear negative is also the useful one: whatever the terms are, this is not MIT, and the README's own framing of a personal utility shared with other developers suggests the terms were written for individual use. The tree does contain both `LICENSE` and a `SECURITY.md`, so the question has an answer somewhere in the repository.

What the README does not cover, and where to look instead

The README on the repository page is a long page with a table of contents, and the sections after the interface preview, where installation and architecture should be, are not part of it. Everything after that point, Quick Start, Architecture, the tool catalog, Security and Privacy, Testing and Contributing, is announced by the table of contents but not written in the file.

What you can read is the problem statement, the routing modes by name, the agent capabilities, the state and memory design, and a set of interface screenshots. What you get from the release notes is the substantive detail: port 3210, the WebSocket path, the tool names, the SDK behaviour, the keychain integration.

The npm surface, from `package.json`, is short and conventional. The entry points that matter are the MCP server, the CLI and the Electron start:

npm run mcp
npm run cli
npm start

`package.json` also shows that the Electron main process is `electron/main-v2.cjs`, that a `prestart` step runs `scripts/ensure-deps.mjs`, that builds target Windows, macOS and Linux through electron-builder, and that tests run on Node's built-in test runner with `--experimental-vm-modules`. The package description states that the MCP server requires localhost network access for AI coding tools, which is a reasonable thing for it to declare explicitly.

Editorial conclusion

Proxima is a well-built answer to a specific problem: you want one address that every coding tool can talk to, whether the model behind it is a browser session or an API key. The routing modes, the 40 MCP tools, the OpenAI-compatible endpoint on port 3210 and the SQLite cost ledger are all real, and the v5.0.0 release notes describe concrete engineering rather than aspirations. Two things to settle first, because neither is answered in the repository. The licence is stated three different ways, so read the LICENSE file rather than the badge. And the session routing mode works by driving logged-in browser accounts instead of an API, which means whether your use complies with each provider's terms is your question to answer, not the project's. Start in BYOK mode if you need a defensible setup, and use session routing only where you have already decided that is acceptable.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Zen4-bit/Proxima on GitHub