> ## Documentation Index
> Fetch the complete documentation index at: https://developers.meshapi.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Frameworks

> Point any agent framework at Mesh with one base URL — the connector, the verified compatibility matrix, and the caveats that apply across all of them.

Mesh speaks the OpenAI chat-completions and Responses dialects, so almost every agent framework reaches it by changing **one setting**: the base URL of its OpenAI client. Your agent code, tools, and prompts stay exactly as they are, and every call runs through your Mesh spend caps, rate limits, routing, and usage logging.

## The universal pattern

Whatever the framework calls it — `base_url`, `api_base`, `baseURL`, `api_base_url` — point it at `https://api.meshapi.ai/v1` and pass your `rsk_` key as the API key:

```python theme={null}
base_url = "https://api.meshapi.ai/v1"
api_key  = os.environ["MESH_API_KEY"]   # rsk_...
model    = "auto"                        # or any Mesh catalog id
```

Set the model to `auto` and Mesh's [auto-router](https://developers.meshapi.ai/docs/capabilities/auto-routing.md) chooses per request. This is the part most frameworks cannot do on their own, and it needs no framework support — `auto` is just a model name on the wire.

> [!NOTE]
>
> The model Mesh actually served comes back in the response's `model` field, and the Responses API additionally returns `x_auto_routed` and `x_resolved_model_id`. Routing genuinely varies by request: in our own verification the same agent code was served `gpt-4o-mini` for a short prompt and `anthropic/claude-haiku-5.5` for a longer one.

## Verified frameworks

Each of these was executed against `https://api.meshapi.ai/v1` with `model="auto"`, completing a full tool-call round trip — request, tool call, tool result, final answer:

| Framework | Verified version | Guide |
| - | - | - |
| Google ADK | `google-adk` 2.13.0 | [Google ADK](https://developers.meshapi.ai/agent/adk.md) |
| LangChain / LangGraph | `langchain-openai` 1.7.2 | [LangChain](https://developers.meshapi.ai/agent/langchain.md) |
| CrewAI | `crewai` 1.15.30 | [CrewAI](https://developers.meshapi.ai/agent/crewai.md) |
| LlamaIndex | `llama-index-core` 0.14.25 | [LlamaIndex](https://developers.meshapi.ai/agent/llamaindex.md) |
| Pydantic AI | `pydantic-ai-slim` 2.61.0 | [Pydantic AI](https://developers.meshapi.ai/agent/pydantic-ai.md) |
| OpenAI Agents SDK | `openai-agents` 0.24.0 | [OpenAI Agents SDK](https://developers.meshapi.ai/agent/openai-agents.md) |

Anything else that lets you set an OpenAI base URL will work the same way. The two groups that need care are frameworks routing through **LiteLLM** (prefix the model with `openai/`, see [Google ADK](https://developers.meshapi.ai/agent/adk.md) and [CrewAI](https://developers.meshapi.ai/agent/crewai.md)) and the **OpenAI Agents SDK**, which defaults to the Responses API rather than chat completions.

## Which endpoint your framework uses

Mesh serves both, and the framework decides:

| Endpoint | Used by |
| - | - |
| `POST /v1/chat/completions` | LangChain, CrewAI, LlamaIndex, Pydantic AI, Google ADK |
| `POST /v1/responses` | OpenAI Agents SDK by default |

`/v1/responses` is only available for models that support it. A model without Responses support returns `400` with code `model_capability_not_supported` — `auto` resolves to a model that supports it, so the default path works.

## Caveats that apply to every framework

### Tool calls on Gemini thinking models

Mesh returns a `thought_signature` on tool calls from Gemini thinking models, which the provider needs echoed back verbatim to keep its reasoning chain intact. Generic OpenAI-dialect clients do not carry that field, so on a **multi-turn** tool call it is dropped and the model loses its thinking after the first turn. Tools still run and the agent still works; reasoning quality degrades quietly.

If your workload depends on multi-turn tool reasoning, pin a non-thinking model rather than relying on `auto`.

### Streaming tool-call deltas

When streaming, tool calls arrive as incremental deltas, so a partial tool call can carry empty or half-built arguments. Frameworks handle this internally, but **if you process streaming events yourself, skip the partial ones** — otherwise you will fire your tool repeatedly with incomplete arguments.

### Token counting against `auto`

A framework that counts tokens locally cannot look up a context window for the literal model name `auto`, because the model is not chosen until Mesh routes the request. Most fall back to an approximation and log a warning. This affects the framework's own bookkeeping only — Mesh's usage accounting and billing use the real served model.

## Related

* [Auto-routing](https://developers.meshapi.ai/docs/capabilities/auto-routing.md) — how Mesh picks a model for `auto`
* [Tool calling](https://developers.meshapi.ai/docs/capabilities/tool-calling.md) — the tool format these frameworks emit
* [Authentication](https://developers.meshapi.ai/docs/getting-started/authentication.md) — `rsk_` keys versus `mak_` admin keys
* [MCP Server](https://developers.meshapi.ai/agent/mcp.md) — connect an MCP-compatible client instead of a framework


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.