Provider API Coverage

The audit covers the public OpenAI inference APIs, built-in tools and their supporting resources, including Responses, media, Files and Batch. Organization, billing, evaluation and training administration are not exhaustively audited.

• Agent skills: Externally prepared skill references can be attached to hosted shell through raw environment.skills tool options. RubyLLM has no dedicated Skills upload/version-management API. OpenAI Skills API and shell attachments.
• Asynchronous research: Long research can run through Responses background mode, but RubyLLM has no response retrieval/cancellation/polling lifecycle. Setting background through provider_options alone does not complete the research job. OpenAI deep research. OpenAI background mode.
• Background Responses jobs: Wire fields can pass through, but RubyLLM normally uses store:false and has no public response retrieval/polling or hosted conversation resource lifecycle. OpenAI Responses create.
• Browser use, Computer use, Apply patch tool: Raw Responses tool definitions can be sent. RubyLLM does not implement the dedicated client computer-action/apply-patch result types and execution loops; these output items are recorded as ServerToolCall rather than dispatched as local Ruby tools. OpenAI computer and browser use. OpenAI apply patch tool.
• Fast inference: Fast/Priority processing is selected with the service_tier request parameter, available through with_params in 1.16 and provider_options in 2.0. RubyLLM has no dedicated public Fast mode switch. OpenAI Fast mode.
• File listing and deletion, Vector store management: File listing/deletion and vector-store lifecycle/search APIs are not provided by the public file abstraction. Hosted file_search can use externally prepared vector stores. OpenAI tools.
• File search store management: OpenAI vector stores have a separate creation, indexing and search lifecycle. RubyLLM can use a prepared vector_store_id with file_search but cannot manage the store. OpenAI file search and vector stores.
• Fine-tuning, Responses over WebSocket: No Realtime/WebSocket transport or fine-tuning job management API. Calling an already fine-tuned model is supported separately. Treat training and administration as scope boundaries. OpenAI audio and speech. OpenAI Responses create.
• Image batches, Other batch operations: The Batch API also accepts image generation, image edits, moderation and legacy completions. RubyLLM only registers Responses, Chat Completions and embedding batches. OpenAI Batch API.
• JSON object mode: Schema-based structured output has its own API; raw JSON-object response mode uses provider options (with_params in 1.16). OpenAI Responses create.
• Programmatic tool calling, Shell and computer tools: Raw hosted-tool definitions can be sent; specialized client tool output types and control loops are not first-class. Do not equate raw hash acceptance with a complete tool implementation. OpenAI tools.
• Tool search: The hosted tool_search definition and defer_loading fields can pass through raw tools. RubyLLM has no dedicated deferred-tool registry or namespace-aware dispatch; function-call namespace information is not normalized into ToolCall. OpenAI tool search and namespaces.
• Voice cloning: OpenAI documents custom voice creation from consent and sample audio for eligible customers. RubyLLM has no voice/consent creation lifecycle; using an externally created voice is a separate speech option. OpenAI text-to-speech and streaming.

The audit includes the direct Claude Messages, Files, Batches and Managed Agents APIs. Built-in coverage is conditional on supported models and documented restrictions; new API offerings are compared against both codebases. Organization and billing administration are outside scope.

• Advisor tool, Agent skills, Browser use, Computer use, Context editing, Fast inference, Programmatic tool calling, Provider-managed fallback, Tool search, Task budgets: No named common RubyLLM operation found. Provider-specific tool declarations, tool provider_options, payload options or headers are required. These interfaces may additionally need caller-managed lifecycle or output parsing; they are not counted as native coverage. Anthropic feature availability. Anthropic tool search.
• File listing and deletion: Provider exposes file listing and deletion. RubyLLM implements upload, metadata lookup and download, but not list/delete operations. Anthropic Files API.
• Prefix completion: Older Claude models accept a final assistant prefill. Raw messages work in 1.16; 2.0 can add an assistant message before generate. Claude 4.6 and newer reject prefill. Claude Messages prefill.
• Shell and computer tools: Claude exposes client-executed bash, text editor and computer tools. Provider declarations and application execution are required. Anthropic feature availability.

The audit covers the Gemini Developer API, including generateContent, stateless Interactions, media, files, caches and batches. One-shot Live transcription remains supported. Live conversations and provider-managed conversation storage are outside this release; other Google Cloud products are outside this provider inventory.

