more-pi

OpenClaw-flavored wrapper for pi. It launches @earendil-works/pi-coding-agent with an extension that registers OpenClaw Codex, Anthropic, and Ollama Cloud providers.

Usage

more-pi --provider openclaw-codex --model gpt-6-astra
more-pi --provider anthropic --model claude-opus-5
more-pi --provider ollama-cloud --model qwen3.5:397b-cloud

The OpenClaw Codex provider reads credentials from:

~/.openclaw/agents/main/agent/auth-profiles.json

Override the path with:

OPENCLAW_AUTH_PROFILES_PATH=/path/to/auth-profiles.json more-pi

GPT models

The extension's Codex models (gpt-6.1-sol, gpt-6.1-terra, gpt-6-sol, gpt-6-luna, gpt-6-astra) are listed under Pi's own openai-codex provider as well as under openclaw-codex, so the full GPT lineup is reachable through whichever credentials you have — a Pi openai-codex login works on its own, no OpenClaw auth profile required.

more-pi --provider openai-codex --model gpt-6-astra

Anthropic

The extension re-registers the anthropic provider so the Claude 5 flagships are selectable on the pinned Pi release. Pi 0.80.10's catalogue stops at Claude Opus 4.8, so claude-opus-5 and claude-fable-5-1 ship with the extension; every model Pi already knows is folded back in, and Pi's entry wins on an id collision. Drop the fallbacks once the pinned Pi ships them.

Credentials

Resolved in this order:

1. A credential stored by Pi — /login in Pi, or the anthropic entry in ~/.pi/agent/auth.json. This includes Claude Pro/Max OAuth, which the re-registration leaves intact.
2. ANTHROPIC_AUTH_TOKEN, if exported.
3. ANTHROPIC_API_KEY.

more-pi --provider anthropic --model claude-opus-5

Ollama Cloud

Ollama Cloud connects directly to https://ollama.com/v1 (no local Ollama server required).

Setup

1. Get an API key from ollama.com
2. Configure via one of:
   • /login in Pi → API key → Ollama Cloud
   • export OLLAMA_API_KEY="your-key"
   • Multiple keys with automatic rotation:

export OLLAMA_API_KEYS="key-one,key-two,key-three"

• ~/.pi/agent/auth.json (comma-separated keys also work in the key field):

{
  "ollama-cloud": {
    "type": "api_key",
    "key": "your-key"
  }
}

3. Refresh models (optional — baked-in list ships with the extension):

/ollama-cloud-refresh

All catalogued models are listed. Set OLLAMA_CLOUD_FILTER_LOCKED=1 to probe each one at startup and hide those your subscription cannot reach.

Pi TUI

more-pi --provider ollama-cloud --model <model-id>

Use /model or Ctrl+L to pick any Ollama Cloud model under the ollama-cloud provider.

OpenAI-compatible endpoint

Start a universal OpenAI-compatible HTTP server that routes to Codex, Ollama Cloud, and Pi built-in providers (OpenRouter, Groq, DeepSeek, etc.):

# Core OpenAI-compatible mode
more-pi --mode endpoint --port 8888

# VS Code Copilot Custom Endpoint mode
more-pi --mode vscode --port 8888

# Ollama-compatible model discovery
more-pi --ollama

