Skip to content

pi: enable thinking levels for system.ai models#194

Open
elyssazyne wants to merge 1 commit into
databricks:mainfrom
elyssazyne:elyssazyne/pi-thinking-levels
Open

pi: enable thinking levels for system.ai models#194
elyssazyne wants to merge 1 commit into
databricks:mainfrom
elyssazyne:elyssazyne/pi-thinking-levels

Conversation

@elyssazyne

Copy link
Copy Markdown

What

ucode pi writes each model into models.json as a bare {"id": ...}, so pi defaults them to reasoning: false and reports "Current model does not support thinking" for every family — no way to enable thinking or choose an effort level. Naively enabling reasoning isn't enough either: supported effort levels differ per model, so a uniform level set gets rejected.

Enabling thinking also differs by hosting method. Unity Catalog (UC) models (system.ai.*) use the current route; the legacy AI Gateway route (databricks-*) uses an older, incompatible thinking format and is being deprecated. This PR enables thinking for UC models only — legacy-route models are left as-is (they still respond, without thinking controls).

The e2e tests only discover models through the legacy AI Gateway route, so the UC path — the one that actually sends thinking params — was never exercised. This PR extends test_launch_pi_per_model to cover UC models too. The same gap exists for the other agents' launch tests; I kept this PR scoped to pi, but I'm happy to extend the others if desired.

Change

  • Added MODEL_THINKING_LEVELS, mapping every model ucode pi currently exposes to the effort levels supported by that model.
  • Thinking is gated on the system.ai. prefix; AI Gateway and unknown/new models get reasoning: false.
  • Claude on the UC route requires adaptive thinking, enabled via compat.forceAdaptiveThinking
  • Most Gemini models are intentionally left without levels — an upstream pi limitation: its google-generative-ai layer detects Gemini 3 vs 2.5 with regexes expecting dotted minor versions (gemini-3.1-pro), but Databricks serves dashed ids (gemini-3-1-pro), so only the unversioned gemini-3-pro/-flash are recognized; the rest fall through to a dynamic budget that ignores the requested effort. They still think at their default.
  • Added an e2e_uc_models fixture (tests/conftest.py) that discovers UC models via discover_model_services, and updated test_launch_pi_per_model / _all_models to launch every model on both the AI Gateway (existing) and UC (new) routes, tagged by route.

Test plan

  • uv run pytest — passed.
  • uv run ruff check . + ruff format --check — passed.
  • UCODE_TEST_WORKSPACE=<your-workspace-url> uv run pytest tests/test_e2e.py -v — passed

ucode wrote pi's models.json with bare {"id": ...} entries, so every
model defaulted to reasoning: false and pi's TUI reported "Current model
does not support thinking" for every family.

Advertise per-model thinking support instead:

- MODEL_THINKING_LEVELS maps each model to the effort levels Databricks
  accepts; _pi_model_entry emits reasoning + a thinkingLevelMap (openai
  disables via "none", xhigh must be explicit, unsupported levels hidden).
- Claude uses adaptive thinking (compat.forceAdaptiveThinking): the
  system.ai Anthropic route requires thinking.type:"adaptive" +
  output_config.effort and rejects the legacy budget format.
- Gate thinking on the system.ai. prefix. The legacy AI-Gateway route
  (databricks-*, deprecating) 400s on the new thinking params across all
  families, so those models ship without thinking and still respond.
- Unknown/new models ship without thinking until added to the table.

Cover both routes in test_launch_pi_per_model. The e2e fixture only
discovered via the AI-Gateway route, so the system.ai path (the one that
actually sends thinking params) was never exercised. Add an e2e_uc_models
fixture (discover_model_services) and launch each model on both routes,
tagged by route.

Co-Authored-By: Claude Opus 4.8 <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.

1 participant