OpenClaude: One Terminal for Cloud and Local Coding Models
runs anywhere. uses anything
At a glance
- What is it?
- OpenClaude is a TypeScript coding-agent CLI that routes prompts, tools and MCP through a single terminal workflow across OpenAI-compatible APIs, Gemini, Ollama and other backends. The pitch is provider portability; the cost is that portability is exactly where the sharp edges live.
- Who is it for?
- Adopt OpenClaude if you already juggle several model backends and want one terminal surface for bash, file tools, grep, glob, agents, tasks, MCP and web tools instead of a separate harness per provider. Do not adopt it if you need a settled licence position today, or if your work depends on a single vendor's proprietary agent features that a compatibility layer cannot reproduce.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 4 days 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 problem OpenClaude targets: provider lock-in in the terminal
Most coding agents are welded to one vendor. You pick a model provider, and the terminal harness, the tool definitions, the slash commands and the streaming output all come as a package with it. Switch providers and you rebuild your habits. OpenClaude's README frames the project as an answer to that: an open-source coding-agent CLI for cloud and local model providers, with one terminal-first workflow covering prompts, tools, agents, MCP, slash commands and streaming output. The intended user is an engineer who already has access to more than one backend, whether through an OpenAI-compatible endpoint, a Gemini key, GitHub Models, Codex OAuth, Ollama on their own machine, or Atomic Chat, and who does not want a different tool per endpoint. The secondary audience is people running local models who still want the agent affordances (bash, file tools, grep, glob, agents, tasks, web tools) that cloud CLIs assume. If you only ever talk to one provider and that provider's own CLI already fits, OpenClaude solves a problem you do not have.
What the repository actually shows about the architecture
The primary language is TypeScript, and the README lists a bundled VS Code extension for launch integration and theme support, which implies the CLI and the extension share the same core rather than the extension being a wrapper around a separate binary. The feature list is a flat enumeration: bash, file tools, grep, glob, agents, tasks, MCP and web tools. That flatness is informative. It suggests a tool-registry design where each capability is a named tool the model can call, and the agent loop is provider-agnostic because the tools sit above the provider boundary rather than inside it. MCP support means the tool set is extensible beyond what ships in the box. The provider layer is described as accepting OpenAI-compatible APIs, Gemini, GitHub Models, Codex OAuth, Codex, Ollama and Atomic Chat, which points to an adapter per backend normalising requests and streaming responses into one internal shape. I cannot confirm the adapter interface, the streaming normalisation, or how tool-call schemas are translated between providers, because the README does not show the source. Treat that as the first thing to inspect in the repository if you care about a specific backend.
Install and first run: the commands the README gives
The README states that OpenClaude requires Node.js `>=22.0.0` for npm installs and runtime, and that Bun is only needed for source builds. The npm package is `@gitlawb/openclaude`, so the install line is `npm install -g @gitlawb/openclaude`. Provider configuration is handled through a slash command: `/provider` is described as guided provider setup with saved profiles. That is the key operational detail. Profiles mean you configure a backend once and switch between saved configurations rather than re-entering endpoints and keys per session. The README does not spell out the profile file location or the exact keys each provider adapter expects, so the honest position is that the guided flow is the documented path and manual configuration is not described here. The VS Code extension is bundled, and the README points to a section titled Meet your buddy, which describes a pixel-art hero companion that fires an arrow every time you press Enter. That is a real feature in the README, not a joke I am adding, and it tells you something about the project's tone: it is willing to spend surface area on personality.
Where the single-CLI promise breaks down
Provider portability is a compatibility claim, and compatibility claims are where coding agents fail quietly. An OpenAI-compatible API is compatible at the request shape, not at the model behaviour. Tool-calling fidelity, parallel tool calls, streaming deltas and context limits all vary by backend, and a CLI that presents them as one workflow has to either normalise aggressively (losing provider-specific features) or pass through (leaking provider quirks into your prompts). The README does not say which path OpenClaude takes. The practical consequence is that a prompt tuned against one backend may behave differently against another with the same flags, and the failure will look like the model being bad rather than the adapter being lossy. The second limitation is the release cadence. Three releases appear in the supplied list within roughly three weeks: v0.29.0 and v0.29.1 on 2026-08-19, then v0.30.0 on 2026-08-31. That is fast enough that pinning a version matters if you script the CLI in CI. The third is the licence, covered below. None of these are disqualifying, but the first one is the reason to test your actual backend before trusting the abstraction.
Licence status: the badge and the metadata disagree
The README carries a licence badge reading MIT and links to a LICENSE file. The repository metadata supplied for this review classifies the licence as NOASSERTION, which is what GitHub reports when it cannot map the LICENSE file to a known licence. Those two signals do not match, and I cannot resolve the discrepancy from the README alone. The practical reading: read the LICENSE file itself before you depend on MIT terms, especially if you plan to redistribute the CLI inside a product or vendor it into an internal platform. This is a description of what the metadata shows, not legal advice, and the only reliable source is the file in the repository. A mismatch like this is common in young projects where the badge is added early and the LICENSE text is edited later, but it is also exactly the kind of detail that matters at adoption time rather than six months in. Check it before you build on it, not after.
How it compares with Aider and with a vendor CLI
Aider is the closest well-known alternative in the open-source terminal agent space, and the difference is in the centre of gravity. Aider's design centres on git: it edits files and commits changes, and its model support is broad but the workflow is built around repository diffs. OpenClaude's README centres on the provider layer and the tool registry instead, listing bash, file tools, grep, glob, agents, tasks, MCP and web tools as the workflow, with a VS Code extension alongside. If your work is mostly multi-file edits you want reviewed as commits, Aider's model fits more directly. If your work is closer to an agent that runs commands, searches a tree, calls MCP servers and streams output while you sit in a terminal, OpenClaude's shape is the more natural one, and its provider list explicitly includes local backends such as Ollama and Atomic Chat. Against a vendor CLI, the trade is the reverse: you give up features the vendor only exposes to its own harness in exchange for not being tied to that vendor. Whether that trade is worth it depends entirely on whether you actually switch backends. If you do not, the vendor CLI is likely better tuned to its own model.
Maintenance cost and what to verify before adopting
The upgrade cost is dominated by the release cadence and the provider surface. With releases landing every week or two, a global npm install will drift, and a pinned version in a script will need periodic attention as provider APIs change underneath it. Saved profiles under `/provider` are the thing most likely to need editing when a backend changes its auth or endpoint shape, so keep a note of which profile maps to which backend. Before adopting, verify four things in the repository rather than in the README: the actual contents of LICENSE, the adapter code for the one backend you intend to use, whether tool-calling is normalised or passed through, and whether the Node.js `>=22.0.0` floor is enforced at runtime or only documented. Then run one real task end to end against your backend with `/provider` configured, and repeat it against a second backend if portability is the reason you are here. If the same prompt produces materially different tool behaviour across the two, you have your answer about how much the abstraction is doing for you.
Editorial conclusion
Adopt OpenClaude if you already juggle several model backends and want one terminal surface for bash, file tools, grep, glob, agents, tasks, MCP and web tools instead of a separate harness per provider. Do not adopt it if you need a settled licence position today, or if your work depends on a single vendor's proprietary agent features that a compatibility layer cannot reproduce. Before committing, run `node --version` and confirm it reports 22 or higher, then install with `npm install -g @gitlawb/openclaude`, run `/provider` to see which backends the guided setup actually offers you, and read LICENSE in the repository rather than trusting the MIT badge in the README, because the repository metadata classifies the licence as NOASSERTION.
Community notes