OpenRelay: a local quota broker that puts Claude Desktop and Kiro behind one endpoint

The silo problem OpenRelay is built around

The README opens with a blunt claim: your AI subscriptions are locked in silos. Claude Pro works in Claude Desktop. Kiro quota works in Kiro. Groq is free but every tool needs manual configuration. Cursor's 500 requests run out and you stop working. That is the pain the project targets, and it is a real one for anyone who pays for more than one AI product. The intended user is an individual developer running several CLI or IDE coding agents on one workstation, not a platform team. The README frames the value as connecting quota you already own to tools you already use, and the tool list it names (Claude Code, OpenClaw, Aider, Goose, Continue, Amp) confirms the audience. If you only use one provider through one client, the project has nothing to give you.

Discovery, a single localhost port, and path-based provider routing

The mechanism is a local process that reads credentials other applications have already stored. The README says it connects to sources including Claude Desktop, Claude Code, Kiro, Windsurf, Antigravity, OpenCode, VS Code Copilot, OpenAI Codex, Gemini CLI, Rovo Dev and QClaw, and that some sources require you to log in to the original app or set an API key first. Everything then comes out of one endpoint on port 18765, which is also the web panel. Provider selection is done in the URL path rather than in a header or a config file. The README's own example sets ANTHROPIC_BASE_URL to http://localhost:18765 for the default route, and to http://localhost:18765/kiro when you want Kiro's free Claude Sonnet inside Aider. That single detail explains most of the design: the proxy speaks the Anthropic and OpenAI wire formats, so any client that lets you override a base URL can be redirected without patching the client. The README also lists 45 direct API or local endpoints (Groq, Gemini API, DeepSeek, Mistral, OpenRouter, LongCat, Qianfan, Qiniu, Anthropic API, Ollama and others) and states 58 non-virtual providers. Those counts are the project's own figures; the README does not explain how the numbers are derived.

Getting it running: binaries, quarantine flags, and one environment variable

There is no npm install and no Node runtime requirement. The README points at prebuilt executables per platform. On Windows you download openrelay-windows-x64.exe and double-click it. On macOS you download openrelay-macos, then run chmod +x openrelay-macos followed by xattr -d com.apple.quarantine openrelay-macos before ./openrelay-macos; the README states the xattr step removes the macOS gatekeeper restriction on unsigned programs, without which the binary will not open. Linux has separate x64 and ARM64 downloads, each needing chmod +x before execution. Once the process is up, the panel is at http://localhost:18765 in a browser and is bilingual. Wiring a client is one environment variable pair. The README gives ANTHROPIC_BASE_URL=http://localhost:18765 and ANTHROPIC_API_KEY=unused for macOS and Linux shells, and the PowerShell equivalents for Windows. The API key value is a placeholder because the credential comes from the discovered source, not from the client. To point a tool at a specific provider you append the provider name to the path, as in ANTHROPIC_BASE_URL=http://localhost:18765/kiro. The README also describes per-tool toggles in the web panel for Claude Code, Aider, Goose and OpenCode, with the instruction to reopen the terminal afterwards.

IDE interception is the most invasive part of the design

Beyond CLI tools, OpenRelay offers to sit in front of IDEs. The README's table lists four approaches. Cursor and Windsurf are handled through an RPC proxy described as ConnectRPC over HTTP/2, which the README says lets you use Claude, Kiro, Groq or any provider inside those editors and replace Windsurf's built-in models. VS Code Copilot goes through an Ollama BYOK bridge, using any model as the Copilot backend. Antigravity is routed through a Gemini REST proxy. This is a different risk profile from setting an environment variable in a shell. An RPC proxy means OpenRelay is parsing and rewriting editor traffic, and the README gives no protocol-level detail about what is transformed, how failures surface inside the IDE, or what happens when a provider refuses a request mid-session. The README says the proxy is started from the panel and that the IDE switches without noticing. I would treat that as a claim to verify per IDE version rather than a property of the design, because RPC surfaces change and the README does not state which editor versions were validated.

The Open Core licence split, and what it means for the MIT badge

