LLxprt Code: A Terminal Coding Agent That Refuses to Pick One LLM Provider
An open-source multi-provider AI assisted CLI development tool. Use whatever LLM you want to code in your terminal.
At a glance
- What is it?
- LLxprt Code is an Apache-2.0 TypeScript CLI that routes coding requests to Anthropic, Gemini, OpenAI, Kimi, or any OpenAI-compatible endpoint, including local models. The interesting part is not the feature list but the launcher, which resolves its own bundled Bun runtime and fails with a specific exit code when it cannot.
- Who is it for?
- Adopt LLxprt Code if you already pay for Claude Pro, ChatGPT Plus, or a Kimi subscription and want those entitlements reachable from a terminal without a second billing relationship, or if you need to point a coding agent at LM Studio or llama.cpp for local inference.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The provider lock-in problem LLxprt Code targets
Most terminal coding agents are welded to one vendor. You install the tool, you authenticate against the vendor's endpoint, and the model behind the agent is whatever that vendor ships this month. LLxprt Code takes the opposite position: the README describes it as an "AI-powered coding assistant that works with any LLM provider," and the command surface reflects that. The `/provider` command switches services, `/model` selects a model within the service, and `/auth` enables a credential path. The intended user is a developer who already holds several LLM entitlements and does not want a fourth one. The README's first code block is telling: it shows Gemini via a Google account or API key, Claude Pro or Max via OAuth, ChatGPT Plus or Pro through the Codex path, and Kimi via a key. Those are existing subscriptions, not new purchases. The secondary audience is privacy-motivated. The README claims local execution through LM Studio and llama.cpp, and states there is no telemetry by default. That claim is a configuration default, not an architectural guarantee, and you should treat it as something to verify in your own network environment rather than take on faith.
How routing and failover actually work
The mechanism visible in the material is a provider abstraction with a load-balancing layer on top. The README lists "Multi-Account Failover" (multiple OAuth accounts that fail over automatically on rate limits) and "Load Balancer Profiles" (balancing requests across providers or accounts with automatic failover). So the routing decision happens above the request, not inside the model call. This matters for how you reason about failures. When a rate limit hits, the tool moves to the next configured account or provider rather than surfacing an error to you. That is convenient and it is also a source of confusion: if an answer looks different from what you expected, the request may have been served by a different account or a different model than the one you thought was active. The README also describes subagents that can be configured with different models, providers, or settings. That is the more architecturally interesting piece, because it means a single task can span providers within one session. The documentation supplied here does not describe the scheduling policy, the ordering guarantees between accounts, or how a partially completed request is handled when failover occurs mid-stream. Those are the questions to answer before trusting the balancer with anything long-running.
Install paths and the commands you actually type
Two install routes are documented. On macOS, `brew tap vybestack/homebrew-tap`, then `brew update`, then `brew install llxprt-code`. Via npm, `npm install -g @vybestack/llxprt-code`. The README also gives a no-install path: `npx @vybestack/llxprt-code --provider synthetic --model hf:zai-org/GLM-4.7 --keyfile ~/.synthetic_key "simplify the README.md"`. Note the shape of that invocation. Provider, model, key file, and prompt are all flags on a single command, which means the tool is usable non-interactively, not only as a REPL. The prerequisite is Node.js 24 or newer, except under Homebrew where it is not required. Authentication commands follow a consistent pattern: `/auth gemini enable` then `/provider gemini` then `/model gemini-2.5-flash`. The same three-step shape appears for anthropic, codex, and kimi, though Kimi uses `/key` with a key value rather than an OAuth enable step. The README notes that tier availability for free and low-cost options changes and points to `docs/cli/authentication.md` for the current state. That is a moving target and the README does not pin it down.
The Bun launcher is the most fragile part of the design
LLxprt Code runs on Bun. The README is explicit that Node.js "remains the compatibility target for invocation" while the platform-native launcher at `packages/cli/bin/llxprt` resolves a package-bundled Bun and execs `packages/cli/index.ts` directly. No Node process starts on the installed command path, and there is no pre-compiled `dist/` artifact to build. The resolution order is documented in three levels. First, package-local at `<package>/node_modules/bun/bin/bun.exe`. Second, hoisted, meaning the enclosing `node_modules/bun/bin/bun.exe`, with the search stopping at the enclosing `node_modules` boundary and never climbing into consumer ancestors. Third, workspace root, only when the package is not under a `node_modules` and the repository root is a verified llxprt-code workspace whose manifest references this package. Each level has an `@oven/bun-<platform>` fallback probed only when the primary path is absent. On macOS, a Bun already on `PATH` that meets the pinned version floor takes precedence over all of it, which the README attributes to issue #2962 and a credential-access disruption caused by npm re-extracting a running executable. The launcher never scans `.bin` symlinks, and when `package.json` declares an exact pin such as `1.3.14`, a candidate with a missing or mismatched version is rejected. If every candidate is rejected, the launcher prints an error and exits with code 43. That exit code is the contract to script against.
npm v12 default-deny and why the optional dependencies exist
This is the constraint most likely to bite in a locked-down CI image. npm v12, per RFC 0054, disables dependency install scripts by default. The `bun` package ships its binary through a `postinstall` that moves it from an `@oven/bun-<platform>` optional dependency into `bun/bin/bun.exe`. When install scripts are blocked, that move never happens and the binary never appears. LLxprt Code's answer is to declare all 16 `@oven/bun-<platform>` packages as its own `optionalDependencies`. Those tarballs contain only `bin/bun[.exe]` and carry no install scripts, so they materialize even under default-deny. The launcher and the TypeScript resolver fall back to them when `bun/bin/bun.exe` is missing. One detail in the README is worth repeating because it affects startup cost: host detection, meaning CPU feature and ABI probing, runs only on this fallback path. A normal install never forks detection subprocesses. So the fallback is functional but not free, and the cost lands on exactly the environments that are already the most constrained.
Where LLxprt Code is the wrong tool
The multi-provider design is a liability if what you want is reproducibility. A session that can be served by any of several accounts or providers is harder to reason about after the fact than one pinned to a single endpoint. If your workflow depends on model-version stability across runs, the load balancer works against you. The second limitation is environmental. The launcher's resolution logic assumes it can find a Bun binary somewhere in a specific set of locations, and it will not degrade gracefully if it cannot. Exit code 43 is a hard stop. On a platform where the `@oven/bun-<platform>` tarball for that architecture is not published as an optional dependency, or where optional dependencies are stripped by the package manager, there is no documented recovery path in the material supplied here. The third is documentation depth. The README covers install, auth, and launcher resolution in unusual detail, but it does not describe the context window handling, the tool-calling protocol, or how edits are applied to files. For a tool whose job is editing codebases, that is a gap. The README also does not state which OpenAI-compatible providers have been verified as opposed to merely supported by the interface.
How this differs from a vendor-tied agent
The obvious comparison is a vendor-tied terminal agent, where the CLI and the model come from the same organization. That arrangement is simpler: one auth flow, one model family, one place to report a bug. LLxprt Code trades that simplicity for substitution. If Anthropic raises prices or degrades a model, you change `/provider` and continue. If you want to run against LM Studio or llama.cpp on your own hardware, the same interface applies. The cost of substitution is the abstraction itself. A vendor-tied agent can tune prompts and tool schemas to one model's quirks. A provider-agnostic agent has to work across model families with different context limits, different tool-calling formats, and different tokenizers. The README lists GLM 5.2, Kimi K3, MiniMax M3, and Qwen 3 Coder Next as supported open models, which suggests the abstraction is being exercised across genuinely different architectures rather than one family with different names. Whether prompt quality holds up equally across all of them is not something the supplied documentation addresses, and it is the thing I would want measured before standardizing a team on this.
Licence, release cadence, and what to check before rolling it out
The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive licence, and it does not carry the copyleft obligations of a GPL-family licence. This is a description of the licence identifier, not legal advice; if you are redistributing a modified build, have counsel read the NOTICE and attribution requirements. The release cadence visible in the material is aggressive: v0.11.0 on 2026-09-07, with nightly builds on 2026-09-07 and 2026-09-08, and the repository's last push on 2026-09-09. Nightly tags follow a date-and-commit pattern. If you pin to a stable release, expect to move relatively often to stay near the documented behaviour, since the README describes launcher logic that has clearly changed recently (the macOS `PATH` preference is attributed to a specific issue number). Upgrade cost concentrates in the launcher and the Bun pin. An exact pin such as `1.3.14` in `package.json` means a version mismatch causes a candidate to be rejected outright, so a Bun upgrade in your environment can break the launcher even when the LLxprt Code version is unchanged. Before rolling this out, run `llxprt` on each target platform and confirm it starts rather than exiting 43, confirm your chosen `/auth` path completes, and confirm that a failover event during a long request produces a result you can still trust.
Editorial conclusion
Adopt LLxprt Code if you already pay for Claude Pro, ChatGPT Plus, or a Kimi subscription and want those entitlements reachable from a terminal without a second billing relationship, or if you need to point a coding agent at LM Studio or llama.cpp for local inference. Do not adopt it if your environment blocks postinstall scripts and you cannot tolerate the @oven/bun-<platform> fallback path, or if you want a single deterministic model behind the agent rather than a routing layer. Verify first that `llxprt` resolves a Bun binary on your platform and that your chosen auth path completes, because the launcher exits 43 rather than degrading when no runtime candidate is found.
Community notes