--ollama listens on port 11434 by default (Ollama's default). Stop a local Ollama server first, or use --port 11435 and set VS Code's Ollama endpoint accordingly.

Provider backend: my-ai-api

Uses my-ai-api 0.3.7, including its updated Codex discovery client version. The endpoint and Pi picker support gpt-6.1-sol, gpt-6.1-terra, gpt-6-sol, and gpt-6-luna, alongside gpt-6-astra and the existing GPT-5 models. Their vision, context limits, reasoning settings, and Standard API price estimates follow the official OpenAI model guidance and pricing. For GPT-6 requests, minimal maps to low; none also maps to low for Astra and GPT-6.1 Sol, which require reasoning. Terra, GPT-6 Sol, and Luna preserve none. Account access is determined by the upstream service.

The HTTP endpoint routes the provider families my-ai-api covers — Codex, Anthropic, Gemini/Antigravity and xAI — through it, instead of through hand-maintained model lists. Ollama Cloud and the ~20 pi-completions providers (OpenRouter, Groq, DeepSeek, …) are untouched and still go through Pi.

The reason is model drift. The lists this replaces had gone stale: three Codex slugs the backend had retired (gpt-5.4, gpt-5.4-mini, gpt-5.3-codex-spark) were still advertised, and because the old path answered a retired model with HTTP 200 and an empty body, VS Code offered the model and then produced nothing. my-ai-api asks each vendor's own models route, so a slug the vendor retires disappears without a code change, and an upstream failure arrives as a real error.

Two things the vendor routes get wrong, which providers/myai/catalogue.ts corrects:

• Ids the vendor omits. Codex discovery depends on the client version. my-ai-api 0.3.7 requests the newer catalogue; discovery is also unioned with the documented GPT-6 models above so they remain selectable when omitted.
• Entries that are not chat models. Antigravity's catalogue is the editor's whole model list, so chat_<digits>, tab_* and the *-image family are filtered out by shape. Models marked visibility: "hide" (gpt-reserve, codex-auto-review) are withheld too — they answer, but the vendor keeps them out of its own picker.

Each provider is gated on its own credential and listed independently at startup, so one without a usable login is simply absent rather than fatal:

[my-ai-api] 27 models over 2 provider(s), discovered live:
  [loaded] openai         5 models
  [loaded] antigravity    22 models
  [skipped] anthropic     No usable credential for provider "anthropic".

Endpoint ids keep the historical openai-codex/ prefix, because they get pasted into VS Code settings and chatLanguageModels.json.

max_tokens, temperature and top_p are dropped on the Codex route. That backend rejects all three outright (400 {"detail":"Unsupported parameter: max_output_tokens"}), and VS Code puts max_tokens on every request, so forwarding it would fail every call. These are reasoning models whose depth comes from the slug and the thinking level, not from temperature. Anthropic, Gemini and xAI all receive the trio normally.

A reasoning_effort field on the request body is accepted as an endpoint extension (none … max) and mapped to whatever the provider actually uses — reasoning.effort on Codex, output_config.effort on Anthropic, thinkingConfig.thinkingLevel on Gemini:

curl -s http://localhost:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"openai-codex/gpt-6-astra","reasoning_effort":"xhigh",
       "messages":[{"role":"user","content":"Plan the migration."}]}'

Verification status. Codex and Antigravity were exercised end to end against a live codex login and agy login on 2026-09-21 — model listing, /api/show, streaming and non-streaming completions, parallel tool calls, vision and token accounting. Anthropic, Gemini API and xAI are covered by unit tests only: no credential for them existed in that environment, so their routes have not been run against a live endpoint. Each is credential-gated, so an untested route cannot affect the Codex path.

When a provider sends a reasoning delta, More Pi streams it separately from the answer as reasoning_content. A model can apply the requested effort without sending a visible summary; this has been observed on the Codex backend.

Requiring a key from clients

The server binds 0.0.0.0 and is open by default — anyone who can reach the port can use it, and their Authorization: Bearer is treated as a bring-your-own upstream key. Set MORE_PI_API_KEY to require a secret from every client instead:

MORE_PI_API_KEY=your-server-key more-pi --ollama

Add --codex-only to serve just the Codex models. Provider keys are read from the environment and from Pi's stored credentials, so an unrelated OPENROUTER_API_KEY exported in your shell would otherwise publish that provider's whole catalogue on a publicly reachable endpoint:

MORE_PI_API_KEY=your-server-key more-pi --ollama --codex-only

Clients then send Authorization: Bearer your-server-key or X-Api-Key: your-server-key; anything else gets 401. /health and / stay open for process supervisors. The gate secret is consumed by more-pi and never forwarded upstream, so bring-your-own-key still works for callers presenting a different token. Leaving MORE_PI_API_KEY unset keeps the previous open behaviour.

Dependency compatibility

This version requires Node.js 22.19+ and uses Pi 0.80.10. Pi 0.80.8 removed the public AuthStorage export; more-pi now uses readStoredCredential for credential discovery and ModelRuntime for API-key/OAuth resolution. Existing auth.json credentials still work.

If an older more-pi installation reports does not provide an export named 'AuthStorage', upgrade to more-pi 0.1.22 or later:

npm install -g more-pi@latest
more-pi --ollama

To build and install from this checkout:

pnpm install --frozen-lockfile
pnpm run build
npm install -g .
more-pi --ollama

Pi dependencies are pinned and pnpm run build only compiles; dependency upgrades are explicit. Run pnpm run test:ollama after upgrading them. more-pi --version currently forwards to Pi, so it reports the Pi version rather than the more-pi package version.

Ollama mode endpoints (VS Code auto-discovery)

Endpoints (core / vscode modes)

Both modes also accept /models and /chat/completions. Set stream: true for server-sent events; omit it or set it to false for JSON.

API key detection

Provider credentials are resolved per backend:

All providers also accept Authorization: Bearer <key> from the client (used by VS Code).

Multi-key rotation (Ollama Cloud + OpenRouter)

When you configure multiple API keys, more-pi automatically rotates to the next key when one hits a rate limit. There is no usage API for these providers, so limits are tracked heuristically:

export OLLAMA_API_KEYS="key1,key2,key3"
export OPENROUTER_API_KEYS="key1,key2"
more-pi --mode endpoint --port 8888

On HTTP 429 / rate-limit errors (before any response content is sent), the server marks that key as cooling down and retries with the next key. State is persisted in ~/.pi/agent/cache/api-key-pool.json across restarts.