The repository metadata says MIT, and the README's licence section confirms that the framework portion (proxy, format conversion, configuration) is MIT. But the same section puts Pro features, described as model combination and higher request-rate ceilings, under a commercial licence in COMMERCIAL-LICENSE.txt. This is an Open Core split, and the README's fifth feature, combining multiple providers into one virtual model with automatic failover across Groq, Cerebras and SambaNova, is the feature most likely to be the reason someone chooses this project. If your use case depends on that grouping and failover behaviour, the MIT licence on the repository does not cover it. Read COMMERCIAL-LICENSE.txt before designing around model groups. This is not legal advice; it is a pointer to the file that governs the feature you probably want.

Credential handling and the trust boundary you are accepting

OpenRelay reads application tokens and cookies from your machine to connect to the original providers, and stores API keys you add through it under ~/.openrelay/. The README says AI requests go from your machine directly to the chosen provider and that OpenRelay's own servers are not in the request path, that prompt content is not logged by default, and that licence and update checks may contact OpenRelay or GitHub endpoints without carrying provider credentials or conversation content. It points at src/cookie.ts as the auditable credential-handling code and at DISCLAIMER.md and PRIVACY.md for detail. The honest reading: you are handing a third-party binary the ability to read session credentials out of other applications. The README's mitigation is that the code is inspectable, which is a real mitigation and also an obligation. If you are not going to read cookie.ts, you are trusting a description rather than a mechanism. On Linux the README notes credential storage goes through secret-tool (gnome-keyring) or a file cache, so headless or minimal desktop environments will fall back to the weaker of the two.

Where OpenRelay is the wrong tool, and what to use instead

OpenRelay is a single-workstation credential broker. It is not a shared gateway: there is no mention of multi-user authentication, per-user quotas, central audit logging or a server deployment story, and the panel is bound to localhost. For a team that needs one internal endpoint with keys held server-side and usage attributed per developer, the closer comparison is LiteLLM's proxy mode, which is configured from a YAML file listing models and keys and is designed to run as a shared service with virtual keys and spend tracking. The difference in approach is structural. OpenRelay discovers credentials that already exist on the client machine and re-exposes them locally, which is why it works with consumer subscriptions that were never meant to be scripted. LiteLLM expects you to supply provider API keys to a server it controls, which is why it scales to a team but cannot turn a Claude Desktop login into an API. If your problem is that your own desktop logins are trapped in their apps, LiteLLM does not solve it. If your problem is that ten engineers need governed access to three providers, OpenRelay does not solve it. There is also a second wrong-tool case: anything unattended. A CI job or a container has no Claude Desktop, no Kiro session and no keyring, so the discovery step has nothing to find.

Release cadence and the maintenance bill

The release history shows v0.10.62 in early July 2026, v0.10.63 in late July, and v0.10.64 on 12 August 2026, with the repository's last push on the same day as the newest release. That is roughly a release every few weeks at the 0.10.x stage, which tells you two things. First, the project is active. Second, it has not reached 1.0, and the version numbers suggest the interfaces are still moving. For a tool whose entire job is to track other vendors' authentication flows and wire formats, that cadence is not optional: when a provider changes how it stores a token or how it shapes a response, the proxy has to follow. The practical cost is that you should expect to update the binary rather than pin it for a year, and that a pinned old build will eventually fail against a provider that changed underneath it. The README does not describe an upgrade path, a migration process for ~/.openrelay/ configuration, or a compatibility matrix by provider, so plan on re-downloading from the releases page and re-checking your provider routes after each jump.

Editorial conclusion

Adopt OpenRelay if you already hold several provider accounts and want Claude Code or Aider pointed at a different quota without editing shell profiles by hand, and if you are comfortable running an unsigned binary that reads application cookies from your machine. Do not adopt it for a shared team gateway or a CI runner: it is a desktop-oriented local proxy, the README states it has no Linux build of Claude Desktop or Antigravity, and the Pro model-combination feature sits under a commercial licence rather than MIT. Verify three things first: that your platform's credential path works (secret-tool or the file cache on Linux), that the /kiro style path routing still matches the provider names in your build, and that the port 18765 default does not collide with anything already bound on your machine.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. romgX/openrelay on GitHub