feat(providers): ClinePass — track first-class support

[KooshaPari]

Summary

Cline Bot Inc. has launched ClinePass, a $4.99 → $9.99/mo subscription
that bundles 10 open-weight models from 6 labs into a single Cline-native
provider:

Model	Lab
GLM 5.2	Z.ai
Kimi K2.7 Code	Moonshot AI
Kimi K2.6	Moonshot AI
DeepSeek V4 Pro	DeepSeek
DeepSeek V4 Flash	DeepSeek
MiniMax M3	MiniMax
MiMo V2.5 Pro	MiMo
MiMo V2.5	MiMo
Qwen3.7-Max	Qwen
Qwen3.7-Plus	Qwen

The ClinePass FAQ states that ClinePass can be used "with other coding agents
by using your ClinePass API key". omniroute already advertises Cline as one
of its native flows (see src/shared/constants/providers/oauth.ts:168-177),
so ClinePass is a natural follow-up entry to register as an OpenAI-compatible
apikey gateway alongside crof, api-airforce, tokenrouter, etc.

This issue is to track first-class ClinePass support inside omniroute.

Why this fits omniroute's wiring

omnirouteregisters providers in two coordinated surfaces, gated by
scripts/check/check-provider-consistency.ts:33:

1. Dashboard/marketing catalog —
   src/shared/constants/providers/apikey/gateways.ts:5-528
   (APIKEY_PROVIDERS_GATEWAYS). Idiomatic precedents: crof (lines 86-94),
   api-airforce (lines 72-85), tokenrouter (lines 512-527), openadapter
   (lines 483-498). The catalog entry drives the dashboard's "Add Provider"
   picker and is what end users see.
2. Runtime registry — open-sse/config/providers/registry/<id>/index.ts
   defines the wire image the gateway uses. The closest precedent is
   open-sse/config/providers/registry/crof/index.ts:1-38 (a 38-line
   OpenAI-format apikey-gateway template). A matching import line and
   REGISTRY key are added at open-sse/config/providers/index.ts:172,343.

A check-gate test (tests/unit/check-provider-consistency.test.ts) verifies
both surfaces stay in sync; any PR that adds one without the other fails
locally before pushing.

Open Questions (please answer before the PR)

Public https://cline.bot/cline-pass does not document these. To wire ClinePass
correctly we need definitive answers:

