You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The OpenRouter Python SDK currently only supports type: "function" tools via ToolDefinitionJSON. This means provider-native tool types — such as Anthropic's computer use, bash, and text editor tools — cannot be passed through the SDK.
All three major LLM providers now offer native computer use capabilities with their own tool type schemas:
The SDK's ToolDefinitionJSON model only accepts type: Literal["function"] with a function field, so the native tool type is either rejected or silently converted to {"type": "function", "function": {"name": "computer"}} — losing all provider-specific fields (display_width_px, display_height_px, etc.).
Expected behavior
The SDK should support passing through provider-native tool types when routing to the corresponding provider. For example, when targeting anthropic/claude-sonnet-4-20250514, the SDK should be able to forward computer_20250124 tool definitions directly to the Anthropic backend.
Context
Anthropic's computer use requires both the beta header (anthropic-beta: computer-use-2025-01-24) and the tool definition in the tools array (with screen dimensions). Neither alone is sufficient.
OpenAI's computer use uses the Responses API with a dedicated computer_call / computer_call_output flow, separate from standard function calling.
The existing langchain-openrouter integration inherits this limitation since ChatOpenRouter.bind_tools() calls convert_to_openai_tool() on all tools.
Support a generic passthrough field for provider-native tool definitions that bypasses SDK-level validation.
Approach 1 seems simplest and most future-proof — if a provider adds a new tool type, the SDK doesn't need updating.
Impact
Computer use is becoming a core capability across all major LLM providers. Without SDK support for native tool types, developers using OpenRouter cannot leverage these capabilities and must fall back to direct provider API calls, which defeats the purpose of using a unified routing layer.
Problem
The OpenRouter Python SDK currently only supports
type: "function"tools viaToolDefinitionJSON. This means provider-native tool types — such as Anthropic's computer use, bash, and text editor tools — cannot be passed through the SDK.All three major LLM providers now offer native computer use capabilities with their own tool type schemas:
computer_20250124,bash_20250124,text_editor_20250124tool_useblockscomputer_use_preview(Responses API)computer_calloutput itemscomputerUse(GenerateContent API)computerUseActionpartsCurrent behavior
When passing a non-function tool definition (e.g., Anthropic's computer use tool) through the SDK:
The SDK's
ToolDefinitionJSONmodel only acceptstype: Literal["function"]with afunctionfield, so the native tool type is either rejected or silently converted to{"type": "function", "function": {"name": "computer"}}— losing all provider-specific fields (display_width_px,display_height_px, etc.).Expected behavior
The SDK should support passing through provider-native tool types when routing to the corresponding provider. For example, when targeting
anthropic/claude-sonnet-4-20250514, the SDK should be able to forwardcomputer_20250124tool definitions directly to the Anthropic backend.Context
anthropic-beta: computer-use-2025-01-24) and the tool definition in thetoolsarray (with screen dimensions). Neither alone is sufficient.computer_call/computer_call_outputflow, separate from standard function calling.langchain-openrouterintegration inherits this limitation sinceChatOpenRouter.bind_tools()callsconvert_to_openai_tool()on all tools.cache_controlfield toToolDefinitionJSON#51 (cache_control stripped from tool definitions) — same root cause of the SDK's tool model being too narrow.Possible approaches
ToolDefinitionJSONto accept arbitrary tool type dicts (passthrough mode), letting the API backend validate provider-specific schemas.ToolDefinitionJSON(e.g.,AnthropicComputerUseTool, etc.).Approach 1 seems simplest and most future-proof — if a provider adds a new tool type, the SDK doesn't need updating.
Impact
Computer use is becoming a core capability across all major LLM providers. Without SDK support for native tool types, developers using OpenRouter cannot leverage these capabilities and must fall back to direct provider API calls, which defeats the purpose of using a unified routing layer.