omp packages

pi-mixlayer0.4.0

Mixlayer provider extension for pi.

zackangelo Published 4 months ago ~836 downloads/mo

Untested on omp

This is a pi package. No one has reported whether it works on omp yet. If you try it, add your result below.

Did it work for you?

Result

One report per person. A new report replaces your old one.

Reports 0

No reports yet.

Readme

pi Mixlayer Extension

Registers Mixlayer as a pi provider using Mixlayer's OpenAI-compatible APIs.

Usage

pi install npm:pi-mixlayer
pi

Inside pi, run:

/login

Select Use an API key, then choose Mixlayer from the provider list. Enter your Mixlayer API key when prompted. Pi stores the credential in ~/.pi/agent/auth.json.

The extension fetches the current model list from:

https://models.mixlayer.ai/_openrouter/models

It registers the models under the mixlayer provider with baseUrl: "https://models.mixlayer.ai/v1". By default, models use Pi's OpenAI-compatible Chat Completions transport.

The model list is cached in ~/.pi/agent/mixlayer-models-cache.json for one hour to avoid repeated API requests. If the cache has expired and the network request fails, the extension falls back to the stale cache so pi still starts with available models.

Run pi --list-models to verify the registered models after installation.

When Mixlayer auth is configured and no model is selected yet, the extension selects qwen/qwen3.5-397b-a17b as the preferred default if that model is present in the remote model list.

Transport Selection

The extension supports configurable transport selection for the mixlayer provider:

Transport Status Behavior
chat-completions Default Uses Pi's openai-completions transport.
responses-sse Supported Uses Mixlayer's Responses API over HTTP/SSE through a Mixlayer-specific wrapper around Pi's Responses transport.
responses-websocket Supported Uses Mixlayer's Responses API over WebSocket with full context sent on every turn.
responses-websocket-delta Supported Uses Mixlayer's Responses API over WebSocket with session-cached previous_response_id deltas when safe, falling back to full context otherwise.

Transport resolution order is:

  1. MIXLAYER_TRANSPORT environment variable
  2. ~/.pi/agent/mixlayer-settings.json, written by /mixlayer-transport
  3. chat-completions

For a one-off run:

MIXLAYER_TRANSPORT=responses-sse pi

For a persistent setting inside Pi:

/mixlayer-transport responses-sse

Then reload extensions or restart Pi for the new transport to take effect. Run /mixlayer-transport with no argument to show the current configured transport.

The Responses transports strip Mixlayer-incompatible request fields before sending and disable Pi's session_id request header, which Mixlayer rejects. They still send x-client-request-id for request affinity. The responses-websocket transport sends the full conversation context each turn. The responses-websocket-delta transport first builds the full request, then sends a delta only when the current request is an exact append-only continuation of the cached previous request and response.

Stats Counters

Run this inside Pi to print in-memory Mixlayer counters for the current extension process:

/mixlayer-stats

The output includes Mixlayer turn counts, logical provider request counts, HTTP response status counts, and WebSocket full/delta request attempts. delta_requests and delta_hit_rate show whether the WebSocket delta path is being used.

Reset counters with:

/mixlayer-stats reset

Debug Logging

Set MIXLAYER_DEBUG_LOGS=1 to write provider request/response debug logs to:

  • /tmp/mixlayer-debug.log
  • /tmp/mixlayer-response.log

Logging is disabled by default.