• Agent skills: Interactions remote environments can mount skills. RubyLLM implements model Interactions chat and MCP, but does not create or configure managed-agent environments or mounted skills. Gemini Interactions API reference.
• Asynchronous research: Deep Research runs as a background Interactions agent. RubyLLM implements synchronous and streamed model Interactions, but not research-agent submission, background polling or result retrieval. Gemini Deep Research.
• Browser use: The Computer Use tool supports browser environments. Raw tool configuration and application-side action execution are required. Gemini Computer Use.
• Computer use: Provider tool configuration is available through raw tool hashes. google_maps has a 2.0 named alias, while computer_use remains provider-specific and needs caller-side execution. Gemini API overview and Interactions migration.
• Context editing: Live contextWindowCompression can remove old turns through a sliding window. Both versions lack the required Live transport; generateContent caching is separate. Gemini Live session and context-window management.
• Fast inference: GenerateContent supports service_tier priority in its request body. Both versions can supply it as raw provider options. Gemini GenerateContent Priority inference.
• File listing and deletion: Provider exposes file listing and deletion. RubyLLM implements upload, metadata lookup and download, but not list/delete operations. Gemini Files API.
• File search store management: RubyLLM can call the File Search tool using an existing store, but does not create/delete stores or import/index their documents. Ordinary RubyLLM.upload targets the separate Files API. Gemini File Search.
• Guardrail configuration: Both versions can pass safetySettings. The common API does not wrap individual safety thresholds. Gemini safety settings.
• Image batches: 2.0 can stage a chat request with raw image response modalities and parse generated attachments. No dedicated batched paint API; 1.16 has no Batch client. Gemini Batch API.
• JSON object mode: Both versions can pass generationConfig.responseMimeType application/json without a schema. Gemini GenerateContent schema.
• Music generation: Lyria has a documented generateContent route. Version 2 can return generated audio attachments through Chat, but has no music operation or Lyria-specific Interactions/Live Music lifecycle. Version 1.16 drops audio attachments when accompanying lyrics are returned. Lyria music with generateContent.
• Other batch operations: TTS models support Batch. 2.0 can batch raw AUDIO generation chat requests and return attachments; there is no batched speak result API. Gemini TTS batch support.
• Omni video generation: Newer Omni video generation/editing API is absent. Veo video generation is independently implemented and counted as native. Gemini video generation.
• Shell and computer tools: Computer Use supports desktop/mobile/browser actions. Raw tool definitions and caller execution are required; this does not imply a hosted shell. Gemini Interactions API reference.
• Streaming speech generation: Gemini TTS supports streamGenerateContent on selected models. RubyLLM.speak sends a synchronous request and has no speech streaming implementation. Gemini TTS streaming.
• Video editing: The Omni video-editing request and job/result lifecycle are not implemented by the model Interactions adapter. Existing Veo generation uses its separate video protocol. Gemini Omni video editing.

The audit covers Vertex AI generative inference, including Gemini, supported partner models, media, caching, batches and Interactions. Direct Gemini or Anthropic features are not assumed to exist on Vertex. Separate Cloud Vision and Document AI services are outside scope.

• Remote MCP tools: RubyLLM.research/research_later connects a remote MCP server through the hosted Deep Research agent, with an explicit agent identity and managed background lifecycle. A fresh Microsoft Learn lookup completed and returned an authoritative microsoft_docs_search result citation. Both completed GET and streamed retrieval omit the actual MCP call/result steps on this route; the citation also lacks a source URL. The common parser retains native calls/results/thinking/citation data when actually returned, but RubyLLM does not invent missing records or URLs. This remains partial, consistently with other providers that drop expected tool-result records. The existing ordinary model chat route is unchanged. Hosted MCP exposes no approval policy; unsupported approval options raise before submission. Vertex AI and Agent Platform API inventory and Interactions reference. Vertex Deep Research. Anthropic feature availability. Gemini Interactions OpenAPI schema.
• Agent skills: Managed Agents can configure skills and environments. Neither version implements these agent or skill resources. Vertex managed-agent tools and skills.
• Browser use, Computer use, Context editing, Tool search, Shell and computer tools: Claude on Google Cloud documents this tool/context feature. 2.0 can inject its Anthropic wire declaration and caller-managed behavior; 1.16 has no Anthropic publisher protocol. Anthropic feature availability.
• Fast inference: Priority PayGo uses the X-Vertex-AI-LLM-Shared-Request-Type header, available through request headers in both versions. Claude fast mode is not offered on Google Cloud. Vertex Priority PayGo. Claude fast-mode platform restrictions.
• File listing and deletion: GCS exposes object listing/deletion; the public RubyLLM UploadedFile API only uploads, finds and downloads. Internal batch-output listing is not a general file-management API. Cloud Storage object operations.
• File search store management, Vector store management: RAG Engine exposes corpus and file lifecycle plus managed vector storage. Neither version implements these resources; raw retrieval can use an externally prepared corpus. Vertex RAG Engine resources.
• Fine-tuning: Google Cloud supports tuning jobs. RubyLLM has no tuning lifecycle client; this is outside inference operation totals. Vertex AI Tuning API.
• Guardrail configuration: Gemini safetySettings and Model Armor request settings can be passed as provider options. Separate Cloud security services are outside this inference row. Vertex generateContent request and tool schemas.
• Image batches: Google Cloud documents batch image generation. 2.0 can stage raw image-output Gemini chat requests through its batch client and parse attachments; no batched paint API. Vertex Gemini image model batch support.
• Interactions API: RubyLLM now registers a dedicated Vertex Interactions dialect for single-turn hosted Deep Research; see Asynchronous research for its implemented lifecycle. A general Vertex Interactions conversation/client API for other agent/model families, continuation and resource management remains unimplemented. Earlier ordinary Gemini model requests to this Vertex endpoint returned Unsupported model interaction. Vertex AI and Agent Platform API inventory and Interactions reference. Vertex Deep Research. Gemini Interactions OpenAPI schema.
• JSON object mode: Gemini generationConfig supports application/json without a schema; both versions can pass it as provider options. Vertex generateContent request and tool schemas.
• Music generation: Lyria music is exposed through Vertex Interactions and Lyria model APIs. RubyLLM has no matching music protocol or result API. Vertex AI and Agent Platform API inventory and Interactions reference.
• Omni video generation, Video editing: Google Cloud documents Omni generation and video editing through Interactions. RubyLLM implements Veo prediction jobs but has no Interactions protocol. Vertex Omni and Veo extension. Vertex video editing.
• Prefix completion: 2.0 supports older Claude publisher routes with assistant prefill; raw messages can be supplied. Claude 4.6 and newer reject prefill. 1.16 lacks the Anthropic publisher adapter. Claude Messages prefill. Anthropic feature availability.
• Responses API: Google Cloud offers Grok Responses at endpoints/openapi/responses. RubyLLM Vertex only registers Gemini, Anthropic, Mistral and Chat Completions; no Responses route. Vertex Grok Responses.
• Streaming speech generation: Vertex Live provides streamed generated speech; RubyLLM has no Live transport. Its synchronous speak path does not stream audio. Vertex Live API. Gemini TTS API choices.
• Task budgets: Claude task budgets are documented on the direct API, but the task-budget page does not establish availability on this cloud platform. No platform-specific confirmation found; raw option acceptance alone is insufficient. Claude task budgets. Anthropic feature availability.
• Voice cloning: The generateContent schema documents replicatedVoiceConfig from an audio sample. Raw speech configuration can be supplied; no common voice-cloning API or resource lifecycle exists. Vertex generateContent request and tool schemas.

