Skip to content

feat(codex): reroute GET /models to OpenAI-shaped discovery for IntelliJ - #242

Open
IceRhymers wants to merge 1 commit into
masterfrom
feat/intellij-support
Open

feat(codex): reroute GET /models to OpenAI-shaped discovery for IntelliJ#242
IceRhymers wants to merge 1 commit into
masterfrom
feat/intellij-support

Conversation

@IceRhymers

Copy link
Copy Markdown
Owner

What

OpenAI-shaped clients — notably JetBrains IntelliJ's AI Assistant, pointed at the local proxy root — enumerate models via GET /models. The codex proxy forwards to the {host}/ai-gateway/openai/v1 base path, but Databricks has no /ai-gateway/openai/v1/models endpoint — a naive forward 400s with "doesn't match any known API type". The working discovery endpoint is {host}/ai-gateway/v1/models (no /openai/v1 segment), but it returns a Databricks-shaped list (query_name/display_name), not OpenAI's {id, object:"model"}.

This adds an opt-in GET /models reroute to the shared proxy engine, gated on a new Config.OpenAIModelsUpstream field.

How

  • internal/core/proxy/models_reroute.go — when OpenAIModelsUpstream is set, register GET /models (exact-match), fetch the discovery URL with a fresh token, and transform the body to the OpenAI shape (id=query_name, object:"model", owned_by:"databricks"). Non-GET /models and /models/{id} fall through to the inference catch-all.
  • Thread the field through LaunchPlancore.Runproxy.Config, and through the codex ProxyConfig facade (serve_codex.go bypasses core.Run).
  • New ConstructModelsURL(host) in codex token.go (const /ai-gateway/v1/models), single-sourced into both launch_codex.go (wrapper) and serve_codex.go (serve).

Off by default

Claude and opencode leave OpenAIModelsUpstream empty, so the route is never registered — byte-identical to before. The multiplexer (databricks-agents codex serve) is covered automatically via exec-delegation.

Testing

  • 5 new shared-engine tests + a codex ConstructModelsURL test; full affected suites green.
  • Live against fevm-west: both databricks-codex serve and databricks-agents codex serve return 44 OpenAI-shaped models on GET /models; POST /models still forwards to inference.

Note

The transformed created field is a fixed constant — the gateway exposes no per-model creation time. OpenAI clients only require the field present and numeric; revisit if a client sorts by it.

This pull request and its description were written by Isaac.

OpenAI-shaped clients (e.g. JetBrains IntelliJ's AI Assistant, pointed at
the local proxy root) enumerate models via GET /models. The codex proxy
forwards to the {host}/ai-gateway/openai/v1 base path, but Databricks has
no /ai-gateway/openai/v1/models endpoint — a naive forward 400s with
"doesn't match any known API type". The working discovery endpoint is
{host}/ai-gateway/v1/models, but it returns a Databricks-shaped list
(query_name/display_name), not OpenAI's {id, object:"model"}.

Add an opt-in GET /models reroute to the shared proxy engine, gated on
the new Config.OpenAIModelsUpstream field:

- internal/core/proxy/models_reroute.go: when the field is set, register
  GET /models (exact-match), fetch the discovery URL with a fresh token,
  and transform the body to the OpenAI shape. Non-GET /models and
  /models/{id} fall through to the inference catch-all.
- Thread the field through LaunchPlan -> core.Run -> proxy.Config, and
  through the codex ProxyConfig facade (serve_codex.go bypasses core.Run).
- New ConstructModelsURL(host) in codex token.go (const /ai-gateway/v1/models),
  single-sourced into both launch_codex.go (wrapper) and serve_codex.go (serve).

Off by default: claude and opencode leave OpenAIModelsUpstream empty, so
the route is never registered — byte-identical to before. The multiplexer
(databricks-agents codex serve) is covered automatically via exec-delegation.

Verified live against fevm-west: both databricks-codex serve and
databricks-agents codex serve return 44 OpenAI-shaped models on GET /models;
POST /models still forwards to inference.

Co-authored-by: Isaac
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