Native Mistral API fails with `cache_breakpoint` validation error during Agent execution
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 58.8k
- Forks
- 8.5k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 109
Description
Description
When using the native Mistral API (api.mistral.ai) with CrewAI, standalone LLM calls work correctly, but Agent execution fails.
The same LLM configuration successfully returns a response using:
llm.call("Say hello")
However, when the LLM is attached to a CrewAI Agent and executed through crew.kickoff(), the request fails with:
litellm.BadRequestError: MistralException -
{
"detail": [
{
"type": "extra_forbidden",
"loc": ["body","messages",0,"system","cache_breakpoint"],
"msg": "Extra inputs are not permitted"
},
{
"type": "extra_forbidden",
"loc": ["body","messages",1,"user","cache_breakpoint"],
"msg": "Extra inputs are not permitted"
}
]
}
This appears to occur only in the Agent execution path (call_llm_native_tools), not during direct LLM usage.
Steps to Reproduce
- Create a CrewAI LLM using:
llm = LLM(
model="mistral/mistral-large-latest",
api_key=os.getenv("MISTRAL_API_KEY")
)
- Verify this works:
print(llm.call("Say hello"))
-
Create an Agent using the same LLM.
-
Execute a simple Crew with crew.kickoff().
-
Observe that Agent execution fails with the cache_breakpoint validation error from the Mistral API.
Expected behavior
Agent execution should work the same way as direct LLM.call() and should not send unsupported fields to the native Mistral API.
Screenshots/Code snippets
Include both the minimal reproduction code and the relevant error.
from crewai import LLM, Agent, Task, Crew, Process
from dotenv import load_dotenv
import os
load_dotenv()
llm = LLM(
model="mistral/mistral-large-latest",
api_key=os.getenv("MISTRAL_API_KEY"),
)
print(llm.call("Say hello"))
agent = Agent(
role="Researcher",
goal="Research a topic",
backstory="Research assistant",
llm=llm,
)
task = Task(
description="Say hello",
expected_output="Greeting",
agent=agent,
)
crew = Crew(
agents=[agent],
tasks=[task],
process=Process.sequential,
)
crew.kickoff()
Error
litellm.BadRequestError: MistralException -
{
"detail": [
{
"type": "extra_forbidden",
"loc": ["body","messages",0,"system","cache_breakpoint"],
"msg": "Extra inputs are not permitted"
},
{
"type": "extra_forbidden",
"loc": ["body","messages",1,"user","cache_breakpoint"],
"msg": "Extra inputs are not permitted"
}
]
}
Operating System
Windows 11
Python Version
3.12
crewAI Version
1.15.10
crewAI Tools Version
1.15.10
Virtual Environment
Venv
Evidence
Possible Solution
It appears that CrewAI's Agent execution path (call_llm_native_tools) injects a cache_breakpoint field into the messages payload before forwarding the request to LiteLLM.
The native Mistral API strictly validates the request schema and rejects unknown fields with an extra_forbidden error.
A possible fix would be to:
- Avoid sending
cache_breakpointto providers that do not support it (such as the native Mistral API), or - Strip provider-specific metadata before making the API request, or
- Add a provider compatibility check so unsupported fields are not included in requests to Mistral.
Additional context
I verified that this is not a Mistral API key or model configuration issue.
The following direct call succeeds:
llm = LLM(
model="mistral/mistral-large-latest",
api_key=os.getenv("MISTRAL_API_KEY")
)
print(llm.call("Say hello"))
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the Agent execution path named call_llm_native_tools and compare its message payload with the direct LLM.call() path. Reproduce the issue with the supplied Mistral configuration and verify that crew.kickoff() no longer sends cache_breakpoint fields to the native Mistral API while direct calls continue to work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- ai, api
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100