The audit covers Bedrock foundation-model inference through Runtime and Mantle, plus documented inference resources and controls. Features may require an explicit protocol, model, region or IAM permission. Separate AWS Data Automation, AgentCore and general AWS services are outside scope.

• Background Responses jobs: Mantle Responses documents background execution. Raw provider options can express request fields, but RubyLLM has no hosted-response retrieval, polling or cancellation lifecycle. Normal chat requests send store:false and replay application-owned history. Bedrock Responses state and background execution.
• Computer use, Context editing, Tool search, Shell and computer tools: Claude on Bedrock documents this feature. Provider-specific tool/context declarations and caller-managed execution or state are required. Anthropic feature availability.
• Fast inference: Converse performanceConfig.latency optimized is available through raw options in both versions on AWS-listed models/regions. Bedrock latency-optimized inference.
• File listing and deletion: S3 offers object listing/deletion. RubyLLM public file API only uploads, finds and downloads; internal batch-output listing does not expose general management. S3 object API operations.
• File search store management, Vector store management: Bedrock managed Knowledge Bases expose managed retrieval storage and lifecycle operations. RubyLLM has no Knowledge Base resource client. Bedrock managed Knowledge Base creation.
• Fine-tuning: Provider exposes model customization jobs; RubyLLM does not manage them. Outside inference totals. Bedrock model customization.
• Guardrail configuration: guardrailConfig can be set on Converse using raw request options in both versions; not a provider-neutral feature API. Bedrock Converse API.
• Prefix completion: Older Claude models can consume final assistant prefill through raw messages; newer Claude models reject it. No common prefix setter. Bedrock Claude Messages parameters.
• Task budgets: Claude task budgets are documented on the direct API, but the task-budget page does not establish availability on this cloud platform. No platform-specific confirmation found; raw option acceptance alone is insufficient. Claude task budgets. Anthropic feature availability.

The audit covers Azure OpenAI and Foundry model inference, including documented partner-model embedding and reranking operations. Azure Speech, Content Safety and Document Intelligence are separate products outside scope. Image and audio operations have Azure-specific endpoint handling with HTTP regression coverage. Live checks returned DeploymentNotFound for the configured resource; these operations still require compatible deployments.

• Embedding batches: Current Azure documentation conflicts on embedding batches: the v1 Batch endpoint enum lists /v1/embeddings, while its prose says only chat is supported; the batch guide and regional SKU inventory list no GlobalBatch or DataZoneBatch embedding model. Registry and fresh resource catalog checks confirm embedding models, not batch-capable deployments. RubyLLM has no Azure embedding-batch adapter, but provider availability must be established before this can be classified as a missing integration. No speculative upload or batch job was submitted. Azure batch REST reference. Azure global batch processing. Current Azure model availability by deployment type. Azure v1 Files REST reference.
• Agent skills: The Azure Responses REST schema documents hosted shell container skills by ID or inline data. A raw shell environment can pass these through. RubyLLM has no dedicated skill-management or attachment API. Azure OpenAI Responses REST reference.
• Asynchronous research, Background Responses jobs: Azure documents stored-response continuation and background jobs. Raw fields can pass through, but RubyLLM has no response retrieval/polling/cancellation lifecycle and normally sends store:false. Azure OpenAI Responses.
• Browser use, Computer use, Apply patch tool, Shell and computer tools: The Azure Responses schema documents these specialized tools. Raw tool definitions can be sent, but RubyLLM does not implement their dedicated client execution/output lifecycles. Azure OpenAI Responses REST reference. Azure OpenAI Responses.
• File listing and deletion, File search store management, Vector store management: Azure exposes file listing/deletion and vector-store resource APIs. RubyLLM Files supports upload/metadata/download, not these management lifecycles. Azure OpenAI v1 preview API inventory.
• Fine-tuning: No realtime session or fine-tuning job lifecycle in either version. Training APIs are outside inference scope. Azure OpenAI Responses. Azure image and audio REST reference.
• JSON object mode: Raw JSON mode uses wire options; structured schemas have their own public API. Azure OpenAI Responses.
• Responses batches: The provider documents Responses batch requests, but RubyLLM does not register a Responses batch dialect for this provider. Azure global batch processing.
• Tool search: Azure documents Responses tool search. Raw tools can include the wire options, but RubyLLM lacks a deferred-tool registry and namespace-aware call dispatch. Azure OpenAI Responses. Azure OpenAI Responses REST reference.
• Video editing: Azure Sora 2 documents the videos.remix endpoint. RubyLLM Azure::Videos only implements the earlier generation-job workflow, not remix. Azure Sora video generation.
• Responses over WebSocket: Azure explicitly documents Responses over WebSocket. RubyLLM has no WebSocket Responses transport. Azure Responses WebSocket mode.

