← → navigate · I index · F fullscreen
Repository deep dive · September 2026

OpenClaude
runs anywhere.

One terminal-first coding-agent workflow for cloud APIs, local models, tools, agents, MCP and streaming output.

Open source CLI Node.js ≥ 22 Cloud + local backends
01 · Plain-English TL;DR

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.

Bottom line: OpenClaude is most useful when you want the coding-agent experience to follow your model and infrastructure choices, rather than the other way around.
Source-backed summaryREADME·agent routing docs
02 · Why it matters

The leverage is in the seam between model choice and tool use.

01
Provider abstraction

A single interaction surface can sit over OpenAI-compatible APIs, Gemini, GitHub Models, Codex, Ollama, Atomic Chat and other supported routes.

02
Agent orchestration

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.

03
Local or headless

Run a local model for privacy or experimentation, or put the engine behind a gRPC interface for another UI, CI/CD pipeline or product.

04
Deliberate trade-offs

Provider behaviour is not identical. Tool quality, output limits, authentication and local-model capability still matter.

03 · Benefits in practice

Where it earns a place in your toolkit.

A · LOCAL EXPLORATION

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.

privacy-first experiments
B · COST-AWARE ROUTING

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.

agentModels + agentRouting
C · PRODUCT EMBEDDING

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.

headless integration
D · CODEBASE ONBOARDING

Inject repo structure

Use the optional repo map to surface structurally important files and definitions when a project is too large to read linearly.

PageRank-backed map
E · REPEATABLE CAPABILITY

Package skills

Install or author skills as folders containing a SKILL.md, then let the agent invoke reusable procedures by name.

skills
F · LONG TASKS

Run background sessions

Kick off a detached prompt, inspect its status and logs, and keep the terminal available for other work.

--bg / ps / logs
02

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.

04 · Mental model

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
05 · Architecture

Terminal-first on the outside; provider-aware on the inside.

Interactive CLIPrompts, sessions, slash commands, streaming output and permissions.
Background modeDetached child processes with status and logs.
VS Code extensionLaunch integration and theme support are bundled.
⇄
Query + tool loopModel calls, tool execution, context, sub-agents and follow-up responses.
Provider adaptersOpenAI-compatible, Gemini, Codex, Ollama, Anthropic-family routes and more.
Integration boundaryBidirectional gRPC can stream text, tool calls and permission requests.
Design implication: treat provider choice as a replaceable runtime decision, but treat tool permissions, secrets, context and evaluation as product decisions.
06 · Provider layer

Bring your route. Keep your workflow.

Route familyHow it is configuredUseful when
OpenAI-compatible/provider or env varsOne interface for OpenAI, OpenRouter, DeepSeek, Groq, Mistral, LM Studio and compatible /v1 servers.
Gemini / GitHub Modelsprovider flowYou want a guided setup or a provider-specific onboarding path.
Codex OAuth / Codex/providerYou want ChatGPT sign-in or existing Codex CLI credentials.
Ollama / Atomic Chatlocal runtimeYou want local inference, no API key, or Apple Silicon experimentation.
Anthropic-family routesenv / native routeYou 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.

07 · Agent routing

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
---
Practical pattern: cheap model for discovery, stronger model for planning or synthesis, bounded verifier before completion. Keep the routing explicit and test each route on the same task set.
08 · Context leverage

Two ways to make a large codebase feel smaller.

REPO MAP

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.

REPO_MAP=1 opt-in1024-token auto map
SKILLS

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.

.openclaude/skills project-localregistry or URL
$ REPO_MAP=1 openclaude
# the session receives a compact structural map
$ openclaude skills list
enabled  ci-fix  Diagnoses and fixes CI pipeline failures.
09 · Integration boundary

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
Security note: binding to 0.0.0.0 exposes the service on all interfaces and is not recommended without authentication.
10 · Read this before adopting

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.
03

Start small: install, connect, bound, validate.

A useful first run is a controlled repo task, not an all-access autonomous experiment.

11 · Step 1

Install the CLI and confirm the runtime.

01

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
02

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
12 · Step 2

Choose a cloud route or a local model.

FAST CLOUD PATH

OpenAI-compatible API

$ export CLAUDE_CODE_USE_OPENAI=1
$ export OPENAI_API_KEY=sk-your-key
$ export OPENAI_MODEL=gpt-4o
$ openclaude
LOCAL PATH

Ollama

$ export CLAUDE_CODE_USE_OPENAI=1
$ export OPENAI_BASE_URL=http://localhost:11434/v1
$ export OPENAI_MODEL=qwen2.5-coder:7b
$ openclaude
Recommended first experiment: use /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.
13 · Step 3

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
14 · Step 4

Scale the workflow only after the loop works.

01

Route

Add agentModels and agentRouting to map different agent types to models or endpoints.

02

Map

Enable REPO_MAP=1 when a repository is large enough that compact structural context improves navigation.

03

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
15 · Step 5 · Optional

Turn the agent loop into a service boundary.

01

Start locally

Run the gRPC server on localhost and use the shipped CLI client to understand the stream and permission events.

02

Generate a client

The repository points to src/proto/openclaude.proto as the source for clients in Python, Go, Rust or another language.

03

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
16 · Validate before trust

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.

Interpretation grounded inprovider notes·step limits·gRPC safety note
17 · Takeaways

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.
18 · Sources and licence

Read the source, then test the workflow on your own repos.

Primary reading

01
Repository and README
Product scope, quick start, providers, agents and background sessions.
02
Advanced setup
Source builds, provider environment variables and runtime controls.
03
Agent routing and step limits
Per-agent models, routing and bounded tool use.
04
Repo map · Skills
Context compression and reusable procedures.
05
Headless gRPC server
Streaming integration boundary and safety defaults.

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.

Practical takeaway: review the repository’s current licence and terms before redistribution or commercial adoption.
LicenceLICENSE

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.

OpenClaude deep divegithub.com/Gitlawb/openclaude