In CrewAI, how do you give one Agent a different LLM from the rest of the crew?

## What the llm field actually sets A CrewAI `Agent` carries its own model handle. The `llm` argument is not a hint or a default that a crew can override at run time — it is the client that agent will use for every reasoning step, every tool-call decision and its final answer. Two agents in the same crew can therefore run on completely different providers, and that is a deliberate design point of the framework: role specialization is cheap only if model cost can be specialized with it. ## The two ways to pass it The simplest form is a string: `Agent(role="Writer", goal="...", backstory="...", llm="openai/gpt-4o-mini")` CrewAI converts that into an `LLM` object internally. The explicit form gives you the tuning knobs: `from crewai import LLM` `llm = LLM(model="anthropic/claude-sonnet-4-5", temperature=0.2)` `LLM` accepts the usual generation parameters (`temperature`, `max_tokens`, `top_p`) plus transport parameters (`api_key`, `base_url`). Model identifiers follow the LiteLLM `provider/model` convention, which is why a bare `gpt-4o` and an explicit `openai/gpt-4o` both work for OpenAI but a self-hosted model needs the provider prefix plus a `base_url`. ## What happens when you omit it An agent without `llm` does **not** inherit the model of another agent and does not inherit anything from the task it is given. It falls back to the environment-configured default (the `OPENAI_MODEL_NAME` environment variable, with a framework default when that is unset). This is the single most common surprise in a first CrewAI project: someone sets a strong model on one agent, sees the bill, and assumes the crew is running that model everywhere — in fact the other agents are running whatever the environment says. ## Why per-agent selection is the point A crew is a pipeline of unequal work. A research agent that has to decide which of six tools to call, read long tool output and plan the next step needs a model that is good at tool selection and long context. A formatting agent that turns a finished draft into a bullet list does not. Because the model is attached to the agent rather than to the crew, the cheap-model/strong-model split is a one-line change per agent instead of a rewrite. The same mechanism lets you keep a data-sensitive step on a locally hosted model while the rest of the crew calls a hosted API. ## Neighbouring knobs on the same object - `function_calling_llm` lets an agent use a different, usually cheaper or more reliably structured, model purely for producing tool-call payloads while the main `llm` does the reasoning. - `max_rpm` bounds how many requests per minute that agent may issue, which matters when one agent sits on a rate-limited provider and the rest do not. - `respect_context_window` (on by default) keeps the agent's message history inside the model's context window instead of letting a request fail outright — relevant because different agents may now have very different context sizes. ## Failure modes to expect The first is a missing or wrong provider prefix: a model string the provider does not recognise fails at the first LLM call, not at construction time, so the error surfaces mid-run. The second is credentials — each provider reads its own environment variable, so mixing providers in one crew means the process needs every one of those keys present. The third is silent cost: because the fallback is an environment default rather than an error, an agent with a typo'd or forgotten `llm` still runs, just not on the model you intended. Logging the resolved model per agent at startup, or asserting it in a test, is a cheap guard. ## How to talk about it in an interview Say plainly that the model is a property of the agent, name the two accepted forms, mention the provider-prefixed identifier, and then move to judgment: which agents in a crew deserve the expensive model and why. That last part is what separates a recited constructor signature from an answer that shows you have run a crew and looked at the bill.