The audit covers the public xAI model APIs, search tools, media and supporting resources. It does not include consumer Grok UI features or assume an API exists for an announced capability.

• Fast inference: Priority processing accepts service_tier on Chat Completions and Responses. Both versions can pass the wire option; neither has a dedicated priority-processing API. xAI Priority Processing.
• File listing and deletion, File search store management, Vector store management: xAI exposes file and Collections management/indexing APIs. RubyLLM implements attachment upload/metadata/download and querying an existing collection through a hosted tool, not collection creation/indexing or file listing/deletion. xAI Collections API.
• Image batches: Current xAI Batch API documents image-generation jobs; RubyLLM only serializes chat requests for xAI. xAI batch API.
• JSON object mode: Wire JSON mode uses provider options; schema-based structured output has a public method. xAI models.
• Voice cloning: xAI exposes custom voice creation from a recording, gated to Enterprise teams. RubyLLM has no custom-voice creation/list/delete API; speak can use a voice ID prepared externally. xAI custom voices and Enterprise API restriction.
• Responses over WebSocket: This row is Responses over WebSocket, not Voice. xAI documents /v1/responses WSS response.create and previous_response_id continuation even store:false. RubyLLM Voice uses /v1/realtime; it does not implement this distinct Responses transport. xAI voice REST and WebSocket APIs. xAI speech to text. xAI Responses WebSocket mode.

The audit covers the public DeepSeek API and its documented request controls. Local model hosting, consumer applications and third-party deployments are outside scope.

• File listing and deletion: DeepSeek exposes image file listing and deletion. RubyLLM now supports upload and metadata lookup, but the public file API has no list or delete operation. A file-content download endpoint is not documented. DeepSeek Files API.
• Fill-in-the-middle completion: DeepSeek documents a separate FIM Completion beta API. RubyLLM has no completion_url dialect for /beta/completions. DeepSeek Files API.
• JSON object mode: JSON-object mode uses raw text.format options on Responses, or raw response_format on Chat Completions. with_schema on Responses is the dedicated JSON Schema API and is counted separately as built in. DeepSeek Responses reference.
• Prefix completion: DeepSeek documents Chat Prefix Completion (Beta); raw message fields can be supplied through provider options. There is no RubyLLM prefix-completion method. DeepSeek Files API.
• Apply patch tool: The alias sends a custom apply_patch definition, but custom_tool_call output is treated as a server item rather than a callable local function; no dedicated client apply-patch loop exists. DeepSeek Responses compatibility.

No built-in Cohere provider exists at tag 1.16.0. Version 2 registers a native Cohere v2 protocol. General chat documents are text or image inputs, not arbitrary uploaded PDFs.

• File listing and deletion: Cohere datasets can be listed and deleted. RubyLLM has no Cohere dataset lifecycle; these resources are for batch/embed data, not general conversation attachments. Cohere list datasets. Cohere delete dataset.
• JSON object mode: Chat v2 accepts response_format.type=json_object without a schema. RubyLLM supports schema output separately; plain JSON object mode uses provider_options. Cohere Chat API.

The audit includes Mistral inference and hosted tools. RubyLLM implements default Chat Completions with multi-completion hosted tools and an explicit stateless Conversations protocol. Both replay completed tool results from application-owned history. Stored conversations and provider confirmations that require them are outside this release. Managed agent, library and skill resources remain separate.

