Skip to main content
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:
Set the model to auto and Mesh’s auto-router 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.
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: 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 and CrewAI) 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: /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.