Feat/opencode zen provider

[snail-vs]

Summary

Testing

• [ * ] cargo fmt --all -- --check
• [ * ] cargo clippy --workspace --all-targets --all-features
• [ * ] cargo test --workspace --all-features

Checklist

• [ * ] Updated docs or comments as needed
• [ * ] Added or updated tests where relevant
• [ * ] Verified TUI behavior manually if UI changes
• [ * ] Harvested/co-authored credit uses a GitHub numeric noreply address

[github-actions]

Thanks @snail-vs for taking the time to contribute.

This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered.

Please read CONTRIBUTING.md for the expected contribution shape. A maintainer can grant recurring PR access by commenting /lgtm on a pull request.

[Hmbown]

Thanks @snail-vs. I am not taking the OpenCode Zen provider PR into 0.8.67 as-is because it is blocked/conflicting and touches provider routing/configuration across several crates. I am cutting 0.8.67 soon; after that, please rebase for 0.8.68 and we can review the provider integration carefully rather than rush it.

[Hmbown]

Thanks for this — it's a thorough, pattern-faithful addition: ProviderKind/ApiProvider variants, the registry count bumps (30→31), every match arm, defaults, env overrides, the two provider-metadata tests updated for the Responses wire, and docs/config example. It also correctly leaves DeepSeek support untouched.

One correctness issue worth fixing before merge:

Missing-credentials message misdirects OpenCode Zen users. In crates/tui/src/config.rs the missing-key bail now groups OpenCode Zen with OpenAI Codex:

ApiProvider::OpenaiCodex | ApiProvider::OpenCodeZen => anyhow::bail!(
    "OpenAI Codex OAuth credentials not found.\n ... CodeWhale uses your existing ChatGPT/Codex login ..."
)

But everywhere else in the PR OpenCode Zen is treated as an API-key provider (OPENCODE_ZEN_API_KEY/OPENCODE_API_KEY, the has_api_key_for / active_provider_has_config_api_key additions, the config-example "copy your API key"). So a user who selects opencode-zen without a key is told to log in via ChatGPT/Codex OAuth, which doesn't apply. Please give OpenCode Zen its own message pointing at OPENCODE_ZEN_API_KEY / [providers.opencode_zen] api_key (mirroring the other Chat/Responses API-key providers) rather than reusing the Codex OAuth text.

Everything else looks good to me. Flagging for @Hmbown's merge decision.

---

Generated by Claude Code

[Hmbown]

Config-lane unblock (2026-07-08) — parked for careful 0.8.68 rebase

Per maintainer note on this PR (2026-07-03): OpenCode Zen was deferred out of 0.8.67 and should be rebased for 0.8.68 for careful review, not rushed through the conflicting provider surface.

Why this stays open but is no longer a catalog gate

• Still dirty vs current main (conflicts across crates/config provider_kind/provider/defaults/lib + TUI wiring + docs).
• Sibling conflicting PR v0.8.67: LongCat provider + post-#3960 review follow-ups + version bump #4034 is being closed as superseded (LongCat/0.8.67 already on main), so the mutual crates/config contention is cleared from the catalog lane's perspective.
• Catalog work (Normalize Models.dev provider IDs onto CodeWhale provider kinds #4186→Demote curated bundled model data after Models.dev live catalog lands #4188) does not depend on adding OpenCode Zen.

Rebase notes for whoever picks this up (grounded in review + upstream docs)

1. Fix the missing-credentials message called out in review: OpenCode Zen is an API-key provider (OPENCODE_ZEN_API_KEY / [providers.opencode_zen] api_key), not Codex OAuth — do not share the OpenaiCodex bail text.
2. Upstream Zen (opencode.ai/docs/zen) is a multi-protocol gateway (/responses, /messages, /chat/completions depending on model). The current PR pins WireFormat::Responses + base https://opencode.ai/zen/v1 — that needs an explicit product decision on 0.8.68 (single Responses default vs per-model wire), not a blind conflict resolution.
3. Live Models.dev (2026-07-08) has opencode / opencode-go keys, not a dedicated opencode-zen id — catalog normalization for Zen is separate from this provider PR.
4. Related product ask: Support OpenCode Go/Zen please, it provides DeepSeek-V4 as well. #1481.

Leaving open for the harvest/provider lane; catalog agents should not block on it.

Refs #4092, #1481.