• Agent skills: Mistral has a dedicated /v1/skills resource API. RubyLLM registers no skill or agent resource protocol. Mistral Skills API.
• Classification: Custom classification endpoint has no domain operation. Mistral Chat API and endpoint index.
• File listing and deletion: Mistral exposes file listing and deletion, while RubyLLM Files implements upload, metadata lookup and download only. Mistral Files API.
• File search store management: Mistral Libraries expose managed indexing and retrieval. RubyLLM has no library/index creation or management API; its Files integration is separate. Mistral Libraries API. Mistral RAG search-index API.
• Fill-in-the-middle completion: Dedicated /fim/completions endpoint is absent. Mistral Chat API and endpoint index.
• Fine-tuning: The official page labels fine-tuning deprecated and no longer actively supported, while retaining job/pricing documentation. The current endpoint index omits it. RubyLLM has no fine-tuning lifecycle in either version; public documentation does not establish whether any existing customer can still create a legacy job. Mistral deprecated fine-tuning documentation. Mistral complete documentation inventory.
• JSON object mode, Prefix completion: Mistral documents plain JSON-object response mode and assistant prefix completion. These wire options can be supplied through with_params/provider_options; no dedicated plain-JSON or prefix-completion RubyLLM operation exists. Mistral Chat API and endpoint index.
• Other batch operations: Provider also batches FIM, moderation, OCR, classification, conversations and transcription. Mistral batch processing.
• Vector store management: Mistral Libraries and RAG search-index APIs support indexing and hosted retrieval. RubyLLM can pass an externally prepared document library into a hosted tool, but has no library/index creation or management API. Mistral Libraries API. Mistral RAG search-index API.
• Voice cloning: Mistral speech accepts reference audio through ref_audio; RubyLLM.speak can pass that field via provider_options. Mistral also exposes custom voice creation and management, which has no dedicated RubyLLM lifecycle. Mistral Speech API. Mistral custom voice API.

The audit includes Chat Completions, Responses, Messages, media, Files, Batch, routing and documented server tools. RubyLLM defaults to Chat Completions and explicitly selects Responses for its supported hosted tools. Messages-specific tools and incomplete provider result contracts are identified separately. Workspace administration is sampled, not exhaustively audited.

• File search tool, Browser use, Computer use: The Responses request schema includes this tool shape, but the supported server-tools catalog does not establish its working upstream integration or required resource setup. RubyLLM has an explicit Responses protocol; schema forwarding alone does not verify this particular hosted tool. Create a response. Server Tools. OpenRouter complete documentation and API inventory.
• Remote MCP tools: OpenRouter Responses can invoke remote MCP; actual stream events expose call IDs and arguments, but upstream omits tool names, results and approval records. Requires explicit require_approval: never; omitted/default and approval modes reject before HTTP. Partial records preserve only actual wire data, and do not become local tools or fabricated approvals. Create a response. Server Tools. OpenRouter complete documentation and API inventory.
• Chat batches, Embedding batches, Responses batches: Implemented documented beta inline batch submission/find/results with one model and protocol, text-only preflight, original request ordering, scalar/array embedding shape, per-request failures and provider aggregate invoice. Cancellation is not exposed. Live submission returned HTTP 400 does not have a :batch endpoint for both normal and catalog-listed variant IDs; embedding rollout also blocked. No real batch lifecycle/results completed, so endpoint integration remains unverified. OpenRouter Batch API beta. Public catalog including :batch variants.
• Advisor tool, Task budgets: OpenRouter accepts its advisor tool type and request max_tool_calls / stop_server_tools_when budgets through raw tool definitions/request options. RubyLLM has no dedicated Advisor alias or server-loop budget API. Server Tools.
• Background Responses jobs: The Responses schema accepts background, but the guide describes synchronous/SSE requests and the audited endpoint inventory does not document response retrieval or cancellation. RubyLLM implements Responses inference, but neither provider background-job availability nor a working RubyLLM polling lifecycle is established. Create a response. OpenRouter Responses API.
• Classification: OpenRouter Custom Classifiers are provider-side classification rules for request/generation analytics, with API configuration. RubyLLM does not create these classifiers. This is not a standalone arbitrary-text classify operation. Custom Classifiers.
• Fast inference: The request service_tier field supports priority and accepts fast as an alias. RubyLLM can send it via raw provider request options; there is no dedicated provider-neutral speed-mode API. Support and billing vary by model. Create a response. OpenRouter service tiers.
• File listing and deletion: OpenRouter exposes workspace file listing and deletion, but RubyLLM only implements upload, metadata lookup and download. The OpenRouter Files subclass does not add listing or deletion to the shared file abstraction. OpenRouter Files API.
• Guardrail configuration: OpenRouter exposes guardrail configuration/management endpoints. RubyLLM does not create or manage workspace guardrails; request routing preferences do not replace this administrative API. OpenRouter complete documentation and API inventory.
• JSON object mode: OpenRouter response_format: {type: json_object} is available on supporting models through RubyLLM raw request options. with_schema provides the separate JSON-schema structured-output operation. OpenRouter request parameters.
• Omni video generation: The videos API accepts input_references with image, audio and video assets on compatible models such as Seedance 2+. RubyLLM animate natively maps only first/last images; extra multimodal references require provider_options. Submit a video generation request.
• Prefix completion: The API supports assistant conversation messages, but the reviewed contract does not establish whether a final assistant prefix is continued for supported models or merely treated as completed history. This needs provider/model confirmation; no support claim is inferred from the serializer. OpenRouter complete documentation and API inventory.
• Provider-managed fallback: OpenRouter supports server-side model fallback lists and provider routing preferences through request fields. RubyLLM can forward these fields, but its client model-fallback API is a different feature. OpenRouter model fallbacks.
• Response caching: Separate whole-response cache uses request headers. It is not prompt caching. OpenRouter response caching.
• Apply patch tool: The existing alias now has an explicit Responses route. Upstream Apply Patch proposes and validates diffs but never applies files: applications must send apply_patch_call_output afterward. Raw output items survive, but RubyLLM has no dedicated local patch execution/result lifecycle. Do not label this a fully implemented hosted editing tool. Server Tools. Shell. Bash. Tool Search. Apply Patch proposal and client output lifecycle.
• Tool search: OpenRouter documents Tool Search on Responses/Messages. RubyLLM now implements Responses shell and apply-patch declarations, but has no Tool Search alias or dedicated deferred-tool discovery/result lifecycle. Server Tools. Shell. Bash. Tool Search.
• Video editing: Compatible video models accept reference videos through input_references for video-conditioned generation. RubyLLM exposes this through raw provider_options, not a dedicated editing operation; exact transformations remain model-specific. Submit a video generation request.
• Voice cloning: Raw input_references can be sent through speech provider_options; no shared voice-reference argument. OpenRouter speech generation and reference voices.

