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 (optimized streaming)
more-pi --mode vscode --port 8888

# Ollama-compatible mode — auto model discovery in VS Code (recommended)
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.

Reasoning/thinking text is not streamed for Codex. The backend emits no reasoning summary events over this route even when asked (reasoning.summary is accepted and ignored), and the path this replaces did not surface any either, so nothing was lost.

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)

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 (recommended: Ollama mode)

VS Code's built-in Ollama provider auto-discovers models via /api/tags and /api/show. Use --ollama instead of Custom Endpoint:

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 — manual model list)

VS Code's Custom Endpoint provider (vendor: "customendpoint") does not auto-fetch models from GET /v1/models. That is a VS Code limitation: each model must be listed manually in chatLanguageModels.json with toolCalling, vision, and token limits. more-pi already serves /v1/models, but VS Code ignores it for custom endpoints.

1. Run more-pi --mode vscode --port 8888
2. Generate a VS Code config from your configured providers:

more-pi --vscode-config --host http://192.168.8.3:8888 > chatLanguageModels.json

Set OLLAMA_API_KEY (and other provider keys in auth.json or env) before running --vscode-config so Ollama Cloud and other backends appear in the output. Re-run after adding providers or refreshing models.

3. Copy the generated JSON into VS Code's chatLanguageModels.json (opened via Chat: Manage Language Models), set apiKey if needed, and reload the window.
4. Pick a model from the model picker.

Important: Use per-model url values pointing at http://<host>:<port>/v1/chat/completions. Do not rely on a provider-level url alone — VS Code will not discover models from more-pi's /v1/models endpoint for customendpoint.

Models need "toolCalling": true to appear in the VS Code model picker.

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

pnpm run build
pnpm publish