pi-sicau-pmt

Pi provider for a self-hosted oh-pmt-api gateway (OpenAI-compatible): dynamic per-key model discovery, thinking-effort support for every published model, and a /login API-key prompt

Packages

Package details

extension

Install pi-sicau-pmt from npm and Pi will load the resources declared by the package manifest.

$ pi install npm:pi-sicau-pmt
Package
pi-sicau-pmt
Version
0.4.0
Published
Nov 3, 2026
Downloads
345/mo · 345/wk
Author
craigkettleman
License
MIT
Types
extension
Size
25.8 KB
Dependencies
0 dependencies · 1 peer
Pi manifest JSON
{
  "extensions": [
    "./src/index.ts"
  ]
}

Security note

Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.

README

pi-sicau-pmt

Pi provider for a self-hosted oh-pmt-api gateway (OpenAI-compatible). Adds the gateway's models to Pi with correct context windows, output limits and thinking-effort tables, and asks for the API key through /login instead of hand-editing config files.

Install

pi install npm:pi-sicau-pmt

Then log in:

/login

Pick SICAU-PMT, paste your gateway API key. It is stored in ~/.pi/agent/auth.json as an api_key credential for the sicau-pmt provider.

To try it without installing:

pi -e npm:pi-sicau-pmt

What it registers

The model list comes from the gateway's /v1/models at startup, using the API key you logged in with. Two keys can see different subsets — the gateway filters the catalog by the member's model allowlist — so a model you cannot use simply does not appear. Models added to the gateway show up in Pi without editing this package.

Model Context Output Thinking effort Image input
Qwen-3.8-Flash 180K 64000 low / medium / xhigh no
Qwen-3.8-Max 180K 64000 low / medium / xhigh no
GLM-5.3-Flash 1M 131072 low / high / max yes
GLM-5.3 1M 64000 low / high / max yes
DeepSeek-V4.1-Flash 1M 128000 low / high / max, off yes
DeepSeek-V4-Pro 1M 128000 high / xhigh / max, off yes
Kimi-K3 1M 32000 low / high / xhigh, off yes
Kimi-K3.1-Pro 1M 32000 low / high / max yes
Kimi-K2.8-Preview 1M 64000 low / high / max yes
MiniMax-M3.1-Flash 1M 128000 low / medium / high / xhigh / max yes
Xiaomi MiMo-V2.6-Pro 1M 128000 low / medium / high yes
Hy3 192K 64000 low / high yes
Hy4 preview 960K 64000 high yes
Step-5-Preview 1M 64000 low / medium / high yes
Space-Bunny 1M 128000 low / medium / high / xhigh / max yes

The gateway also publishes a <model>-free variant of some models — the same model routed through a free channel. Lookup strips that trailing -free and falls back to the base model's entry, so both ids offer the same effort list instead of the free one dropping to the fallback.

Free variants are live, not a fixed list: the gateway only publishes one while some upstream account is actually serving that model, and withdraws it after failing health checks. The catalog cache is therefore one minute instead of five, and a shorter list from the gateway is treated as the new truth rather than as an error — only a failed request keeps the previous catalog.

The table covers every model the gateway can publish, not just the ones the current key sees. When the same display name is served by both Qoder and WorkBuddy, the entry takes the lower of the two output limits (exceeding it is an upstream error) and the union of the two effort lists; the gateway normalizes the effort again for whichever provider actually runs the request.

compat.supportsDeveloperRole is disabled on every model: Qoder validates message roles and rejects anything outside system / assistant / user / tool.

Model names come straight from the gateway: an id listed as DeepSeek-V4.1-Flash is registered with exactly that name, so the picker and the Model Name: footer always agree with what the gateway publishes. No aliasing happens in this package.

The gateway's /v1/models publishes no effort metadata, so effort tables live in src/models.ts. Lookup normalizes the name (case, spaces, dashes, dots, underscores and slashes are ignored) and tries the model id first, then upstream_key, so Qwen-3.8-Flash, Qwen3.8-Flash and qfmodel all land on the same entry. The table's context windows and output limits come from Qoder's official catalog and WorkBuddy's product config, used only when the gateway does not publish its own; effort tables come from the vendors' declared effort lists.

A model missing from the table still appears and still thinks: the fallback registers it as a reasoning model with low / medium / high and conservative length limits. Getting this wrong the other way — declaring a thinking model non-reasoning — silently disables the effort selector, which is the failure people actually notice.

The catalog is cached per API key for one minute. If the gateway is unreachable, the last good catalog is kept rather than falling back to the built-in six, so models only your key can see do not disappear on a transient network error.

Context windows and output limits come from the gateway's context / max_output fields when it publishes them, and from src/models.ts otherwise. A new model the gateway starts serving therefore gets correct length limits without a new release; only its effort levels fall back to low / medium / high until the table learns about it.

Point it at your own gateway

BASE_URL in src/index.ts is pinned to https://api.hhy.homes/v1. To use a different deployment, fork this package, change BASE_URL, and adjust the capability table in src/models.ts for your models.

Requirements

  • Pi 1.4.0 or newer — the model list is refreshed through ProviderConfig.refreshModels.
  • A gateway that forwards reasoning_effort and reads max_completion_tokens. Gateways without that plumbing still work, but the thinking selector has no effect and the output limit falls back to the server default.

License

MIT