pi-merge-gateway-login

pi extension that adds the Merge Dev gateway as a model provider through its OpenAI Responses API.

Install

pi install npm:@iaziz786/pi-merge-gateway-login
# or from git:
pi install git:github.com/iAziz786/pi-merge-gateway-login

Then authenticate (prompts for your key, stores it in ~/.pi/agent/auth.json):

/login merge-gateway

Permissions: outbound HTTPS to api-gateway.merge.dev only. No filesystem or subprocess access. Key stored by pi in ~/.pi/agent/auth.json.

Models

The extension registers the gateway's own catalog — every chat-capable model it serves, under the gateway's model IDs (GET /v1/models, ~270 models today, with context window, output cap, input modalities, and reasoning ladder per model taken from the model's preferred vendor). It is fetched at startup and falls back to four bundled models when no API key is available or the gateway cannot be reached:

bundled model ID	Model	Preferred vendor
merge-gateway/zai/glm-5.3-flash	GLM 5.3 Flash	Particle
merge-gateway/deepseek/deepseek-v4-flash	DeepSeek V4 Flash (retired, resolved to V4.1)	DeepSeek
merge-gateway/deepseek/deepseek-v4-flash-0731	DeepSeek V4 Flash 0731	Particle
merge-gateway/deepseek/deepseek-v4.1-flash	DeepSeek V4.1 Flash	DeepSeek

Pick via /model in pi (omp models merge-gateway lists them all). Requests are not pinned to a vendor: the gateway picks. That is deliberate — pi and omp generate session titles, compaction summaries, and handoff documents through side requests that never run extension hooks, so a model ID the gateway does not recognize, or a field only the hook could add, would break them (the vendor-prefixed IDs this extension used to register failed exactly there: 404 Model 'fireworks/deepseek-v4.1-flash' is not supported, after which compaction fell through to its largest-context fallback model and died on that model's output cap).

That is also why there is one entry per model rather than one per vendor: pi keys models by ID alone, so a per-vendor entry would need an invented ID that the gateway rejects on those unhooked side requests. Vendor selection belongs to the gateway, and pricing follows it — see below.

All models support:

• Reasoning: the thinking ladder is mapped per model from the vendor's declared effort values (DeepSeek takes the full none … max ladder; GLM folds onto low / high / max); models whose vendor declares none are registered without effort control
• Prompt caching: automatic. The extension forwards the pi session ID as the body prompt_cache_key (the gateway ignores the X-Session-Id header on this surface), which keeps a session on the vendor whose prompt cache is warm and namespaces the provider cache key. Existing keys are preserved.

Pricing

The gateway routes each request to the cheapest eligible vendor and fails over to the next when that vendor cannot take it, so a fixed card per model would drift. The extension prices each turn at the vendor that actually served it: after_provider_response fires before the response stream is consumed — and therefore before pi prices the usage — and rewrites the model's rates from that response's x-merge-vendor header, using the rates from the gateway's own catalog. Input, output, cache-read, and cache-write rates all follow the serving vendor, and DeepSeek's peak windows (weekdays 01:00–04:00 and 06:00–10:00 UTC, 2×) are applied from its schedule, so the displayed cost matches the gateway's usage.cost rather than an estimate.

If the catalog could not be fetched, the bundled cards below remain — one per model, at the preferred vendor's base rates, which is the route the gateway picks by default.

Bundle model	Preferred vendor	Input	Output	Cache read
zai/glm-5.3-flash	Particle	$0.015	$0.05	$0.003
deepseek/deepseek-v4-flash	DeepSeek	$0.15	$0.60	$0.003
deepseek/deepseek-v4-flash-0731	Particle	$0.035	$0.07	$0.007
deepseek/deepseek-v4.1-flash	DeepSeek	$0.15	$0.60	$0.003

Rates are per million tokens and were verified against the gateway's own usage.cost on live probes — cold and cache-hit turns matched to nine decimals. Cache writes are billed only on some vendors (Anthropic and Bedrock entries, from cache_write_per_million).

Every vendor the gateway may choose, with what it charges, comes from GET /v1/models and is applied automatically. For the four bundle models:

Model	Eligible vendors (input / output / cache read per M)
zai/glm-5.3-flash	Particle 0.015/0.05/0.003 · z.ai 0.015/0.05/0.003 · Baseten, Fireworks, Together AI, Wafer 0.15/0.50/0.03 · Modal 0.45/1.50/0.09
deepseek/deepseek-v4-flash	resolved to V4.1 Flash before routing, and billed as it
deepseek/deepseek-v4-flash-0731	Particle 0.035/0.07/0.007 · Makora 0.09/0.195/0.0196 · Baseten 0.13/0.26/0.028 · Together AI 0.14/0.28/0.03 · Empiriolabs 0.14/0.28
deepseek/deepseek-v4.1-flash	DeepSeek 0.15/0.60/0.003 · Particle 0.20/0.80/0.03 · Fireworks 0.22/0.66/0.007 · Baseten 0.30/1.20/0.03

Vendors without zero data retention, per the same payload: z.ai and Wafer on GLM 5.3 Flash, Empiriolabs on V4 Flash 0731, DeepSeek on the V4.1 family — every other vendor lists zero_data_retention: true.

The gateway's own usage.cost on a response is the authoritative bill; the headers carry x-merge-vendor (the vendor that served it) and x-merge-model (the model it resolved to). To force a vendor, send vendor in the request body or set the organization's vendor policy in the gateway dashboard.

Routing and zero data retention

The gateway picks the vendor per request, preferring the cheapest eligible one — today GLM 5.3 Flash and V4 Flash 0731 route to Particle, the two V4.1-family entries to DeepSeek's own API. Without a vendor pin there is no per-session control over where a request runs, and the default route for the V4.1 family is a vendor without zero data retention (see the vendor list above for which vendors support it). Use the organization's routing policy or vendor allow/deny lists in the gateway dashboard when a workload must stay on ZDR-capable infrastructure.

Also note the retired deepseek/deepseek-v4-flash id: the gateway resolves it to V4.1 Flash, so the response comes back as V4.1 Flash (x-merge-model: deepseek/deepseek-v4.1-flash) at V4.1 rates. Pick deepseek/deepseek-v4-flash-0731 to stay on the July snapshot.

Jev (TypeSafe) judgments in omp

omp ships a TypeSafe judge it uses for thinking-level detection, Smart unexpected-stop detection, git AI staging, and the judge() helper in eval cells. The gateway serves the same System One contract, but at /v1/decisions under the model typesafe/jev-1.13 while the client posts to /v1/systemone and defaults to jev-latest, so tools/jev-bridge.ts adapts path and model id:

MERGE_GATEWAY_API_KEY=… bun tools/jev-bridge.ts   # keep it running (loopback only)

# ~/.omp/agent/.env — omp loads this into $env at startup
TYPESAFE_BASE_URL=http://127.0.0.1:8787
TYPESAFE_API_KEY=<the same gateway key>
TYPESAFE_DEFAULT_MODEL=typesafe/jev-1.13

With the env key present, AuthStorage.hasAuth("typesafe") is satisfied, so the default providers.judgmentProvider: auto sends those judgments to Jev through the gateway instead of the tiny/smol chat fallback. Jev is not a chat model — it never appears in /model, and chat side requests (titles, compaction) are unaffected. Billing is $0.042/M input tokens with output free; omp's ledger shows $0 for these calls because the judgment usage mapper reads token counts, not the gateway's usage.cost.

The bridge is repo-local tooling; the npm tarball ships dist, README.md and LICENSE only.

Endpoint

POST https://api-gateway.merge.dev/v1/openai/responses
Authorization: Bearer <MERGE_GATEWAY_API_KEY>

Test

bun test