workers-ai-provider does not work with openai/gpt-5.6 class models

[longzheng]

I was trying to use workers-ai-provider with openai/gpt-5.6-luna but I kept getting an error in AI Gateway

{ "error": "Model execution failed (User Input Error): Invalid value at input: Invalid input", "state": "Failed" }

I used a pretty basic example from https://github.com/cloudflare/ai/tree/main/packages/workers-ai-provider#third-party-models-via-ai-gateway

import { createWorkersAI } from "workers-ai-provider";
import { openai } from "workers-ai-provider/openai";
import { streamText } from "ai";

const workersai = createWorkersAI({
	binding: env.AI,
	providers: [openai], // opt-in; enables third-party routing
});

const result = streamText({
	model: workersai("openai/gpt-5.6-luna"), // routed through AI Gateway
	prompt: "Hello",
});

After some investigation by Opus, turns out it's because the gpt-5.6 class of models only support the OpenAI Response API wire format, but the workers-ai-provider/openai provider only does the OpenAI Completions API wire format.

The workaround was to use a custom provider

import { createOpenAI } from "@ai-sdk/openai";

/**
 * `gpt-5.6-luna` only accepts the Responses API wire format, while the stock
 * `workers-ai-provider/openai` plugin builds models with `.chat()`.
 */
const openaiResponses: ProviderPlugin = {
  wireFormat: "openai",
  create: ({ modelId, fetch, baseURL }) =>
    createOpenAI({ apiKey: "unused", fetch, ...(baseURL ? { baseURL } : {}) }).responses(modelId),
};

const workersai = createWorkersAI({
	binding: env.AI,
	providers: [openaiResponses], // custom provider
});

[tajagn01]

I reproduced this with openai/gpt-5.6-luna.The failure appears to come from workers-ai-provider/openai constructing the model with createOpenAI(...).chat(), while the affected GPT-5.6 models require the Responses API.

I also noticed the existing .chat() behavior is intentional because the Gateway run catalog currently expects the Chat Completions wire format for the general OpenAI provider.

I'd like to work on a backwards-compatible fix rather than switching the OpenAI plugin globally to .responses(). My current thinking is to make the transport/model selection capability-aware so Responses-only models can use .responses() without changing existing OpenAI-compatible routing.

Is that direction aligned with how you'd like this handled?