fix(workers-ai-provider): route gpt-5.6 through Responses API

[mikemikimike]

Related issue

Fixes #643

Background

workers-ai-provider/openai always built OpenAI-compatible models with Chat Completions. OpenAI gpt-5.6 class models only accept the Responses API, so requests through the provider failed with an invalid-input error.

Changes

• Route gpt-5.6 class model IDs through @ai-sdk/openai's Responses API model.
• Keep existing Chat Completions routing for other OpenAI-compatible models.
• Add regression coverage for model boundaries and Gateway baseURL routing.
• Add a patch changeset for workers-ai-provider.

Compatibility

Only gpt-5.6 class IDs change endpoint selection. gpt-5.5 and other ordinary OpenAI-compatible IDs retain Chat Completions behavior. The selection is synchronous and stateless, so concurrent model construction cannot observe a partially updated route.

Validation

• pnpm --filter workers-ai-provider test -- --run — 23 files, 457 tests passed.
• pnpm --filter workers-ai-provider type-check — passed.
• pnpm exec oxfmt --check packages/workers-ai-provider/src/openai.ts packages/workers-ai-provider/test/openai.test.ts — passed.
• git diff --check — passed.

The package build command was not run because the repository's existing rolldown-plugin-dts step fails on Billing being exported but not defined in the current baseline. The repository postinstall also uses Unix rm, so dependencies were installed with --ignore-scripts on Windows.

The regression suite verifies endpoint selection and the configured Gateway base URL, but does not make a live Cloudflare AI Gateway request or validate a live gpt-5.6 response stream. Those require external credentials/runtime and are left to CI/maintainer validation.

Docs were not updated because this is an internal provider routing correction with no new public API or configuration.

[changeset-bot]

🦋 Changeset detected

Latest commit: 570dc20

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
workers-ai-provider	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[tajagn01]

I reproduced #643 as well, and this fixes the immediate routing issue. One architectural question: should the Responses-vs-Chat capability be represented in the provider/model routing metadata rather than inferred from the model ID in openai.ts?

The provider registry already carries wire-format/routing metadata, so I'm wondering whether a capability-based approach would make this easier to extend if more OpenAI models become Responses-only. If the model-family check is intentional here, I'm interested in the reasoning behind keeping it at the provider-plugin level.

[mikemikimike]

Thanks for raising this. I agree that a capability-based routing field would be the more extensible design if we expect multiple Responses-only model families. For this fix, I kept the model-family check in the OpenAI provider intentionally to minimize the scope and avoid changing the provider registry contract for a single known exception. The existing registry metadata describes the provider/wire format, while this distinction is currently specific to OpenAI model compatibility. If additional Responses-only models are introduced, I’d be happy to move this into explicit routing capabilities with coverage for the precedence and fallback behavior.