The audit includes Sonar, embeddings, standalone search, files and Router. RubyLLM defaults to Sonar; protocol: :router_chat_completions selects the stateless Router adapter. Router request/result contracts have unit coverage, but the configured account returned HTTP 403 limited-preview denial. Perplexity Agent is outside this release because it requires provider-managed conversation state. Perplexity documents Sonar retirement on September 27, 2026.

• Audio input: The explicitly selected Router protocol serializes documented input_audio content with WAV or MP3 data, while default Sonar still rejects audio. The request contract and public Chat encoding are unit-tested, but the published Router catalog identifies no verified callable audio-capable model and the configured account has no preview access. Audio inference remains unverified; no model capability was invented. Perplexity Router API. Router models and cache pricing. Perplexity Router API (OpenAI-compatible) API specification. Media & Attachments. Perplexity Router Chat Completions request, tools, cache and audio contracts.
• Token counting: A fresh review of the Router Messages OpenAPI finds CountMessageTokensRequest/Response components describing POST /router/v1/messages/count_tokens, but the published paths contain only /router/v1/messages and the Router overview omits token counting. The Chat Completions dialect does not establish this separate endpoint. Availability remains unresolved, and RubyLLM does not invent a token-count route. Perplexity Router API (Anthropic-compatible) API specification. Perplexity Router API. Router Messages API reference.
• Asynchronous research: Asynchronous Sonar Deep Research job submission/polling is absent. Perplexity Deep Research controls and async API.
• Contextual embeddings: Contextualized embedding requests and nested result groups have no dedicated renderer/parser. Perplexity embeddings.
• JSON object mode: On the explicitly selected router_chat_completions protocol, with_provider_options(response_format: { type: "json_object" }) forwards the documented JSON object option. The registered Router path handles endpoint selection; a custom base URL is unnecessary. The configured account has no Router preview access, so JSON object output is not live-verified. with_schema provides structured JSON Schema output separately. Perplexity Router API (OpenAI-compatible) API specification. Perplexity Router API.
• Prompt cache options: Router documents prompt-cache keys/options and block-level breakpoints (Chat Completions) or cache_control (Messages); Agent usage also includes cache read/write accounting. RubyLLM defaults to legacy Sonar, without dedicated Router selection or these caching translations. Custom api_base/provider_options requests are unverified integration paths. Perplexity Router API (OpenAI-compatible) API specification. Perplexity Router API (Anthropic-compatible) API specification. Create Agent Response.
• Provider-managed fallback: Perplexity Router documents automatic routing and provider-managed fallback. RubyLLM exposes no dedicated server-fallback configuration or validated fallback-result accounting. Router execution remains access-limited; application-side with_fallbacks is a separate feature. Routing & Reliability. Create Agent Response.
• Responses API: The separate Router /router/v1/responses endpoint has no registered RubyLLM protocol. The retained Router integration uses /router/v1/chat/completions. Perplexity Agent is outside the release scope because it requires provider-managed conversation state. Perplexity Router API (OpenAI Responses-compatible) API specification. Perplexity Router API.
• Standalone search API: Standalone ranked Search API is distinct from Sonar search-in-answer. Perplexity Search API.

The audit includes speech generation, transcription and Text Intelligence. RubyLLM integrates speech and prerecorded-file transcription, including streaming output. Voice Agent conversations are outside this release; their documented offerings remain listed separately. Account, project and billing administration are outside scope.

• Classification: Text Intelligence /v1/read exposes intent, topic and sentiment analysis. RubyLLM does not implement the Read API; this is separate from transcription keyword formatting. REST API API specification. Deepgram complete documentation and API inventory.
• Text analysis API: Separate /v1/read endpoint for text intent/sentiment/topics is absent. Deepgram Text Intelligence Read API.

The audit includes speech APIs and Flows image/video generation and assets. RubyLLM integrates speech, transcription and Flows media operations. ElevenLabs Agents conversations and hosted-agent administration are outside this release; their provider offerings remain listed separately. Account and billing administration are outside scope.

