Problem / motivation
open·kritt currently supports Codex, Claude, and OpenRouter as model-access providers. OpenCode Zen is a curated AI gateway offering pay-per-use access to Claude, GPT-5.x-codex, and other models through a single API key, but there is no way to configure or use it in open·kritt today.
Proposed solution
Add opencode as a fourth model provider, following the same pattern OpenRouter already uses:
- A single
OPENCODE_API_KEY bearer token, configurable via ./kritt setup, the Accounts page, or .env.
- Support both the Claude Code harness (via OpenCode Zen's Anthropic-compatible endpoint at
https://opencode.ai/zen, reaching its claude-*/qwen* models) and the Codex harness (via its OpenAI Responses-API endpoint at https://opencode.ai/zen/v1, reaching its gpt-*/gpt-5.x-codex models). Unlike OpenRouter, OpenCode Zen splits its model families across two separate, wire-incompatible endpoints, so harness and model family are coupled for this provider.
- Background model-catalog auto-refresh from
https://opencode.ai/zen/v1/models, filtered to the two reachable families (that endpoint has no display name or reasoning metadata, unlike OpenRouter's catalog).
- A clear engine-side error when a harness/model-family pair is mismatched (e.g. a
gpt-* model on the Claude Code harness), instead of an opaque upstream HTTP failure.
- A new
docs-site/ai-provider-setup/opencode-zen.mdx guide, mirroring the existing OpenRouter guide.
Which area
workflows / scanning (the change spans engine, backend, frontend, and CLI, since it changes which models a scan can use and how they're configured)
Alternatives considered
- Single-harness support (Claude Code or Codex only) — rejected because OpenCode Zen's GPT-5.x-codex models are only reachable via Codex, and its Claude models only via Claude Code; limiting to one harness would arbitrarily exclude half of what the provider offers.
- A generic "custom OpenAI-compatible endpoint" abstraction instead of a bespoke provider — rejected as a much larger refactor of how all three existing providers are wired; out of scope for this change.
- Free-text model IDs only, no catalog auto-fetch — rejected in favor of matching OpenRouter's existing UX (searchable catalog with a free-text fallback).
Additional context
- OpenCode Zen docs: https://opencode.ai/docs/zen/
- OpenCode Zen also serves other model families (Grok, DeepSeek, GLM, Kimi, MiniMax, Gemini, and some free models) over an OpenAI-compatible
/v1/chat/completions endpoint and Google-specific paths that neither the Codex nor Claude Code harness speaks today. Those are out of scope for this change and would need separate follow-up work; the catalog fetcher filters them out rather than surfacing them as broken choices.
Problem / motivation
open·kritt currently supports Codex, Claude, and OpenRouter as model-access providers. OpenCode Zen is a curated AI gateway offering pay-per-use access to Claude, GPT-5.x-codex, and other models through a single API key, but there is no way to configure or use it in open·kritt today.
Proposed solution
Add
opencodeas a fourth model provider, following the same pattern OpenRouter already uses:OPENCODE_API_KEYbearer token, configurable via./kritt setup, the Accounts page, or.env.https://opencode.ai/zen, reaching itsclaude-*/qwen*models) and the Codex harness (via its OpenAI Responses-API endpoint athttps://opencode.ai/zen/v1, reaching itsgpt-*/gpt-5.x-codexmodels). Unlike OpenRouter, OpenCode Zen splits its model families across two separate, wire-incompatible endpoints, so harness and model family are coupled for this provider.https://opencode.ai/zen/v1/models, filtered to the two reachable families (that endpoint has no display name or reasoning metadata, unlike OpenRouter's catalog).gpt-*model on the Claude Code harness), instead of an opaque upstream HTTP failure.docs-site/ai-provider-setup/opencode-zen.mdxguide, mirroring the existing OpenRouter guide.Which area
workflows / scanning (the change spans engine, backend, frontend, and CLI, since it changes which models a scan can use and how they're configured)
Alternatives considered
Additional context
/v1/chat/completionsendpoint and Google-specific paths that neither the Codex nor Claude Code harness speaks today. Those are out of scope for this change and would need separate follow-up work; the catalog fetcher filters them out rather than surfacing them as broken choices.