Skip to content

fix(opencode): add GPT routing alongside OSS discovery#239

Open
dgokeeffe wants to merge 7 commits into
databricks:mainfrom
dgokeeffe:fix/opencode-model-routing-followup
Open

fix(opencode): add GPT routing alongside OSS discovery#239
dgokeeffe wants to merge 7 commits into
databricks:mainfrom
dgokeeffe:fix/opencode-model-routing-followup

Conversation

@dgokeeffe

Copy link
Copy Markdown

Summary

Follow-up to #223 with only the OpenCode and OSS discovery changes that depend on the Pi/long-context foundation.

Review scope

This branch is stacked on #223. Review the incremental diff from #223 to this branch; the parent PR carries the Pi OSS provider, proxy, and long-context metadata work.

Changes in this PR

  • Add the databricks-openai provider to OpenCode so GPT-5, GPT-5.6, and Codex models remain available alongside databricks-oss.
  • Discover Codex models for OpenCode and emit the Responses API configuration.
  • Fall back to foundation-model serving endpoints when UC model-services does not expose OSS models.
  • Keep the OSS-family filter so Claude/Gemini endpoints sharing the MLflow dialect are not misclassified.

Validation

  • Incremental diff from fix: declare long-context Claude and GPT metadata #223: 242 lines across 5 files.
  • tests/test_agent_opencode.py: 57 passed.
  • tests/test_databricks.py: passed through 90% before an existing subprocess/auth test stalled in the isolated worktree; the same focused suite previously passed 362 tests on the consolidated branch.
  • ruff check: passed.

Replaces the larger consolidated #238 so the review can proceed in smaller layers.

dgokeeffe and others added 7 commits July 24, 2026 17:08
…h reasoning/limits

Builds on the merged OpenCode OSS support (kimi/glm) to close the remaining gaps:

- Pi had NO OSS provider. Add databricks-mlflow (api openai-completions ->
  /ai-gateway/mlflow/v1) so Pi can select OSS chat models, with a local
  SSE-repair proxy (_mlflow_proxy) for models like inkling whose gateway stream
  omits finish_reason (Pi's parser rejects that; OpenCode's @ai-sdk/openai
  tolerates it, so it needs no proxy).
- Broaden _OSS_MODEL_FAMILIES from kimi/glm to the full chat-completions cohort
  (inkling, llama, qwen, gpt-oss, gemma), excluding non-chat services
  (embeddings/rerankers) that share a family substring (e.g. qwen3-embedding).
- Correct + extend _MODEL_TOKEN_LIMITS from probed gateway caps: glm is
  1M context / 65536 output (was 200k/25k); per-family output ceilings for the
  cohort. Add model_is_reasoning() from probed openai_reasoning capability;
  Pi sets reasoning:true so it renders streamed reasoning_content as thinking.

Both agents read the shared model_token_limits/model_is_reasoning tables.
Verified live: glm-5-2 answers through Pi (6*7 -> 42).
Pi databricks-mlflow OSS provider + broadened OSS cohort with reasoning/limits.
gpt-oss-* contains 'gpt-' so it matched the codex bucket, but it's a
chat-completions-only OSS model (served via /ai-gateway/mlflow/v1), not an
openai-responses model. Broadening _OSS_MODEL_FAMILIES to include gpt-oss put
it in BOTH codex_models and oss_models, so it was offered under Pi's
databricks-openai provider too — where the openai-responses route 400s for it.
Exclude gpt-oss from the codex bucket so it's OSS-only.
Proxy (_mlflow_proxy.py):
- Close the connection at stream end (self.close_connection = True) so HTTP/1.1
  clients detect the message boundary instead of hanging after [DONE] (the
  proxy sends no Content-Length/chunking). [critical]
- Only repair text/event-stream responses; relay non-streaming and error bodies
  verbatim with their real Content-Type instead of forcing SSE. [high]
- Catch URLError/OSError around urlopen and return a clean 502 instead of a dead
  socket on connection-level failures. [high]
- Restrict forwarded paths to /ai-gateway/mlflow/ (404 otherwise) so the
  localhost relay can't be used as an authenticated arbitrary-path workspace
  client. [security]
- Move terminator-repair writes inside the OSError guard so a client
  disconnect doesn't traceback on the daemon thread. [medium]
- Parse SSE data lines with or without the optional space after the colon. [low]

Discovery (databricks.py):
- OSS chat models matching a broad family (qwen, llama-) but lacking a specific
  _MODEL_TOKEN_LIMITS entry now fall back to a conservative floor
  (128k/8192) so they're never offered uncapped (which 400s). Non-OSS and
  embedding ids still return None.

Verified live: glm-5-2 streams content (42) + finish_reason + [DONE] through the
proxy; non-stream/error/404/502 paths covered by tests. 898 passed.
… reach OpenCode

The OSS branch (fix/1m-context-claude-gpt-pi) rebuilt opencode around a
databricks-oss bucket but dropped the databricks-openai (GPT/Codex) wiring
that only lived on fix/opencode-codex-provider. Neither branch had both, so
on the latest work GPT-5.x/5.6 was unreachable from OpenCode.

Reconcile the two efforts across all three layers:
- databricks.build_opencode_base_urls: add the 'openai' -> /ai-gateway/codex/v1 base URL
- cli.configure_shared_state: discover codex models for opencode and populate opencode_models['openai']
- agents.opencode: emit the databricks-openai provider (per-model useResponsesApi=true) alongside oss

Now OpenCode gets anthropic + google + openai + oss together. Ports databricks#97 wiring
onto the OSS/1M-context work. Adds TestOpenAIProvider + base-url coverage.

Co-authored-by: fix/opencode-codex-provider
OSS model discovery only queried UC model-services for `system.ai.*`
ids and, unlike the claude/gemini/codex families, had no AI-Gateway
fallback. On workspaces that expose OSS foundation models as regular
`databricks-*` serving endpoints (rather than `system.ai.*` UC
model-services), `oss_models` came back empty and pi/opencode never
offered GLM, Qwen, Gemma, inkling, etc.

Add `discover_oss_models`, which lists foundation-model endpoints
advertising `mlflow/v1/chat/completions` and keeps the OSS chat families
via the existing `_is_oss_chat_model` filter (the family filter is
required because Claude/Gemini endpoints can advertise the same dialect
on some workspaces). Wire it as the fallback in cli.py, mirroring the
other three families.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants