Skip to content
OpenSmartRoute
Documentation
Python SDK

Compatibility matrix

Every provider, client, agent framework and adapter the router connects to - and how each connection was verified.

Python SDK 3 min read

What OpenSmartRoute connects to, how each connection is made, and how it was verified. One row per provider, client, framework and adapter; the Verified column names the evidence - a unit test that runs on every push, a live run with real credentials and its date, or "by protocol" when the connection is the OpenAI-compatible wire format and no deeper adapter exists. A test holds this page to the code: every provider preset the platform offers, every adapter module of the SDK and every framework the website names must have a row here.

Legend for Verified: CI = exercised by the test suite on every push (a fake endpoint speaking the provider's wire format); live <date> = a real call with real credentials on that date, recorded in the repository; protocol = reached through the OpenAI-compatible API without a dedicated adapter, so what is verified is the protocol, not the vendor's quirks.

Model providers (hosted platform and osr serve)

The platform's Model providers page offers these presets (platform/api/osr_platform/providers.py); each is an OpenAI-compatible endpoint the router calls with the workspace's own key. The SDK reaches the same endpoints through attach_chat_handlers / OpenAICompatClient and, for Anthropic, AnthropicClient.

PresetVendor APIWire formatVerified
openaiOpenAIOpenAI chat / embeddings / responsesCI; live 2026-09-10 (token calibration against billed gpt-4.1 usage)
azureAzure OpenAI / Azure AI FoundryOpenAI v1 with api-key headerCI; live 2026-09-10 (multi-cloud benchmark, 150 prompts)
azure-identityAzure OpenAI / Azure AI Foundry, keylessOpenAI v1 with a managed-identity bearer token (identity://https://cognitiveservices.azure.com)CI (reference resolution and caching); the token exchange is the same identity endpoint the Key Vault references use in production
huggingfaceHugging Face Inference ProvidersOpenAI-compatible router (router.huggingface.co/v1, Hub model ids)protocol
bedrockAmazon BedrockOpenAI-compatible endpoint (openai.gpt-oss-*)live 2026-09-10 (multi-cloud benchmark)
geminiGoogle Gemini APIOpenAI-compatible endpointprotocol
vertexGoogle Cloud Vertex AIOpenAI-compatible endpoint (google.thinking_config passed through)live 2026-09-10 (multi-cloud benchmark, judge re-scoring)
openrouterOpenRouterOpenAICI (the example catalogue names OpenRouter ids)
anthropicAnthropicnative Messages API (AnthropicClient)CI (translation of chat calls, streaming)
mistralMistralOpenAIprotocol
groqGroqOpenAIprotocol
togetherTogether AIOpenAIprotocol
fireworksFireworks AIOpenAIprotocol
deepseekDeepSeekOpenAIprotocol
xaixAIOpenAIprotocol
cohereCohereOpenAI-compatible endpointprotocol
ollamaOllama (local models)OpenAICI; live, in production (the on-prem targets of opensmartroute.ai run on it)
vllmvLLMOpenAIprotocol (the vLLM semantic-router import is CI)
litellmLiteLLM proxyOpenAIprotocol
customany OpenAI-compatible endpointOpenAICI (the test fleet is one)

The platform's own model server (osr-models, Ollama and OpenAI APIs over llama.cpp) is a ollama preset to the router; its API coverage has its own matrix in the model-serving plan.

Clients that talk to the router

ClientHowVerified
OpenAI Python SDKOpenAI(base_url=<router>/v1, api_key=<key>), model="auto"CI (the official client against osr serve, chat, streaming, tools, embeddings); openai>=1.50,<3
OpenAI Node SDK and every OpenAI-compatible client (Vercel AI SDK, Continue, aider, LiteLLM, ...)same base URLprotocol; the TypeScript SDK's live test runs against production
Anthropic SDK / Claude Code/v1/messages with the router as base_urlCI (Messages API surface)
OpenAI Responses clients/v1/responsesCI
MCP hosts (VS Code, Cursor, Windsurf, Claude Desktop, Claude Code)/mcp (Streamable HTTP) or osr mcp (stdio)CI (the official mcp client, mcp>=1.10,<2); live in production
@opensmartroute/sdk (TypeScript)typed REST client over the platform APICI (surface and live tests)
osr CLIthe SDK, in a terminalCI

Agent frameworks

FrameworkIntegrationDepthVerified
LangGraphadapters.frameworks.langgraph_node / langgraph_conditiondeep adapter (a routing node and an edge condition)CI (the node runs without LangGraph installed; the graph wiring is the framework's)
Microsoft Agent Framework / AutoGenadapters.frameworks.maf_router_executordeep adapter (an executor)CI
OpenAI function calling / Agents SDKadapters.frameworks.openai_tool_spec / openai_tool_handlerdeep adapter (the router as a tool)CI
LangChainChatOpenAI(base_url=<router>/v1, model="auto")protocolprotocol
CrewAIthe OpenAI-compatible LLM settingprotocolprotocol
LlamaIndexOpenAILike(api_base=<router>/v1)protocolprotocol
Semantic Kernelthe OpenAI connector with a base URLprotocolprotocol
pydantic-aithe OpenAI model with a base URLprotocolprotocol

SDK adapters (opensmartroute.adapters)

ModuleConnectsVerified
a2aA2A Agent Cards as agent targets; a2a_handler with task pollingCI
anthropic_clientthe Anthropic Messages API as a chat handlerCI
cataloguethe live model catalogue (prices, context windows)CI; live every 8 hours on the platform
frameworksLangGraph, Agent Framework, OpenAI tools (above)CI
handlersHTTP endpoints, MCP tools and asynchronous queues as handlersCI
harnessagent harnesses: callable, HTTP, subprocessCI
marketplacethe marketplace (search, pull, sync, signed manifests)CI; live in production
mcpMCP tool catalogues (stdio and Streamable HTTP), resources and promptsCI (official client)
mcp_serversMCP server recommendation from a requestCI
mock_clientthe mock provider kind: a deterministic, network-free provider for tests, demos and pipelinesCI
openai_compatOpenAI-compatible HTTP client (chat, embeddings, retries, error mapping)CI; live (above)
optionaladapters with extra dependencies, imported lazilyCI
personaspersona catalogues as targetsCI
semantic_routera vLLM semantic-router configuration imported as rulesCI
skillsAgent-Skills SKILL.md packages as targetsCI
websearchweb knowledge and feeds for the self-improverCI; live on the platform

Runtimes

RuntimeVerified
CPython 3.11, 3.12 (Linux, Windows)CI on every push; 3.11 is the floor
Node 22 (web, TypeScript SDK, extension, desktop)CI
PostgreSQL 16 (platform)CI and production
Redis, Kafka (platform clustering, optional)CI (platform cluster job)

A vendor that changes its wire format breaks a protocol row first; the CI rows carry a fake of the format the SDK was written against, so a change shows up as a red build only once the fake is updated - treat a protocol row as "should work" and a CI or live row as "does work".

Something wrong or out of date on this page? Tell us - the page is named for you, so a one-line note is enough.