• Agent skills: ElevenAgents Procedures are reusable task-specific instructions loaded when relevant, with create/compile/get/delete endpoints. RubyLLM does not integrate these hosted skills/procedures. Procedures. ElevenLabs complete documentation and API inventory.
• Dubbing, Sound effects: Separate ElevenLabs audio generation operations are not covered by speak/transcribe. ElevenLabs audio API overview.
• File listing and deletion: RubyLLM supports Flows media asset upload, metadata lookup and download. General asset listing and deletion have no dedicated public lifecycle. Hosted-agent knowledge-base and conversation-file administration are outside the release scope. ElevenLabs complete documentation and API inventory. Multimodal input. Create Image Generation.
• Fine-tuning: The public music fine-tunes API creates custom music fine-tunes. RubyLLM has no training/job lifecycle integration. This is separate from the already documented voice-cloning APIs. Create Music Finetune.
• Music generation: No /v1/music client. ElevenLabs music composition.
• Other batch operations: ElevenAgents exposes a batch RAG-index computation API. This specialized knowledge-base operation is not the same as batched chat or embedding-vector generation, and RubyLLM does not integrate it. Compute RAG index in batch. ElevenLabs complete documentation and API inventory.
• Provider-managed fallback: ElevenAgents supports default/custom/disabled model fallback sequences. RubyLLM does not configure these server-side agent fallbacks. Models.
• Video editing: RubyLLM Flows video generation accepts Seedance reference videos through with:. The separately advertised Kling O3 Edit/O1 Edit workflows have no implemented REST request/result contract; reference-conditioned generation does not claim those dedicated editing models. Image & Video. Create Video Generation.
• Voice cloning: ElevenAPI exposes instant and professional voice cloning and associated training/voice-management endpoints. RubyLLM accepts an existing voice ID for speech but does not create voices. ElevenLabs complete documentation and API inventory.
• Voice conversion: Speech-to-speech voice conversion has no public RubyLLM operation. ElevenLabs voice conversion.

Self-hosted Ollama uses the OpenAI-compatible Chat Completions and embeddings routes. Native Ollama endpoints and hosted web services are separate. Server/model/backend versions affect available capabilities. Scope: native and compatibility inference, plus the separately documented Ollama hosted search/fetch API. Local runner features are not assumed to exist on the Cloud host. Model-file imports and LoRA loading do not count as training jobs.

• Context compaction, Manual context compaction: Upstream main implements /v1/responses/compact and compaction handling on /v1/responses, but latest released v0.33.3 has neither route/handler. Released availability is therefore unconfirmed, rather than absent by API inventory. RubyLLM registers only Chat Completions for Ollama and has no integration for these main-branch Responses operations. Ollama v0.33.3 release (September 2, 2026). Ollama v0.33.3 registered inference routes. Ollama main registered inference routes. Ollama main Responses compaction implementation.
• Fill-in-the-middle completion, Prefix completion: Native /api/generate and compatible completions accept a prompt and suffix; RubyLLM has no completions operation. Ollama generation API. Ollama OpenAI compatibility.
• JSON object mode: The compatibility API accepts JSON object mode through raw response_format; with_schema exposes structured JSON Schema output. Ollama OpenAI compatibility.
• Responses API: Ollama offers stateless /v1/responses. RubyLLM registers only its Chat Completions dialect. Ollama OpenAI compatibility.
• Standalone search API, Standalone web fetch API: Hosted /api/web_search and /api/web_fetch require an Ollama account key; no domain wrapper. Ollama separate web search and fetch APIs.

Dedicated provider introduced in v2; v1 could target cloud manually through Ollama base URL/key configuration, so v1 missing means no named provider integration, not impossible access. Scope: native and compatibility inference, plus the separately documented Ollama hosted search/fetch API. Local runner features are not assumed to exist on the Cloud host. Model-file imports and LoRA loading do not count as training jobs.

• Prompt caching: Local Ollama documents prompt-cache reuse, but the Cloud documentation does not establish the hosted cache contract or cache-hit accounting. Ollama Cloud. Ollama generation API.
• Text embeddings: The local /api/embed endpoint is documented; the Cloud guide and public hosted catalog do not establish a callable Cloud embedding operation. Ollama Cloud. Ollama Cloud model catalog.
• Responses API: The compatibility reference documents local stateless Responses; the Cloud guide does not establish that endpoint on the remote ollama.com host. Ollama Cloud. Ollama OpenAI compatibility.
• Standalone search API, Standalone web fetch API: Separate hosted search/fetch APIs are not wrapped by the Cloud adapter. Ollama separate web search and fetch APIs.

Scope: GPUStack standard inference routes and documented built-in backends, including vLLM-Omni. Support is conditional on the deployed model, backend version and settings. The optional generic proxy can forward custom APIs; this audit does not claim those arbitrary extensions are absent. GPU administration, external model-provider integrations and loading fine-tuned weights are outside the comparison.