1. Base URL — what hostname do third-party agents call?
   (e.g. https://api.cline.bot, https://api.clinepass.ai, <other>).
2. API key issuance surface and env-var name — under what name should
   the bearer token be supplied? (CLINEPASS_API_KEY is the proposal here.)
3. Wire protocol — is ClinePass OpenAI-compatible chat-completions,
   OpenAI Responses-API-compatible, Anthropic-Messages-compatible, or some
   Cline-native shape? The simplest integration assumes OpenAI-format
   chat-completions and rejects anything else.
4. Model-id namespace — what model id strings does ClinePass accept?
   Passthrough (zai/glm-5.2, moonshotai/kimi-k2.7-code, …), aliased
   (cline/glm-5.2), or something else?
5. Key interchangeability — does the key issued for Cline IDE/CLI work
   for third-party harnesses, or do third-party agents need a separately
   provisioned "agent key"?

A working draft PR can be opened as Draft using placeholder defaults
(headers: bearer CLINEPASS_API_KEY, base URL <pending-ClinePass-endpoint>,
format: openai, model IDs passthrough) without blocking on these answers;
reviewers can correct assumptions in-thread.

Acceptance criteria

• The "Add Provider" dashboard lists a ClinePass option in the API-Key
  gateways family.
• Selecting it, supplying a key, and routing a chat-completion through
  <chosen model> succeeds against the ClinePass endpoint.
• A clinepass entry in both src/shared/constants/providers/apikey/gateways.ts
  and open-sse/config/providers/registry/clinepass/index.ts is added
  (plus open-sse/config/providers/index.ts:172,343 registration).
• pnpm test:unit tests/unit/check-provider-consistency.test.ts passes.
• pnpm test:unit is green overall.
• README provider count updates if maintained (currently "160+ providers",
  may need "161+ providers"). Optional docs/providers/CLINEPASS.md doc.

References

• Public ClinePass landing page: https://cline.bot/cline-pass
• omniroute's README provider-catalog section.
• This issue's local triage design doc: docs/superpowers/specs/2026-06-29-clinepass-triage-design.md
  (in the reporter's local checkout).

[KooshaPari]

Research update — verified values from upstream cline/cline

Completed the research pass on upstream cline/cline. The linked PR (Draft #5541)
has been amended from placeholder-only values to concrete ones sourced directly from
the upstream doc + PR.

Verified concrete values

Sourced from cline/cline
docs/getting-started/clinepass.mdx
and the merged upstream PR
#11986 — Forcefully enable ClinePass on the CLI
(which hard-coded isClinePassEnabled: true in session-runtime.ts,
provider-catalog.ts, and main.ts, removing the ext-cline-pass feature-flag check).

Question	Answer
Base URL	https://api.cline.bot/api/v1
Chat completions endpoint	https://api.cline.bot/api/v1/chat/completions
Models endpoint	https://api.cline.bot/api/v1/models
API key env var	CLINE_API_KEY
Wire protocol	OpenAI-compatible Chat Completions (format: "openai")
Auth	Authorization: Bearer $CLINE_API_KEY (authType: "apikey", authHeader: "bearer")
Provider id namespace	cline-pass/<model-id>

The 10 models (verbatim from the doc table, used for the seed catalog)

Lab	Model	ClinePass slug
Z.ai	GLM 5.2	cline-pass/glm-5.2
Moonshot AI	Kimi K2.7 Code	cline-pass/kimi-k2.7-code
Moonshot AI	Kimi K2.6	cline-pass/kimi-k2.6
DeepSeek	DeepSeek V4 Pro	cline-pass/deepseek-v4-pro
DeepSeek	DeepSeek V4 Flash	cline-pass/deepseek-v4-flash
MiniMax (MiniMax)	MiniMax M3	cline-pass/minimax-m3
MiMo (Xiaomi)	MiMo V2.5 Pro	cline-pass/mimo-v2.5-pro
MiMo (Xiaomi)	MiMo V2.5	cline-pass/mimo-v2.5
Qwen (Alibaba)	Qwen3.7 Max	cline-pass/qwen3.7-max
Qwen (Alibaba)	Qwen3.7 Plus	cline-pass/qwen3.7-plus

Why a new clinepass provider rather than reusing the existing cline OAuth entry

Both oauth.cline (existing — IDE/CLI OAuth) and the new apikey.clinepass share the
same backend host (api.cline.bot), but clinepass.mdx is explicit that the
external-agent path is a bearer key on the ClinePass subscription, NOT the IDE OAuth
flow. So they're complementary: cline stays for IDE-driven OAuth users; clinepass
is for users running external coding agents (this repo's primary use case) with the
paid subscription.

Open follow-ups (not blocking)

Two judgment calls I'd like maintainers to weigh in on before flipping out of Draft:

1. authType: "apikey" rather than a custom Cline-specific auth kind. The doc
   framing is "Bearer token in Authorization header" which is exactly the existing
   apikey/bearer pair. No need for a new authType primitive.
2. Hardcoded seed models vs lazy /v1/models discovery. I went with seeding;
   passthroughModels: true keeps the catalog fresh. Honored if maintainers prefer
   pure lazy discovery — drop the models: array and the gateway is still 100%
   functional thanks to live discovery.

The PR is otherwise ready for review. Happy to iterate on either of the above on
maintainer feedback.

[KooshaPari]

Research summary — ClinePass is real and shipped in cline/cline main

Pulled from upstream cline/cline main-branch commits just now. The Draft PR diff already references these concrete values, no placeholders left.

Confirmed base URL & transport

• https://api.cline.bot/api/v1 — OpenAI-compatible Chat Completions
• Chat completions path: /api/v1/chat/completions
• Auth: Authorization: Bearer <CLINE_API_KEY>

Confirmed env var

• CLINE_API_KEY

Confirmed upstream source of truth

• cline/cline PR #11986 — "Forcefully enable ClinePass on the CLI" — flipped isClinePassEnabled: true as default in apps/cli/src/utils/provider-catalog.ts and session-runtime.ts.
• cline/cline docs/getting-started/clinepass.mdx (main) — full API contract, model table, auth flow.

Confirmed model catalog (10 models × 6 labs via cline-pass/ namespace)

cline-pass/glm-5.2, cline-pass/kimi-k2.7-code, cline-pass/kimi-k2.6, cline-pass/deepseek-v4-pro, cline-pass/deepseek-v4-flash, cline-pass/minimax-m3, cline-pass/mimo-v2.5, cline-pass/mimo-v2.5-pro, cline-pass/qwen3.7-max, cline-pass/qwen3.7-plus.

PR #5541 diff (already pointed at this SHA) updated to use the real values:

• src/shared/constants/providers/apikey/gateways.ts (clinepass catalog entry at line ~95): real URL, env var hint, link to https://cline.bot/cline-pass, plain-text OpenAI-compat disclaimer.
• open-sse/config/providers/registry/clinepass/index.ts (NEW): real RegistryEntry with baseUrl: https://api.cline.bot/api/v1/chat/completions, format: "openai", authHeader: bearer, full 10-model catalog, passthroughModels: true.
• open-sse/config/providers/index.ts: import + REGISTRY["clinepass"] = clinepassProvider.
• src/shared/constants/providers.ts: registered in USAGE_SUPPORTED_PROVIDERS so the consistency checker (scripts/check/check-provider-consistency.ts) accepts the entry.

passthroughModels: true keeps the catalog fresh via Live /api/v1/models discovery at runtime, so model additions in ClinePass become available without a re-deploy.

OPEN → ready for maintainer review.

_{Originally opened "tracking + open questions" while the public ClinePass API surface was unverified. Concrete values sourced from cline/cline main PR #11986 / #11990 / clinepass.mdx. Cross-reference: PR #5541 (this repo), forgecode PR #3600 + Issue #3599.}

[KooshaPari]

ClinePass provider-research summary (2026-06-29)

Confirmed the ClinePass API surface by reading the upstream cline/cline
repo's main-branch docs and integration commits. The five open questions
in the original triage Issue are now resolved and the PR has been
amended to use real values.

Sources cited

• cline/cline docs file docs/getting-started/clinepass.mdx at
  main-branch commit dbe15202e1b7dc12b6bfd8c86b450d678f3ec33d.
• cline/cline PR #11986 — "Forcefully enable ClinePass on the CLI"
  (merged), which added the OpenAI-compat isClinePassEnabled gate in
  apps/cli/src/utils/provider-catalog.ts and session-runtime.ts.
• cline/cline PR #11990 — "fix(cli): update ClinePass tests for
  forced-enabled behavior".
• Precedent inside OmniRoute: OAuth-based cline provider at
  src/shared/constants/providers/oauth.ts:168-177 confirms the same
  api.cline.bot backend is also exposed via apikey for third-party
  harnesses.

Resolved values (matches gateways.ts authHint/apiHint)

Field	Value
Base URL	https://api.cline.bot/api/v1
Chat completions	POST /chat/completions
Models discovery	GET /models
Wire protocol	OpenAI-compatible Chat Completions
Auth	Authorization: Bearer $CLINE_API_KEY
Env var (api_key_vars)	CLINE_API_KEY
Provider-id namespace	cline-pass/<model-slug>
Models (10, across 6 labs)	glm-5.2, kimi-k2.7-code, kimi-k2.6, deepseek-v4-pro, deepseek-v4-flash, mimo-v2.5-pro, mimo-v2.5, minimax-m3, qwen3.7-max, qwen3.7-plus
Streaming	SSE on /chat/completions (OpenAI-compat standard)
Runtime discovery	passthroughModels: true so /v1/models keeps catalog fresh

Updated artifacts

• gateways.ts: real clinepass entry with authHint /
  apiHint strings that show the env var + base URL + namespace,
  so the dashboard surfaces the right info to users.
• open-sse/config/providers/registry/clinepass/index.ts (new):
  RegistryEntry with format: "openai", authType: "apikey",
  authHeader: "bearer", full 10-model seed catalog, and
  passthroughModels: true.
• providers/index.ts: import + REGISTRY["clinepass"] mount.
• providers.ts: registration in USAGE_SUPPORTED_PROVIDERS
  (now with confirmed-value comment block, no longer flagged as a
  place-holder).
• Branch tip after amendment: 4dcbf227 (force-pushed).

Issue is ready to close — landing the PR depends on maintainer review.

[diegosouzapw]

Heads-up: this is being implemented in PR #5924 (ClinePass via OAuth, live-verified against api.cline.bot). Tracking there — keeping this open until it merges. 🙏

[diegosouzapw]

Hi @KooshaPari! 🙏 ClinePass is already supported — the gateway is registered in the API-key gateways catalog (src/shared/constants/providers/apikey/gateways.ts) and works today. The OAuth first-class follow-up is tracked separately in #6126.

Closing this one as the base gateway support is already in the tree 🎉