[Feature Request]:(mistral-backend): forward prompt_cache_key to chat.complete (currently dropped, supported by SDK)

[jbottesi]

Component

CLI

Problem statement

Summary

The Mistral backend in vibe/core/llm/backend/mistral.py does not forward the prompt_cache_key parameter to chat.complete_async / chat.stream_async, even though the mistralai Python SDK accepts it and the Mistral API documents it as the activation switch for prompt caching.

The Anthropic and Vertex backends already implement caching (backend/anthropic.py:360, backend/vertex.py:118). The Mistral backend is the asymmetric outlier.

Use Case

Multi-turn agent loops with stable system prompts and tools schemas — the default vibe usage pattern for me.

In a small benchmark I ran (a fixed task replayed 10 times back-to-back via chained vibe -p --resume calls on mistral-medium-3.5), each cycle averaged around 280k cumulated session_prompt_tokens, dominated by the system prompt and tools schemas being re-sent on every internal LLM round-trip. Whenever the same system + tools prefix is sent across many turns, this is exactly the scenario prompt_cache_key was designed for.

Description (the gap)

vibe/core/llm/backend/mistral.py:270-285 (the complete method) currently calls:

response = await self._get_client().chat.complete_async(
    model=model.name,
    messages=...,
    temperature=temperature,
    tools=...,
    max_tokens=max_tokens,
    tool_choice=...,
    http_headers=extra_headers,
    metadata=metadata,
    stream=False,
    reasoning_effort=reasoning_effort,
)

prompt_cache_key is absent. The same applies to complete_streaming at line ~349 (chat.stream_async).

I verified in the bundled SDK:

• mistralai/client/chat.py exposes prompt_cache_key: OptionalNullable[str] = UNSET on both complete_async and stream_async
• mistralai/client/models/chatcompletionrequest.py and chatcompletionstreamrequest.py both include the field
• mistralai/client/models/usageinfo.py uses model_config = ConfigDict(extra="allow"), so any cache-related response fields the API may return would surface in additional_properties

For comparison, the existing caching plumbing in other backends:

• backend/anthropic.py:360, :376, :475 — sets cache_control: {"type": "ephemeral"} on tools and last user message
• backend/anthropic.py:160, :293, :561 — accumulates cache_creation_input_tokens and cache_read_input_tokens into the reported usage
• backend/vertex.py:118 — calls _add_cache_control_to_last_user_message

There is no equivalent for Mistral.

Proposed solution

Suggested Fix

Two-line change (the API surface is for the maintainers to decide — env var, config.toml field, or per-call CLI flag; the snippet below uses an env var as the minimal-impact option):

# vibe/core/llm/backend/mistral.py
from mistralai.client.types import UNSET   # +1 import

# in MistralBackend.complete (and complete_streaming):
_cache_key = os.getenv("VIBE_PROMPT_CACHE_KEY")
response = await self._get_client().chat.complete_async(
    ...,
    reasoning_effort=reasoning_effort,
    prompt_cache_key=_cache_key if _cache_key else UNSET,
)

Backward compatible: when the env var is unset, behavior is unchanged.

A more idiomatic option (and arguably more aligned with how Anthropic/Vertex handle caching) would be to derive a stable cache key from the session id automatically, so users get caching without configuration. I'd happily defer to the maintainers on that design decision.

Alternatives Considered

The Anthropic and Vertex backends already provide caching out of the box, so I could switch providers to work around this gap. However, I've standardized on Mistral models (for performance, sovereignty, or partnership reasons), and this fix would let me keep that choice without forcing a backend migration.

Additional context

Environment

• vibe version: 2.9.5
• Python: 3.14
• OS: macOS (Darwin 25.3.0)
• Model used in measurement: mistral-medium-3.5
• mistralai SDK: bundled with mistral-vibe 2.9.5

Duplicates Check

I searched issues and PRs in mistralai/mistral-vibe for cache, prompt_cache_key, caching. The existing matches relate to internal Python object caching (e.g. #105 "Cache Active Tool Classes", #96 "Tool Classes Regenerated on Every LLM Call"), not the Mistral API caching parameter. No duplicate found.

Thanks for the great work on vibe.

— @jbottesi