Optional tuning:

export MORE_PI_OLLAMA_SESSION_WINDOW_MS=18000000   # 5 hours
export MORE_PI_OLLAMA_WEEKLY_WINDOW_MS=604800000   # 7 days

Ollama Cloud models appear in /v1/models when their credentials are configured, or when a Bearer token is sent with the request. The full catalogue is listed by default, and a model you are not entitled to fails at request time with the provider's own error.

To hide subscription-gated models instead, set OLLAMA_CLOUD_FILTER_LOCKED=1. Each model is then probed with a minimal API request on server start and the locked ones are dropped from the list. The probe costs one request per model, so listing stays instant while it is off.

VS Code setup (legacy Ollama provider)

VS Code's deprecated built-in Ollama provider auto-discovers models via /api/tags and /api/show. If your VS Code still offers this provider:

1. Stop local Ollama if it is using port 11434 (or pick another port with --port)
2. Configure provider keys (OLLAMA_API_KEY, auth.json, etc.)
3. Run:

more-pi --ollama

4. In VS Code: Chat: Manage Language Models → Add Models → Ollama
5. Endpoint: http://localhost:11434 (or your host/port)
6. All configured models appear automatically — no chatLanguageModels.json editing

pi-coding-agent setup (another Pi instance via Ollama endpoint)

When a second pi-coding-agent instance connects to more-pi --ollama, it must declare vision support in ~/.pi/agent/models.json. Pi defaults custom models to text-only (input: ["text"]), which causes the agent to reject images with "model does not support images" before the request reaches more-pi.

Generate a ready-to-use config (includes "input": ["text", "image"] for vision-capable models and "reasoning": true with thinkingLevelMap for thinking models):

more-pi --pi-models-config --host http://localhost:11434 > ~/.pi/agent/models.json

Without this, pi defaults custom models to text-only and non-reasoning, so images and thinking levels are rejected before requests reach more-pi.

Set provider keys (OPENCLAW_API_KEY, OLLAMA_API_KEY, auth.json, etc.) before generating so all backends appear. Re-run after adding providers.

VS Code setup (Custom Endpoint)

1. Configure the provider logins or API keys on the server, then start More Pi:

   more-pi --mode vscode --port 8888

2. Generate the Custom Endpoint group from the running server. Use the address that VS Code can reach:

   more-pi --vscode-config --from-server --host http://localhost:8888 > more-pi-vscode.json

   If the server requires MORE_PI_API_KEY, set the same variable in the shell that runs this command. The generator uses it to fetch the catalog and writes a VS Code secret reference in the file. Omit --from-server to generate a catalog from local credentials when the server is offline.

3. In Chat: Manage Language Models → Add Models → Custom Endpoint, choose Chat Completions. In the chatLanguageModels.json file that opens, replace the More-Pi group with the generated one, leaving your other groups in place. For a protected server, set the group key with Update API Key in the Language Models editor. For an open server, the group can omit apiKey.

4. Select a More-Pi model in Chat. For reasoning models, open the submenu next to the model name and select its effort. More Pi accepts VS Code's reasoning_effort and routes it to the selected model's backend.

5. Re-run the generator after changing the server's model catalog. Copy the new models array into your group to keep the effort settings and API key you already saved in VS Code.

The Custom Endpoint source can request <provider-url>/models, but the shared discovery code skips IDs without known capabilities, and Custom Endpoint does not read those capabilities from the response. The generated group supplies the explicit model entries needed for More Pi's IDs, including the effort picker, tool calling, vision, and token limits. Use the generated per-model URLs and omit the provider-level url so VS Code uses those entries.

More Pi uses the Chat Completions API at the VS Code boundary for every configured backend, including ones that speak Responses or Messages upstream.

Package behavior

• Does not patch @earendil-works/pi-ai or @earendil-works/pi-coding-agent.
• Reuses pi's built-in openai-codex-responses and openai-completions transports.
• Mirrors the installed pi-ai openai-codex model list into openclaw-codex at extension load time.
• Ships a baked-in Ollama Cloud model list; run /ollama-cloud-refresh for the latest catalog. The whole list is offered; set OLLAMA_CLOUD_FILTER_LOCKED=1 to hide models your plan cannot reach.
• Can also be installed as a pi package; its pi.extensions manifest points at dist/extension.js.

Development

Endpoint code lives under src/endpoint/:

• ollama/ contains the Ollama server entry point, native routes, and model metadata mapping.
• vscode/ contains the VS Code server entry point and chatLanguageModels.json generator.
• openai/ contains the standard OpenAI-compatible entry point, Chat Completions protocol, and Pi config generator.
• shared/ contains the HTTP server and model routing used by all three modes.
• backends/ contains the adapters for Codex, Ollama Cloud, my-ai-api, and Pi providers.

pnpm run build
pnpm publish