OpenClaude
runs anywhere.
One terminal-first coding-agent workflow for cloud APIs, local models, tools, agents, MCP and streaming output.
It is a model-flexible coding agent in your terminal.
One workflow
Keep prompts, files, shell commands, agents, MCP servers, slash commands and streamed responses in one place.
Many backends
Switch between compatible cloud endpoints and local runtimes such as Ollama without adopting a different CLI for each one.
More control
Route different agents to different models, cap tool-use steps, inspect repo structure, and expose the engine over gRPC.
The leverage is in the seam between model choice and tool use.
A single interaction surface can sit over OpenAI-compatible APIs, Gemini, GitHub Models, Codex, Ollama, Atomic Chat and other supported routes.
The workflow is not just “chat with a model”: tool calls, sub-agents, MCP, permissions, context and streaming are first-class parts of the loop.
Run a local model for privacy or experimentation, or put the engine behind a gRPC interface for another UI, CI/CD pipeline or product.
Provider behaviour is not identical. Tool quality, output limits, authentication and local-model capability still matter.
Where it earns a place in your toolkit.
Prototype with Ollama
Try a local coding model against a small repo, keeping the same agent/tool loop while iterating on model size and quality.
Split work by model strength
Use a cheaper or local model for exploration, a stronger model for planning, and a specialised route for frontend or review tasks.
Put an agent behind your UI
Expose the core engine over bidirectional gRPC, then build a custom interface, CI/CD integration or internal tool around the stream.
Inject repo structure
Use the optional repo map to surface structurally important files and definitions when a project is too large to read linearly.
Package skills
Install or author skills as folders containing a SKILL.md, then let the agent invoke reusable procedures by name.
Run background sessions
Kick off a detached prompt, inspect its status and logs, and keep the terminal available for other work.
Think of OpenClaude as a relay station between intent, tools and models.
Its interesting design choice is not a new model. It is the attempt to keep the agent loop portable.
One loop, several interchangeable layers.
Prompt
You state the task in the terminal or through a client.
Model
A provider route produces reasoning and tool intent.
Tools
Files, bash, grep, agents, tasks, MCP and web tools act on the repo.
Follow-up
Results return to the model for the next step in the loop.
Outcome
Stream progress, ask permission, inspect changes and finish.
$ openclaude # choose a provider, then ask for a bounded change > inspect the failing test, propose a fix, then run the focused suite streaming · tool call · permission · verification · summary
Terminal-first on the outside; provider-aware on the inside.
Bring your route. Keep your workflow.
| Route family | How it is configured | Useful when |
|---|---|---|
| OpenAI-compatible | /provider or env vars | One interface for OpenAI, OpenRouter, DeepSeek, Groq, Mistral, LM Studio and compatible /v1 servers. |
| Gemini / GitHub Models | provider flow | You want a guided setup or a provider-specific onboarding path. |
| Codex OAuth / Codex | /provider | You want ChatGPT sign-in or existing Codex CLI credentials. |
| Ollama / Atomic Chat | local runtime | You want local inference, no API key, or Apple Silicon experimentation. |
| Anthropic-family routes | env / native route | You need Bedrock, Vertex or Foundry-style integrations; behaviour differs from Chat Completions routes. |
Profiles reduce repetition
The /provider flow can save provider profiles. A profile is a practical boundary for switching model, endpoint and credentials without rewriting the task workflow.
But adapters are not identical
Tool quality, context handling, output caps and provider-native features vary. A green “connected” state is not an evaluation.
Use different models for different kinds of work.
Model routing
Map an agent type such as Explore, Plan, frontend-dev or verification to a named model route.
"agentRouting": { "Explore": "deepseek-v4-flash", "Plan": "gpt-4o", "frontend-dev": "zai-default" }
Step limits
A custom agent can set maxSteps to cap tool-use steps. When the limit is reached, the agent is asked for a concise summary of work, findings and remaining tasks.
--- name: bounded-researcher description: Focused research maxSteps: 8 ---
Two ways to make a large codebase feel smaller.
Structural context, ranked
The repo map enumerates files, extracts symbols and references, builds a weighted graph, then uses PageRank to rank structurally important files before rendering within a token budget.
Reusable procedures, named
A skill is a folder with a SKILL.md. Project and user skills load at start; commands support list, show, install, remove, validate and verify.
$ REPO_MAP=1 openclaude # the session receives a compact structural map $ openclaude skills list enabled ci-fix Diagnoses and fixes CI pipeline failures.
When the terminal is not the final interface.
Bidirectional streaming
The gRPC server can stream text chunks, tool calls and permission requests for sensitive commands. A test CLI client ships with the repository.
Product-shaped integration
Use the protocol boundary for a custom UI, an internal developer tool, CI/CD, or a future agentic product surface.
# terminal 1: start the engine $ npm run dev:grpc # terminal 2: run the test client $ npm run dev:grpc:cli # defaults GRPC_HOST=localhost GRPC_PORT=50051
0.0.0.0 exposes the service on all interfaces and is not recommended without authentication.Portability helps. It does not remove the hard parts.
Credentials
The routing guide warns that api_key values in settings.json are stored in plaintext. Keep the file private and out of version control.
Model variance
Anthropic-specific features may not exist on other providers, smaller local models can struggle with long tool flows, and output caps vary.
Config boundaries
OpenClaude uses its own ~/.openclaude paths and does not automatically load Claude Code configuration. Migrate intentionally.
What the repository does not prove
- It does not prove equal quality across every provider or model.
- It does not remove the need for permission design, evaluation, observability and secret handling.
- It does not create filesystem isolation when you fork a conversation; the README explicitly calls out that boundary.
Start small: install, connect, bound, validate.
A useful first run is a controlled repo task, not an all-access autonomous experiment.
Install the CLI and confirm the runtime.
Use Node.js 22 or newer
The npm install path requires Node.js ≥22.0.0. Bun is needed for source builds and local development.
$ node --version $ npm install -g @gitlawb/openclaude@latest $ openclaude --version
Run the first session
Start in a test repository with a clean working tree. Keep the first task narrow enough to inspect every file change.
$ cd path/to/a-test-repo $ openclaude
Choose a cloud route or a local model.
OpenAI-compatible API
$ export CLAUDE_CODE_USE_OPENAI=1 $ export OPENAI_API_KEY=sk-your-key $ export OPENAI_MODEL=gpt-4o $ openclaude
Ollama
$ export CLAUDE_CODE_USE_OPENAI=1 $ export OPENAI_BASE_URL=http://localhost:11434/v1 $ export OPENAI_MODEL=qwen2.5-coder:7b $ openclaude
/provider for guided setup, then run the same small task against one cloud model and one local model. Compare tool completion, edit quality, latency and cost.Make the first agent bounded and observable.
Limit the tool loop
Create a custom agent with a positive maxSteps value. Ask for a summary when the budget is exhausted rather than letting the workflow run indefinitely.
Keep permissions explicit
Treat file edits, shell commands, network access and credentials as separate capabilities. Use a disposable branch or test repository until the behaviour is predictable.
mkdir -p .openclaude/agents cat > .openclaude/agents/bounded-researcher.md <<'EOF' --- name: bounded-researcher description: Focused research with bounded tool use maxSteps: 8 --- You are a focused research agent. Return: completed work, findings, remaining tasks, and whether another run is needed. EOF
Scale the workflow only after the loop works.
Route
Add agentModels and agentRouting to map different agent types to models or endpoints.
Map
Enable REPO_MAP=1 when a repository is large enough that compact structural context improves navigation.
Package
Turn repeated procedures into skills under .openclaude/skills, then validate and verify them before wider use.
# structural context for the next session $ REPO_MAP=1 openclaude # inspect reusable capabilities $ openclaude skills list $ openclaude skills validate .openclaude/skills/my-skill $ openclaude skills verify
Turn the agent loop into a service boundary.
Start locally
Run the gRPC server on localhost and use the shipped CLI client to understand the stream and permission events.
Generate a client
The repository points to src/proto/openclaude.proto as the source for clients in Python, Go, Rust or another language.
Wrap it with product guardrails
Add authentication, network policy, audit logging, cancellation, rate limits, model selection and explicit approval states before exposing it beyond localhost.
$ npm run dev:grpc $ npm run dev:grpc:cli
Use the same task set to compare routes.
Functional checks
- Install path works on a clean machine.
- Provider setup can start a session and stream output.
- File read/write, shell, grep and MCP tools behave as expected.
- Resume, fork and background-session commands match your workflow.
- Repo map and skills load only when intended.
Risk checks
- Credentials are not committed or exposed in logs.
- Agent step limits stop work predictably.
- Tool permissions are visible and reviewable.
- Local versus cloud data paths are understood.
- gRPC is not exposed on all interfaces without authentication.
Suggested benchmark
Create five representative repo tasks: explore, plan, edit, test and review. Run them across two providers and record success, tool errors, human interventions, latency, token/cost signals and quality of the final diff.
The strategic idea is simple: keep the agent workflow stable while the model and deployment surface stay swappable.
Worth trying if you...
- Want one terminal workflow across cloud and local models.
- Need explicit agent routing or bounded sub-agents.
- Are exploring custom UIs or developer tooling around an agent engine.
- Prefer open-source control over provider-specific tooling.
Keep your eyes open for...
- Provider-specific differences and model quality variance.
- Credential storage, network exposure and permission boundaries.
- Whether your team needs a CLI, a service, or both.
- Evidence from your own task benchmark, not a feature checklist.
Read the source, then test the workflow on your own repos.
Primary reading
Licence note
The repository licence says modifications and additions by OpenClaude contributors are offered under the MIT License where legally permissible, while underlying derived code remains subject to Anthropic’s copyright and terms.
Deck prepared as an evidence-grounded explainer. Claims are based on the repository and linked documentation available at the time of preparation; check the upstream project for changes.
Keep your agent loop portable.
Then make the boundaries explicit: model, tools, permissions, context, evaluation and deployment.