Serve GPT 5.6+ in OpenCode through the Responses API

[mats16]

What changed and why?

ug opencode never exposed GPT models: the generated opencode.json only had databricks-anthropic, databricks-google, and databricks-oss. This adds a fourth provider, databricks-openai, that talks to the Responses API (@ai-sdk/openai → <workspace>/ai-gateway/codex/v1) and serves GPT 5.6 and newer only:

• gpt-6-1-sol, gpt-6-sol, gpt-6-luna, gpt-6-astra
• gpt-5-6-sol, gpt-5-6-terra, gpt-5-6-luna

Older GPT models (≤ 5.5) stay hidden on purpose, because the OpenCode problems reported against them (#85, #99) have not been re-checked. Dated snapshot IDs such as gpt-5-2025-08-07 and gpt-oss-* are also excluded.

Changes:

• agents/opencode.py:
  • add the databricks-openai provider, with the per-model User-Agent header and the token-refresh auth plugin wired the same way as the other providers;
  • add opencode_gpt_models(), the 5.6+ filter;
  • add build_opencode_models(), so configure and status build the provider buckets with the same code.
• cli.py: configuring opencode now also discovers codex/GPT models.
• databricks.py: build_opencode_base_urls() now returns an openai entry.
• managed_resolve.py: GPT 5.6+ models in a managed config's model list now go to the openai bucket instead of being dropped.
• The default model order stays anthropic → gemini → openai → oss, so workspaces that have Claude keep the same default.

Existing users see the GPT models after running ug configure again. Older state has no openai bucket, which is harmless.

Why this works now (and didn't in #85)

The last investigation (#85, OpenCode 1.15.11) found both wire formats broken. I re-tested on the current gateway:

Problem reported earlier	Current result with GPT 5.6+
Responses SSE stream lacked content_part.added, so OpenCode failed with text part … not found (#85)	The event is present: output_item.added → content_part.added → output_text.delta
Responses ID was 193 chars, over OpenAI's 64-char limit, so turn 2 returned 400 (#99)	IDs are 53–55 chars
Chat Completions rejects reasoningSummary (#85)	Not used here. Chat Completions via /ai-gateway/mlflow/v1 still fails, now with Parameter 'store' is not supported, which is why this PR uses Responses

How this differs from related issues and PRs

• Opencode Model Configuration #85 / ucode opencode adapter omits databricks-openai provider — opencode loses access to GPT-5 / Codex Responses models #97 / Add Opencode support for OpenAI models #154: the feature requests. ucode opencode adapter omits databricks-openai provider — opencode loses access to GPT-5 / Codex Responses models #97 and Add Opencode support for OpenAI models #154 were closed as duplicates of Opencode Model Configuration #85. This PR addresses Opencode Model Configuration #85 for GPT 5.6+ models.
• Surface OpenAI models in Opencode #167 (Surface OpenAI models in Opencode): the same basic wiring, but it exposes every codex model, including GPT ≤ 5.5, which was never validated, and it doesn't touch managed-config bucketing. This PR limits the provider to 5.6+, covers managed configs, and is based on current main, including the --model support from Support per-launch model selection for OpenCode #834.
• fix(opencode): route GPT models and discover OSS fallbacks #239 / feat(opencode): route Responses models natively #450 (dgokeeffe stacks): broader changes (OSS fallback discovery, shared context limits, Pi changes) that depend on several unmerged PRs (feat(pi): add validated GLM/Kimi MLflow provider #217, fix(pi): omit unsupported GPT off-reasoning effort #223, fix: centralize Claude and GPT context capabilities #333, fix(pi): use native Responses models safely #446). This PR is standalone and limited to OpenCode + GPT. It doesn't set context/output limit for GPT models; that can come later if needed.
• Expose compatible models through matching OpenCode providers #816 (closed, replaced by Support per-launch model selection for OpenCode #834): expanded OpenCode discovery to more OSS/compatible services. Not related to GPT/Responses.
• Managed config model_services ignored for pi and opencode #894: a separate bug. Managed model_config.model_services lists are ignored for pi/opencode. This PR doesn't fix it; it only makes GPT 5.6+ bucketable once that list reaches _bucket_by_provider.
• Multi-turn GPT-5 conversations fail through ucode + stock OpenCode — Databricks Responses returns itemIds >64 chars that OpenAI rejects on echo #99: does not reproduce on GPT 5.6+ (see the table above). GPT ≤ 5.5 stays excluded, so this PR does not close that issue.

Validation

• ruff check, ruff format --check, and ty check src pass.
• pytest, excluding test_e2e*.py: 3057 passed, 2 failed. The two failures (tests/test_claude_smart_routing_v2.py, socket-based) fail the same way on unmodified main in my sandbox and are unrelated.
• New unit tests cover the 5.6+ filter (including a dated snapshot ID), the provider overlay, discovery bucketing in configure, managed-config bucketing, the default-model order, base URLs, and the auth plugin's provider set.
• Live test against a workspace that serves these models, on OpenCode 1.18.32 (the opencode-ai@1 version ug installs): ran ug configure with real discovery, then ug opencode -m <model> -- run for three turns. Turn 1 reads a file with a tool, turn 2 (-c) lists files with a tool, and turn 3 (-c) recalls both answers without tools. All three turns passed for gpt-6-sol, gpt-6-luna, gpt-6-1-sol, gpt-5-6-sol, gpt-5-6-terra, and gpt-5-6-luna. OpenCode 2.0.14 also passed for gpt-6-sol and gpt-6-luna.
• gpt-6-astra is included but untested: it isn't available in my test workspace.

This pull request and its description were written by Isaac.