2.0 KiB
Mistral Provider Shape
Last updated: dev@2e2bb52 | 2026-08-16
Scope
Canonical provider ID mistral; OpenAI-compatible chat with Mistral response
extensions and runtime handling in src/llm_core.py. There is no dedicated
Mistral canonical reader on current dev.
Catalog Shape
GET /v1/models returns data[] cards with id, root, aliases,
max_context_length, and capabilities booleans including
completion_chat, completion_fim, function_calling, vision,
classification, and lifecycle/fine-tuning fields. These are candidate fields
for a future dedicated reader:
- chat/FIM or classification family;
- vision input;
- function calling;
- explicitly reported reasoning/structured output when present;
- context limit and root family.
Fine-tuning availability and archived status are not inference capabilities. The current generic reader retains identity/raw data only and does not map any of these fields. Different Mistral models retain independent identities.
Request And Response Shape
Reasoning-capable models accept graded reasoning_effort. Mistral can return content as typed blocks: a thinking block containing text fragments plus a normal text block. Runtime normalizes those blocks for async utility calls as well as chat/stream paths, keeping reasoning and visible text separate instead of stringifying the list or scanning text tags (#4698, #5882).
Fallback And Safety
Runtime llm_core detects label-bounded Mistral hosts for request/response
handling. The canonical registry has no Mistral host or rich-payload detector;
an explicitly supplied mistral vendor falls back to generic identity. A
Mistral model served through another engine uses that serving engine's dialect.
Current Gaps
- Catalog reasoning fields vary across model-card generations; absent remains unknown.
- Mistral catalog capability fields are not normalized by current
dev. - Runtime thinking-family selection still uses names and should migrate to structured root/capability identity.