• Web search tool: with_server_tools(web_search: { require_approval: "never" }) maps to the configured browser search subtool. Search and fetch aliases coalesce into one MCP entry, retaining both requested filters. Requires an explicitly selected Responses protocol and a deployment-configured vLLM MCP tool server. RubyLLM requires explicit require_approval: never and rejects alias settings that change namespaces or broaden subtools. The upstream allowed_tools filter affects model-facing descriptions, not Harmony execution authorization. Harmony may omit tool result data; RubyLLM retains available call/action records without inventing results. No live endpoint is configured. Historical audit correction: tag 1.16.0 only routes GPUStack chat through Chat Completions and cannot call this Responses-hosted tool API. GPUStack inference APIs. vLLM server-side MCP tool examples. GPUStack v2.2.3 inference API routes and authenticated model proxy. vLLM v0.28.0 configured MCP examples. vLLM v0.28.0 MCP label and allowed-tools selection. vLLM v0.28.0 MCP session selection and complete MCP result items. vLLM v0.28.0 Harmony result omission and restricted response input types. allowed_tools filters model-facing descriptions, not execution permissions.
• Web fetch tool: with_server_tools(web_fetch: { require_approval: "never" }) maps to the configured browser open subtool. Requires a backend with subtool dispatch such as Harmony; released non-Harmony dispatch only implements search. Requires an explicitly selected Responses protocol and a deployment-configured vLLM MCP tool server. RubyLLM requires explicit require_approval: never and rejects alias settings that change namespaces or broaden subtools. The upstream allowed_tools filter affects model-facing descriptions, not Harmony execution authorization. Harmony may omit tool result data; RubyLLM retains available call/action records without inventing results. No live endpoint is configured. Historical audit correction: tag 1.16.0 only routes GPUStack chat through Chat Completions and cannot call this Responses-hosted tool API. GPUStack inference APIs. vLLM server-side MCP tool examples. GPUStack v2.2.3 inference API routes and authenticated model proxy. vLLM v0.28.0 configured MCP examples. vLLM v0.28.0 MCP label and allowed-tools selection. vLLM v0.28.0 MCP session selection and complete MCP result items. vLLM v0.28.0 Harmony result omission and restricted response input types. allowed_tools filters model-facing descriptions, not execution permissions.
• Code execution tool: with_server_tools(code_execution: { require_approval: "never" }) selects only the deployment-configured Python namespace, without enabling container tools. Requires an explicitly selected Responses protocol and a deployment-configured vLLM MCP tool server. RubyLLM requires explicit require_approval: never and rejects alias settings that change namespaces or broaden subtools. The upstream allowed_tools filter affects model-facing descriptions, not Harmony execution authorization. Harmony may omit tool result data; RubyLLM retains available call/action records without inventing results. No live endpoint is configured. Historical audit correction: tag 1.16.0 only routes GPUStack chat through Chat Completions and cannot call this Responses-hosted tool API. GPUStack inference APIs. vLLM server-side MCP tool examples. GPUStack v2.2.3 inference API routes and authenticated model proxy. vLLM v0.28.0 configured MCP examples. vLLM v0.28.0 MCP label and allowed-tools selection. vLLM v0.28.0 MCP session selection and complete MCP result items. vLLM v0.28.0 Harmony result omission and restricted response input types. allowed_tools filters model-facing descriptions, not execution permissions.
• Remote MCP tools: Dedicated with_server_tools(mcp: ...) on explicit Responses for deployment-configured vLLM MCP servers. Complete non-Harmony calls retain actual name/arguments/results and replay as supported function-call pairs, preserving original raw_content. Released Harmony/GPT-OSS output omits tool result messages, may emit built-in calls only as reasoning or search actions, and rejects native MCP/search output item replay. Incomplete records retain actual JSON as assistant history, without fabricated results. Requires explicit require_approval: never; URLs/connectors/authorization and ignored read_only filters reject before HTTP. Backend setup required; this is not arbitrary per-request MCP routing or a managed GPUStack service. allowed_tools filters the descriptions shown to the model; Harmony does not enforce it as execution authorization. Configure execution restrictions on the deployed tool server. GPUStack inference APIs. vLLM server-side MCP tool examples. GPUStack v2.2.3 inference API routes and authenticated model proxy. vLLM v0.28.0 configured MCP examples. vLLM v0.28.0 MCP session selection and complete MCP result items. vLLM v0.28.0 MCP label and allowed-tools selection. vLLM v0.28.0 Harmony result omission and restricted response input types. allowed_tools filters model-facing descriptions, not execution permissions.
• OCR / document parsing: GPUStack advertises OCR model deployment, but no dedicated document-parsing route or output contract is established in its inference reference. Reading an image through chat is counted under image input. GPUStack model ecosystem. GPUStack inference APIs.
• Classification: The opt-in vLLM proxy exposes classification endpoints. RubyLLM implements the separate plain tokenization route, but has no classification request or typed classification result API. GPUStack inference APIs. vLLM server API reference.
• JSON object mode: Compatible models accept response_format JSON object mode through raw options; RubyLLM exposes schema output separately. GPUStack inference APIs. vLLM server API reference.
• Realtime sessions: Built-in vLLM offers realtime transcription over WebSockets, but GPUStack documentation does not establish WebSocket forwarding for this route. GPUStack inference APIs. vLLM transcription and realtime APIs.
• Voice cloning: GPUStack documents Qwen3-TTS reference-audio voice cloning; RubyLLM has no dedicated cloning operation. GPUStack audio and streaming APIs.