pi-clinepass

Use ClinePass models (GLM-5.2, Kimi K2.7, DeepSeek V4, Qwen3.7, MiniMax M3) in Pi. Log in with a browser device code, pick a model, start coding.

Capabilities

• WorkOS device-code OAuth with Cline token registration and refresh
• Live ClinePass model discovery with static fallback metadata
• Per-model context windows, output limits, reasoning settings, and thinking maps
• Prompt-cache and reasoning compatibility for the ClinePass gateway
• Provider id clinepass; transport openai-completions at https://api.cline.bot/api/v1
• Credentials stored by Pi; requests use Authorization: Bearer workos:<access>

Primary model: glm-5.2.

Install locally

From npm:

pi install npm:@codewithkenzo/pi-clinepass

From GitHub:

pi install git:github.com/codewithkenzo/pi-clinepass

From a checkout:

bun install
bun run typecheck
bun test
pi install .

Or add a local checkout manually to ~/.pi/agent/settings.json:

{
  "packages": ["../../dev/pi-clinepass"]
}

Then restart Pi or run /reload.

Login + use

In Pi:

1. Run /login
2. Choose ClinePass
3. Open the browser/device URL and enter the shown code
4. Run /model
5. Pick clinepass/glm-5.2

Exact model string for CLI/non-interactive runs:

pi --model clinepass/glm-5.2 "Say OK"

How it works

1. /login starts a WorkOS OAuth device authorization request.
2. Pi shows a verification URL and one-time device code.
3. Open the URL, enter the code, approve access.
4. The extension polls WorkOS until authorization completes.
5. WorkOS tokens register with Cline auth; Pi receives OAuth credentials.
6. Later requests use refreshed Cline access tokens.

Wire-level detail:

1. WorkOS device auth with Cline's production client id
2. Poll WorkOS until approved
3. POST /api/v1/auth/register with WorkOS tokens
4. POST /api/v1/auth/refresh when access is near expiry
5. Requests use Authorization: Bearer workos:<access>

Access and refresh tokens are never logged.

Model discovery

The extension fetches:

https://api.cline.bot/api/v1/ai/cline/recommended-models

It reads clinePass[], dedupes model ids, then enriches context/output limits from OpenRouter's public model catalog by model slug. A static table covers known ClinePass models when OpenRouter omits fields. If the live list fails, the extension falls back to the static set and writes a stderr notice.

Known models:

Model	Context window	Max output tokens	Reasoning
glm-5.2	1,048,576	131,072	Yes
qwen3.7-max	1,000,000	65,536	Yes
qwen3.7-plus	1,000,000	65,536	Yes
kimi-k2.7-code	262,144	16,384	Yes
deepseek-v4-pro	1,048,576	384,000	Yes
deepseek-v4-flash	1,048,576	65,536	Yes
minimax-m3	1,048,576	512,000	Yes

ClinePass compatibility

Each model is registered with:

{
  api: "clinepass:openai-completions",
  input: ["text"],
  contextWindow: 1_000_000, // per-model from vendor docs
  maxTokens: 131_072,       // per-model from vendor docs
  reasoning: true,
  compat: {
    thinkingFormat: "together",
    cacheControlFormat: "anthropic",
    supportsUsageInStreaming: true,
    supportsReasoningEffort: true,
    supportsStore: false,
    supportsDeveloperRole: false,
    maxTokensField: "max_tokens"
  }
}

Why thinkingFormat: "together":

• ClinePass accepts top-level reasoning objects.
• ClinePass honors { reasoning: { enabled: false } }.
• It does not treat { reasoning: { effort: "none" } } as disabled.
• z.ai-native thinking: { type: "disabled" } is also ignored by ClinePass.

Development

bun install
bun run typecheck
bun run lint
bun run lint:type-aware
bun run format:check
bun run quality:sentinel
bun test
bun run package:contract
bun run clean-room

package:contract packs the real npm artifact, installs production dependencies in an isolated consumer, and loads it through Pi without credentials. clean-room is mandatory and requires Podman; it runs packed-artifact smoke tests against official Pi 0.73.1 and Earendil Pi 0.80.6.

Useful smoke test after local install:

pi --model clinepass/glm-5.2 -p "Reply exactly OK"

If it says No API key found for clinepass, the extension loaded; run /login.

Package surface

Pi loads this package through:

{
  "pi": {
    "extensions": ["./src/index.ts"]
  }
}

Runtime entrypoint: src/index.ts.

Maintainer release setup

Runtime updates run weekly from .github/workflows/update-runtime.yml. Configure RUNTIME_UPDATE_TOKEN as a fine-grained personal access token or GitHub App token with repository Contents: read/write and Pull requests: read/write. GitHub's default workflow token is not used because pull requests created by it do not trigger pull_request CI. The updater keeps one automation/pi-ai-runtime branch, pins an exact runtime version only when npm latest is newer, and never downgrades or auto-merges; full CI and review remain required.

npm publication uses trusted publishing (OIDC) from .github/workflows/publish.yml; do not add an NPM_TOKEN. Configure that repository/workflow as the trusted publisher in npm. Create a published GitHub release only when its tag exactly matches v${package.version} (for this release, v0.1.1). The workflow runs reusable full CI before publish, then polls npm and verifies public metadata, tarball integrity, production installation, and a no-auth official Pi smoke test.