Feat: Align Pi and OpenCode model family options - #256
Conversation
anthonyivn2
changed the title
|
@rohita5l can I get you or the team to OK this? |
| # Old provider names earlier ucode versions wrote; cleaned up on each write so | ||
| # users don't end up with stale entries pointing at routes that 400. | ||
| LEGACY_PROVIDER_NAMES = ("databricks-anthropic", "databricks-codex", "databricks-oss") | ||
| LEGACY_PROVIDER_NAMES = ("databricks-anthropic", "databricks-codex", "databricks-kimi") |
There was a problem hiding this comment.
where did kimi come from? I dont see a old ucode version that supported kimi?
| claude_models[family] = candidates[0] | ||
|
|
||
| codex_models = [m for m in ids if "gpt-" in m] | ||
| codex_models = [m for m in ids if "gpt-" in m and "gpt-oss-" not in m] |
There was a problem hiding this comment.
The gpt-oss exclusion only covers the UC path. The filter is in discover_model_services, but cli.py:426-427 falls back to discover_codex_models when the UC listing comes back empty for codex, and that path (discover_endpoints_with_api_type(...,"openai/v1/responses")) has no gpt-oss filter. So on a workspace without UC model-services, gpt-oss still reaches Pi/OpenCode and still fails the same way. Probably wants to live one layer down, or in both places
|
|
||
| written_providers = json.loads(config_file.read_text()).get("providers", {}) | ||
| for legacy in ("databricks-anthropic", "databricks-codex", "databricks-oss"): | ||
| for legacy in ("databricks-anthropic", "databricks-codex", "databricks-kimi"): |
There was a problem hiding this comment.
This swap means the databricks-oss cleanup is no longer tested. The old version of this test proved that a stale databricks-oss entry (on openai-completions) got stripped on upgrade; retargeting it to databricks-kimi drops that guard right as the PR removes databricks-oss from LEGACY_PROVIDER_NAMES. Could we keep a case for it — a stale databricks-oss entry with oss_models empty, asserting it's gone after the
write? That's the scenario I'm unsure about in my other comment.
| "opus": "system.ai.claude-opus-4-8", | ||
| "sonnet": "system.ai.claude-sonnet-4-6", | ||
| } | ||
| # gpt-oss is not Responses-compatible with Pi/OpenCode and must not |
There was a problem hiding this comment.
This covers the exclusion on the UC path, but discover_codex_models (the fallback at cli.py:426-427 when the UC listing is empty for codex) has no gpt-oss filter and isn't tested here. Worth a case on that path too — it's the one where gpt-oss can still reach Pi/OpenCode.
2 participants
Summary
gpt-ossmodel services from Codex discovery instead of exposing options that fail in Pi and OpenCodeTesting
.venv/bin/ruff check ..venv/bin/pytest tests/test_agent_pi.py tests/test_agent_opencode.py tests/test_agents_init.py tests/test_databricks.py tests/test_cli.py tests/test_lint.py -q(471 passed)2 passed in 239.58s)