Skip to content

feat(azure): support Kimi family (Moonshot) on Azure AI Foundry#650

Merged
mikehostetler merged 2 commits into
agentjido:mainfrom
spfoos:feat/azure-kimi-upstream
Apr 29, 2026
Merged

feat(azure): support Kimi family (Moonshot) on Azure AI Foundry#650
mikehostetler merged 2 commits into
agentjido:mainfrom
spfoos:feat/azure-kimi-upstream

Conversation

@spfoos
Copy link
Copy Markdown
Contributor

@spfoos spfoos commented Apr 27, 2026

Summary

Azure AI Foundry hosts Moonshot's Kimi-K2 family — kimi-k2-thinking and kimi-k2.5 are already in LLMDB, and the newer Kimi-K2.6 is deployable in Azure today. But lib/req_llm/providers/azure.ex doesn't list a Kimi prefix in @model_families, so any azure:Kimi-.../azure:kimi-... model crashes at prepare_request/4 time:

ArgumentError: Unknown Azure model family for 'Kimi-K2.6'

A second symptom: even after stubbing the family map, Azure.OpenAI.format_request/3 keeps an independent prefix allowlist (@openai_compatible_prefixes) and emits a Logger.warning on every Kimi request:

Model 'Kimi-K2.6' does not appear to be OpenAI-compatible. Proceeding with OpenAI formatting (may fail).

The request actually succeeds (Foundry exposes Kimi via the standard OpenAI-compatible /openai/v1/chat/completions endpoint), so the warning is misleading.

Changes

  1. @model_families in lib/req_llm/providers/azure.ex — add "Kimi" => Azure.OpenAI and "kimi" => Azure.OpenAI. Both casings because LLMDB-canonical ids are lowercase (kimi-k2.5, kimi-k2-thinking) but Azure deployment names are commonly uppercased (Kimi-K2.6), and String.starts_with?/2 is case-sensitive.
  2. @family_env_vars / @family_api_key_env_vars — add matching AZURE_KIMI_BASE_URL / AZURE_KIMI_API_KEY entries (both casings) for symmetry with deepseek / mai-ds.
  3. @openai_compatible_prefixes in lib/req_llm/providers/azure/openai.ex — same two casings, suppresses the spurious "may fail" warning.
  4. Tests — 4 new tests under describe "Kimi family routing":
    • azure:kimi-k2.5 (lowercase, LLMDB-resolved) prepares a request without raising.
    • Kimi-K2.6 (uppercase, hand-built %LLMDB.Model{}) prepares a request without raising.
    • format_request/3 emits no "does not appear to be OpenAI-compatible" warning for either casing.

No new formatter module needed — Foundry's /openai/v1/chat/completions is OpenAI-compatible, so reusing Azure.OpenAI matches the existing pattern for deepseek / mai-ds / grok.

Test plan

  • mix test test/provider/azure/azure_test.exs — 107/107 pass (4 new + 103 existing).
  • Verified end-to-end against a real Azure Foundry Kimi-K2.6 deployment (cmesh.ai's HIPAA tenant) — chat completions succeed, no warning.

References

🤖 Generated with Claude Code

Amplify added 2 commits April 27, 2026 14:40
Azure AI Foundry now hosts Moonshot's Kimi-K2 family (kimi-k2.5,
kimi-k2-thinking, etc.) and the Azure deployment naming sometimes uses
uppercase "Kimi-K2.x" while LLMDB-canonical ids are lowercase. Adding
both prefixes to @model_families so case-sensitive prefix matching
works for either, plus the matching AZURE_KIMI_BASE_URL /
AZURE_KIMI_API_KEY family env-var entries.

Routes through the existing Azure.OpenAI formatter — Foundry exposes
Kimi via the standard OpenAI-compatible /models/chat/completions
endpoint, so no new formatter is needed.

Without this, any "azure:Kimi-..." (or "azure:kimi-...") model raises
ArgumentError "Unknown Azure model family for ..." at request time.
…rning

The Kimi family addition in 8d4e14d only covered @model_families and the
family env-var maps. The OpenAI formatter (Azure.OpenAI.format_request/3)
keeps an independent prefix allowlist (@openai_compatible_prefixes) and
emits a Logger.warning every request when the model id falls outside it
("Model 'Kimi-K2.6' does not appear to be OpenAI-compatible. Proceeding
with OpenAI formatting (may fail)."), even though the request would have
succeeded.

Add "Kimi" and "kimi" to the formatter's prefix list to suppress the
spurious warning, and cover Kimi end-to-end:
  * azure:kimi-k2.5 resolves from LLMDB and prepares a request OK.
  * Kimi-K2.6 (uppercase Azure deployment id, not in LLMDB) prepares OK
    when constructed as %LLMDB.Model{}.
  * format_request emits no "does not appear to be OpenAI-compatible"
    warning for either casing.
@mikehostetler mikehostetler merged commit 3c6adfd into agentjido:main Apr 29, 2026
7 checks passed
@spfoos spfoos deleted the feat/azure-kimi-upstream branch May 7, 2026 13:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants