# Calls <Note> If you haven't already, we recommend first reading the section on writing [Prompts](/docs/v1/learn/prompts) </Note> When working with Large Language Model (LLM) APIs in Mirascope, a "call" refers to making a request to a LLM provider's API with a particular setting and prompt. The `call` decorator is a core feature of the Mirascope library, designed to simplify and streamline interactions with various LLM providers. This powerful tool allows you to transform prompt templates written as Python functions into LLM API calls with minimal boilerplate code while providing type safety and consistency across different providers. We currently support [OpenAI](https://openai.com/), [Anthropic](https://www.anthropic.com/), [Google (Gemini/Vertex)](https://ai.google.dev/), [Groq](https://groq.com/), [xAI](https://x.ai/api), [Mistral](https://mistral.ai/), [Cohere](https://cohere.com/), [LiteLLM](https://www.litellm.ai/), [Azure AI](https://azure.microsoft.com/en-us/solutions/ai), and [Amazon Bedrock](https://aws.amazon.com/bedrock/). If there are any providers we don't yet support that you'd like to see supported, let us know! <Callout type="api"> [`mirascope.llm.call`](/docs/v1/api/llm/call) </Callout> ## Basic Usage and Syntax Let's take a look at a basic example using Mirascope vs. official provider SDKs: <TabbedSection showLogo={true}> <Tab value="Shorthand"> ```python from mirascope import llm @llm.call(provider="$PROVIDER", model="$MODEL") # [!code highlight] def recommend_book(genre: str) -> str: return f"Recommend a {genre} book" # [!code highlight] response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> <Tab value="Template"> ```python from mirascope import llm, prompt_template @llm.call(provider="$PROVIDER", model="$MODEL") # [!code highlight] @prompt_template("Recommend a {genre} book") # [!code highlight] def recommend_book(genre: str): ... response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> </TabbedSection> Official provider SDKs typically require more boilerplate code: <Info title="Official SDK" collapsible={true}> <ProviderCodeBlock examplePath="v1/learn/calls/basic_usage/sdk"/> </Info> Notice how Mirascope makes calls more readable by reducing boilerplate and standardizing interactions with LLM providers. The `llm.call` decorator accepts `provider` and `model` arguments and returns a provider-agnostic `CallResponse` instance that provides a consistent interface regardless of the underlying provider. You can find more information on `CallResponse` in the [section below](#handling-responses) on handling responses. Note the `@prompt_template` decorator is optional unless you're using string templates. ### Runtime Provider Overrides You can override provider settings at runtime using `llm.override`. This takes a function decorated with `llm.call` and lets you specify: - `provider`: Change the provider being called - `model`: Use a different model - `call_params`: Override call parameters like temperature - `client`: Use a different client instance When overriding with a specific `provider`, you must specify the `model` parameter. <TabbedSection> <Tab value="Shorthand"> ```python from mirascope import llm @llm.call(provider="$PROVIDER", model="$MODEL") # [!code highlight] def recommend_book(genre: str) -> str: # [!code highlight] return f"Recommend a {genre} book" # [!code highlight] response: llm.CallResponse = recommend_book("fantasy") print(response.content) override_response = llm.override( # [!code highlight] recommend_book, # [!code highlight] provider="$OTHER_PROVIDER", # [!code highlight] model="$OTHER_MODEL", # [!code highlight] call_params={"temperature": 0.7}, # [!code highlight] )("fantasy") # [!code highlight] print(override_response.content) ``` </Tab> <Tab value="Template"> ```python from mirascope import llm from mirascope.core import prompt_template @llm.call(provider="$PROVIDER", model="$MODEL") # [!code highlight] @prompt_template("Recommend a {genre} book") # [!code highlight] def recommend_book(genre: str): ... # [!code highlight] response = recommend_book("fantasy") print(response.content) override_response = llm.override( # [!code highlight] recommend_book, # [!code highlight] provider="$OTHER_PROVIDER", # [!code highlight] model="$OTHER_MODEL", # [!code highlight] call_params={"temperature": 0.7}, # [!code highlight] )("fantasy") # [!code highlight] print(override_response.content) ``` </Tab> </TabbedSection> ## Handling Responses ### Common Response Properties and Methods <Callout type="api"> [`mirascope.core.base.call_response`](/docs/v1/api/core/base/call_response) </Callout> All [`BaseCallResponse`](/docs/v1/api) objects share these common properties: - `content`: The main text content of the response. If no content is present, this will be the empty string. - `finish_reasons`: A list of reasons why the generation finished (e.g., "stop", "length"). These will be typed specifically for the provider used. If no finish reasons are present, this will be `None`. - `model`: The name of the model used for generation. - `id`: A unique identifier for the response if available. Otherwise this will be `None`. - `usage`: Information about token usage for the call if available. Otherwise this will be `None`. - `input_tokens`: The number of input tokens used if available. Otherwise this will be `None`. - `output_tokens`: The number of output tokens generated if available. Otherwise this will be `None`. - `cost`: An estimated cost of the API call if available. Otherwise this will be `None`. - `message_param`: The assistant's response formatted as a message parameter. - `tools`: A list of provider-specific tools used in the response, if any. Otherwise this will be `None`. Check out the [`Tools`](/docs/v1/learn/tools) documentation for more details. - `tool`: The first tool used in the response, if any. Otherwise this will be `None`. Check out the [`Tools`](/docs/v1/learn/tools) documentation for more details. - `tool_types`: A list of tool types used in the call, if any. Otherwise this will be `None`. - `prompt_template`: The prompt template used for the call. - `fn_args`: The arguments passed to the function. - `dynamic_config`: The dynamic configuration used for the call. - `metadata`: Any metadata provided using the dynamic configuration. - `messages`: The list of messages sent in the request. - `call_params`: The call parameters provided to the `call` decorator. - `call_kwargs`: The finalized keyword arguments used to make the API call. - `user_message_param`: The most recent user message, if any. Otherwise this will be `None`. - `start_time`: The timestamp when the call started. - `end_time`: The timestamp when the call ended. There are also two common methods: - `__str__`: Returns the `content` property of the response for easy printing. - `tool_message_params`: Creates message parameters for tool call results. Check out the [`Tools`](/docs/v1/learn/tools) documentation for more information. ## Multi-Modal Outputs While most LLM providers focus on text outputs, some providers support additional output modalities like audio. The availability of multi-modal outputs varies among providers: | Provider | Text | Audio | Image | |---------------|:------:|:-------:|:-------:| | OpenAI | ✓ | ✓ | — | | Anthropic | ✓ | — | — | | Mistral | ✓ | — | — | | Google Gemini | ✓ | — | — | | Groq | ✓ | — | — | | Cohere | ✓ | — | — | | LiteLLM | ✓ | — | — | | Azure AI | ✓ | — | — | *Legend: ✓ (Supported), — (Not Supported)* ### Audio Outputs - `audio`: Configuration for the audio output (voice, format, etc.) - `modalities`: List of output modalities to receive (e.g. `["text", "audio"]`) For providers that support audio outputs, you can receive both text and audio responses from your calls: <ProviderCodeBlock examplePath="v1/learn/calls/multi_modal_outputs"/> When using models that support audio outputs, you'll have access to: - `content`: The text content of the response - `audio`: The raw audio bytes of the response - `audio_transcript`: The transcript of the audio response <Warning title="Audio Playback Requirements" collapsible={true} defaultOpen={false}> The example above uses `pydub` and `ffmpeg` for audio playback, but you can use any audio processing libraries or media players that can handle WAV format audio data. Choose the tools that best fit your needs and environment. If you decide to use pydub: - Install [pydub](https://github.com/jiaaro/pydub): `pip install pydub` - Install ffmpeg: Available from [ffmpeg.org](https://www.ffmpeg.org/) or through system package managers </Warning> <Note title="Voice Options" collapsible={true} defaultOpen={false}> For providers that support audio outputs, refer to their documentation for available voice options and configurations: - OpenAI: [Text to Speech Guide](https://platform.openai.com/docs/guides/text-to-speech) </Note> ## Common Parameters Across Providers There are several common parameters that you'll find across all providers when using the `call` decorator. These parameters allow you to control various aspects of the LLM call: - `model`: The only required parameter for all providers, which may be passed in as a standard argument (whereas all others are optional and must be provided as keyword arguments). It specifies which language model to use for the generation. Each provider has its own set of available models. - `stream`: A boolean that determines whether the response should be streamed or returned as a complete response. We cover this in more detail in the [`Streams`](/docs/v1/learn/streams) documentation. - `response_model`: A Pydantic `BaseModel` type that defines how to structure the response. We cover this in more detail in the [`Response Models`](/docs/v1/learn/response_models) documentation. - `output_parser`: A function for parsing the response output. We cover this in more detail in the [`Output Parsers`](/docs/v1/learn/output_parsers) documentation. - `json_mode`: A boolean that deterines whether to use JSON mode or not. We cover this in more detail in the [`JSON Mode`](/docs/v1/learn/json_mode) documentation. - `tools`: A list of tools that the model may request to use in its response. We cover this in more detail in the [`Tools`](/docs/v1/learn/tools) documentation. - `client`: A custom client to use when making the call to the LLM. We cover this in more detail in the [`Custom Client`](#custom-client) section below. - `call_params`: The provider-specific parameters to use when making the call to that provider's API. We cover this in more detail in the [`Provider-Specific Usage`](#provider-specific-usage) section below. These common parameters provide a consistent way to control the behavior of LLM calls across different providers. Keep in mind that while these parameters are widely supported, there might be slight variations in how they're implemented or their exact effects across different providers (and the documentation should cover any such differences). Since `call_params` is just a `TypedDict`, you can always include any additional keys at the expense of type errors (and potentially unknown behavior). This presents one way to pass provider-specific parameters (or deprecated parameters) while still using the general interface. <TabbedSection> <Tab value="Shorthand"> ```python from mirascope import llm @llm.call(provider="$PROVIDER", model="$MODEL", call_params={"max_tokens": 512}) # [!code highlight] def recommend_book(genre: str) -> str: return f"Recommend a {genre} book" response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> <Tab value="Template"> ```python from mirascope import llm, prompt_template @llm.call(provider="$PROVIDER", model="$MODEL", call_params={"max_tokens": 512}) # [!code highlight] @prompt_template("Recommend a {genre} book") def recommend_book(genre: str): ... response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> </TabbedSection> ## Dynamic Configuration Often you will want (or need) to configure your calls dynamically at runtime. Mirascope supports returning a `BaseDynamicConfig` from your prompt template, which will then be used to dynamically update the settings of the call. In all cases, you will need to return your prompt messages through the `messages` keyword of the dynamic config unless you're using string templates. ### Call Params <TabbedSection> <Tab value="Shorthand"> ```python from mirascope import BaseDynamicConfig, Messages, llm @llm.call(provider="$PROVIDER", model="$MODEL") def recommend_book(genre: str) -> BaseDynamicConfig: return { "messages": [Messages.User(f"Recommend a {genre} book")], # [!code highlight] "call_params": {"max_tokens": 512}, # [!code highlight] "metadata": {"tags": {"version:0001"}}, } response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> <Tab value="Template"> ```python from mirascope import BaseDynamicConfig, llm, prompt_template @llm.call(provider="$PROVIDER", model="$MODEL") @prompt_template("Recommend a {genre} book") # [!code highlight] def recommend_book(genre: str) -> BaseDynamicConfig: return { "call_params": {"max_tokens": 512}, # [!code highlight] "metadata": {"tags": {"version:0001"}}, } response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> </TabbedSection> ### Metadata <TabbedSection> <Tab value="Shorthand"> ```python from mirascope import BaseDynamicConfig, Messages, llm @llm.call(provider="$PROVIDER", model="$MODEL") def recommend_book(genre: str) -> BaseDynamicConfig: return { "messages": [Messages.User(f"Recommend a {genre} book")], # [!code highlight] "call_params": {"max_tokens": 512}, "metadata": {"tags": {"version:0001"}}, # [!code highlight] } response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> <Tab value="Template"> ```python from mirascope import BaseDynamicConfig, llm, prompt_template @llm.call(provider="$PROVIDER", model="$MODEL") @prompt_template("Recommend a {genre} book") # [!code highlight] def recommend_book(genre: str) -> BaseDynamicConfig: return { "call_params": {"max_tokens": 512}, "metadata": {"tags": {"version:0001"}}, # [!code highlight] } response: llm.CallResponse = recommend_book("fantasy") print(response.content) ``` </Tab> </TabbedSection> ## Provider-Specific Usage <Callout type="api"> For details on provider-specific modules, see the API documentation for each provider: - [`mirascope.core.openai.call`](/docs/v1/api/core/openai/call) - [`mirascope.core.anthropic.call`](/docs/v1/api/core/anthropic/call) - [`mirascope.core.mistral.call`](/docs/v1/api/core/mistral/call) - [`mirascope.core.google.call`](/docs/v1/api/core/google/call) - [`mirascope.core.azure.call`](/docs/v1/api/core/azure/call) - [`mirascope.core.cohere.call`](/docs/v1/api/core/cohere/call) - [`mirascope.core.groq.call`](/docs/v1/api/core/groq/call) - [`mirascope.core.xai.call`](/docs/v1/api/core/xai/call) - [`mirascope.core.bedrock.call`](/docs/v1/api/core/bedrock/call) - [`mirascope.core.litellm.call`](/docs/v1/api/core/litellm/call) </Callout> While Mirascope provides a consistent interface across different LLM providers, you can also use provider-specific modules with refined typing for an individual provider. When using the provider modules, you'll receive a provider-specific `BaseCallResponse` object, which may have extra properties. Regardless, you can always access the full, provider-specific response object as `response.response`. <TabbedSection> <Tab value="Shorthand"> <ProviderCodeBlock examplePath="v1/learn/calls/provider_specific/basic_usage/shorthand"/> </Tab> <Tab value="Template"> <ProviderCodeBlock examplePath="v1/learn/calls/provider_specific/basic_usage/template"/> </Tab> </TabbedSection> <Note title="Reasoning For Provider-Specific BaseCallResponse Objects" collapsible={true} defaultOpen={false}> The reason that we have provider-specific response objects (e.g. `OpenAICallResponse`) is to provide proper type hints and safety when accessing the original response. </Note> ### Custom Messages When using provider-specific calls, you can also always return the original message types for that provider. To do so, simply return the provider-specific dynamic config: <ProviderCodeBlock examplePath="v1/learn/calls/provider_specific/custom_messages"/> Support for provider-specific messages ensures that you can still access newly released provider-specific features that Mirascope may not yet support natively. ### Custom Client Mirascope allows you to use custom clients when making calls to LLM providers. This feature is particularly useful when you need to use specific client configurations, handle authentication in a custom way, or work with self-hosted models. __Decorator Parameter:__ You can pass a client to the `call` decorator using the `client` parameter: <TabbedSection> <Tab value="Shorthand"> <ProviderCodeBlock examplePath="v1/learn/calls/provider_specific/custom_client/decorator/shorthand"/> </Tab> <Tab value="Template"> <ProviderCodeBlock examplePath="v1/learn/calls/provider_specific/custom_client/decorator/template"/> </Tab> </TabbedSection> __Dynamic Configuration:__ You can also configure the client dynamically at runtime through the dynamic configuration: <TabbedSection> <Tab value="Shorthand"> <ProviderCodeBlock examplePath="v1/learn/calls/provider_specific/custom_client/dynamic_config/shorthand"/> </Tab> <Tab value="Template"> <ProviderCodeBlock examplePath="v1/learn/calls/provider_specific/custom_client/dynamic_config/template"/> </Tab> </TabbedSection> <Warning title="Make sure to use the correct client!" collapsible={true} defaultOpen={false}> A common mistake is to use the synchronous client with async calls. Read the section on [Async Custom Client](/docs/v1/learn/async#custom-client) to see how to use a custom client with asynchronous calls. </Warning> ## Error Handling When making LLM calls, it's important to handle potential errors. Mirascope preserves the original error messages from providers, allowing you to catch and handle them appropriately: <TabbedSection> <Tab value="Shorthand"> ```python from mirascope import llm @llm.call(provider="$PROVIDER", model="$MODEL") def recommend_book(genre: str) -> str: return f"Recommend a {genre} book" try: response: llm.CallResponse = recommend_book("fantasy") # [!code highlight] print(response.content) except Exception as e: print(f"Error: {str(e)}") # [!code highlight] ``` </Tab> <Tab value="Template"> ```python from mirascope import llm, prompt_template @llm.call(provider="$PROVIDER", model="$MODEL") @prompt_template("Recommend a {genre} book") def recommend_book(genre: str): ... try: response: llm.CallResponse = recommend_book("fantasy") # [!code highlight] print(response.content) except Exception as e: print(f"Error: {str(e)}") # [!code highlight] ``` </Tab> </TabbedSection> These examples catch the base Exception class; however, you can (and should) catch provider-specific exceptions instead when using provider-specific modules. ## Next Steps By mastering calls in Mirascope, you'll be well-equipped to build robust, flexible, and reusable LLM applications. Next, we recommend choosing one of: - [Streams](/docs/v1/learn/streams) to see how to stream call responses for a more real-time interaction. - [Chaining](/docs/v1/learn/chaining) to see how to chain calls together. - [Response Models](/docs/v1/learn/response_models) to see how to generate structured outputs. - [Tools](/docs/v1/learn/tools) to see how to give LLMs access to custom tools to extend their capabilities. - [Async](/docs/v1/learn/async) to see how to better take advantage of asynchronous programming and parallelization for improved performance. Pick whichever path aligns best with what you're hoping to get from Mirascope.