openai-compatible

Package

@ai-sdk/openai-compatible

Factories

AIProviders.openAICompatible

Capabilities

• Language
• Completion
• Embedding
• Image

Request transforms with warnings

var settings = ProviderSettings(apiKey: "...")
settings.transformRequestBodyWithWarnings = { body, warnings in
    var body = body
    if body.removeValue(forKey: "seed") != nil {
        warnings.append(.init(type: "unsupported", feature: "seed", message: "The proxy ignores seeds."))
    }
    return body
}

The existing transformRequestBody callback remains available and runs first. The new callback can report changes alongside the transformed request. Normal request/response metadata and warning results include the resulting transformation.

The standard AIProviders.openAICompatible(..., transformRequestBodyWithWarnings:) overload also accepts this two-argument callback. It preserves the existing factory overloads and the optional earlier one-argument transform.

Referenced files and returned image URLs

Chat user content and multipart tool-result content accept provider file references for every media type. References resolve against the configured provider identity and preserve compatible content metadata; a missing provider ID raises AINoSuchProviderReferenceError.

Image generation and edits accept base64, URL, and mixed image responses. Returned URLs are downloaded through the configured transport with the request abort signal and URL/redirect checks. Credentials and custom headers remain on the API origin. base64Images preserves image order, including downloaded bytes, while urls retains response URLs for existing callers.

Generated content order

Unary generation places the separate reasoning block before text, followed by function tool calls. Content-array entries preserve their internal order after the separate reasoning block. This keeps result.content in the same reasoning-before-answer order as streamed output.

Notes

Generic OpenAI-compatible factory mirrors upstream 3.0.78: caller supplies provider ID and base URL, custom headers/query params, versioned user-agent suffix, upstream surface IDs, chat/completion/embedding/image models, providerOptions namespace unwrapping with raw and camelCase keys, deprecated raw-key warnings, structured outputs, stream usage, hosted and data-URL video message input, image token usage, truncated-stream errors, nonempty Gemini thought signatures under custom provider namespaces, preservation of unknown raw usage fields including nested prompt and completion details, response/provider metadata, camelCase provider metadata namespace selection when camelCase providerOptions are used, extensible image provider options, provider-controlled image response formats instead of a forced response_format, non-negative text-token usage when reasoning counts exceed completion counts, and ID/index/latest streamed tool-call correlation. Current parity preserves ordered array-based text/thinking content, ignores unknown future content parts, and maps top-level reasoning disablement to reasoning_effort: none. ProviderV4 type names, ESM-only packaging, Node 22 engines, optional JS headers config, and workflow serialization helpers are JS-only upstream concerns. The 3.0.44 pass keeps streamed reasoning open across empty tool_calls arrays and closes it only when real text or tool output begins. Rich tool-result content is opt-in through ProviderSettings.supportsMultiPartToolContent; the default string representation is retained. Generic image input capabilities remain unknown. The 2026-10-11 pass: Warning-aware request transforms are exposed through settings and the standard factory while preserving the existing callback; embeddings accept shared dimensions with provider overrides. The 2026-10-18 pass: Provider file references map to provider-native file IDs. URL-only and mixed image results are materialized into ordered base64 images with validated redirects, aborts and origin-bound credentials. The 2026-10-23 pass: Generated reasoning precedes text and tool calls. Shared Moonshot generation orders reasoning, tools, then text.

Factory argument requirements are defined by the public Swift factory signatures. Use Public symbols when you need the exact initializer or factory declaration.

Return to the provider matrix.