cloudflareBindingProvider sends reasoning.effort max on Responses path; Workers AI /run rejects it

[Divkix]

Describe the Bug

After #525, cloudflareBindingProvider correctly uses the OpenAI Responses wire format for AI Gateway openai/… models. That path still forwards catalog thinking levels straight through, including "max".

For cloudflare/openai/gpt-5.6-luna with thinkingLevel: "max", env.AI.run fails immediately:

Model execution failed (User Input Error): Invalid value at reasoning.effort: Invalid option: expected one of "none"|"low"|"medium"|"high"

AI Gateway logs the call as path /run, model openai/gpt-5.6-luna, status 400.

The interesting part is the split inside the same provider file:

• chat-completions binding path already clamps:
  high | xhigh | max -> "high" (mapReasoningEffort)
• Responses binding path does not. applyResponsesReasoning does:

const effort = model.thinkingLevelMap?.[clamped] ?? clamped;
payload.reasoning = { effort, summary: 'auto' };

pi-ai's AI Gateway catalog currently marks Luna as:

thinkingLevelMap: {
  low: "low",
  medium: "medium",
  high: "high",
  xhigh: "xhigh",
  max: "max",
}

So Flue happily emits reasoning.effort: "max", and Workers AI /run rejects it.

Same model + same effort: "max" previously succeeded on the older AI Gateway HTTP Responses path (cloudflare-ai-gateway/gpt-5.6-luna, path responses). This started failing only after moving Support onto the stock binding provider.

This is not a duplicate of #525. #525 was "wrong wire format" (chat vs Responses). This is "Responses path is on, but effort enums are not clamped the way chat already is."

Expected Behavior

For binding-backed OpenAI Responses models:

1. Either clamp unsupported /run effort values the same way chat already does (max/xhigh -> high, or whatever the binding actually accepts), or
2. Fail fast client-side with a clear unsupported-level error before calling env.AI.run.

Apps should not get a hard 400 after admission for a thinking level Flue itself accepts and catalogs as valid.

Steps to Reproduce

1. Worker with ai.binding = "AI" and a named AI Gateway that has OpenAI BYOK.
2. Register stock binding provider:

import { setProvider } from '@flue/runtime';
import { cloudflareBindingProvider } from '@flue/runtime/cloudflare/workers-ai';

setProvider(
  cloudflareBindingProvider({
    binding: env.AI,
    gateway: { id: 'your-gateway-id', skipCache: true, collectLog: true },
  }),
);

3. Agent or stream with:

useModel('cloudflare/openai/gpt-5.6-luna', { thinkingLevel: 'max' });

4. Observe binding /run 400 with the reasoning.effort error above.
5. Same call with thinkingLevel: 'high' succeeds.
6. Optional contrast: older HTTP AI Gateway Responses path accepted effort: "max" for the same model.

Environment

• @flue/runtime 2.0.0 / 2.0.0-nightly.202607240825 (same Responses reasoning code on local main)
• @earendil-works/pi-ai 0.82.1 / 0.83.0
• Model: openai/gpt-5.6-luna via binding + named AI Gateway
• Cloudflare Workers

Workaround

Do not change app config off thinkingLevel: "max". Keep the product pin and patch Flue so Responses binding effort is clamped the same way chat already is (max/xhigh → high) before env.AI.run.

We are shipping that as a temporary pnpm patch on @flue/runtime@2.0.0 and posted the source-form fix in a comment on this issue. When this lands upstream, drop the patch and upgrade Flue; app config stays max.

[Divkix]

App workaround while this is open

We hit this in production after moving Support onto cloudflareBindingProvider with:

• model: cloudflare/openai/gpt-5.6-luna
• thinkingLevel: "max"

AI Gateway /run returned:

Invalid value at reasoning.effort: Invalid option: expected one of "none"|"low"|"medium"|"high"

Same model + effort: "max" had worked earlier on the HTTP AI Gateway Responses path. The binding chat-completions path in this file already maps max/xhigh → high; the Responses path did not.

Proposed fix (source)

Clamp catalog effort through the same binding-safe map chat already uses, before sending reasoning.effort:

function applyResponsesReasoning(
	payload: Record<string, unknown>,
	model: Model<'openai-responses'>,
	level: SimpleStreamOptions['reasoning'] | undefined,
): void {
	if (!model.reasoning) return;
	const clamped = level ? clampThinkingLevel(model, level) : undefined;
	if (clamped && clamped !== 'off') {
-		const effort = model.thinkingLevelMap?.[clamped] ?? clamped;
+		// Binding `/run` currently accepts Responses effort as
+		// none|low|medium|high. Catalog entries may still advertise max/xhigh
+		// (and chat-completions already clamps those via mapReasoningEffort).
+		// Reuse the same map so thinkingLevel "max" does not hard-400.
+		// See https://github.com/withastro/flue/issues/544
+		const catalogEffort = model.thinkingLevelMap?.[clamped] ?? clamped;
+		const effort =
+			mapResponsesBindingEffort(catalogEffort) ??
+			mapResponsesBindingEffort(clamped) ??
+			catalogEffort;
		payload.reasoning = { effort, summary: 'auto' };
		// Encrypted reasoning items make `store: false` multi-turn replay
		// stateless, mirroring pi's openai-responses request shape.
		payload.include = ['reasoning.encrypted_content'];
	} else if (model.thinkingLevelMap?.off !== null) {
		payload.reasoning = { effort: model.thinkingLevelMap?.off ?? 'none' };
	}
}

+/** Binding-safe Responses effort; mirrors chat mapReasoningEffort. */
+function mapResponsesBindingEffort(level: string): WorkersAIReasoningEffort | undefined {
+	switch (level) {
+		case 'minimal':
+		case 'low':
+			return 'low';
+		case 'medium':
+			return 'medium';
+		case 'high':
+		case 'xhigh':
+		case 'max':
+			return 'high';
+		default:
+			return undefined;
+	}
+}

Source patch against current main:

diff --git a/packages/runtime/src/cloudflare/workers-ai-provider.ts b/packages/runtime/src/cloudflare/workers-ai-provider.ts
index 33f7609b..3d2a35be 100644
--- a/packages/runtime/src/cloudflare/workers-ai-provider.ts
+++ b/packages/runtime/src/cloudflare/workers-ai-provider.ts
@@ -841,7 +841,16 @@ function applyResponsesReasoning(
 	if (!model.reasoning) return;
 	const clamped = level ? clampThinkingLevel(model, level) : undefined;
 	if (clamped && clamped !== 'off') {
-		const effort = model.thinkingLevelMap?.[clamped] ?? clamped;
+		// Binding `/run` currently accepts Responses effort as
+		// none|low|medium|high. Catalog entries may still advertise max/xhigh
+		// (and chat-completions already clamps those via mapReasoningEffort).
+		// Reuse the same map so thinkingLevel "max" does not hard-400.
+		// See https://github.com/withastro/flue/issues/544
+		const catalogEffort = model.thinkingLevelMap?.[clamped] ?? clamped;
+		const effort =
+			mapResponsesBindingEffort(catalogEffort) ??
+			mapResponsesBindingEffort(clamped) ??
+			catalogEffort;
 		payload.reasoning = { effort, summary: 'auto' };
 		// Encrypted reasoning items make `store: false` multi-turn replay
 		// stateless, mirroring pi's openai-responses request shape.
@@ -851,6 +860,23 @@ function applyResponsesReasoning(
 	}
 }
 
+/** Binding-safe Responses effort; mirrors chat mapReasoningEffort. */
+function mapResponsesBindingEffort(level: string): WorkersAIReasoningEffort | undefined {
+	switch (level) {
+		case 'minimal':
+		case 'low':
+			return 'low';
+		case 'medium':
+			return 'medium';
+		case 'high':
+		case 'xhigh':
+		case 'max':
+			return 'high';
+		default:
+			return undefined;
+	}
+}
+
 /**
  * Pass-through that records whether the SSE stream reached a terminal
  * `response.*` event and whether it ended cleanly, so the catch handler can

What we are shipping locally

pnpm patch on @flue/runtime@2.0.0 dist (applyResponsesReasoning reuses existing mapReasoningEffort). That keeps app config on thinkingLevel: "max". When this lands upstream we drop the patch and upgrade.

Happy to open a PR if useful.

[FredKSchott]

Confirmed and fixed on main — thanks for the unusually precise report. Rather than a second mapping table, the Responses branch now strips xhigh/max from the hydrated model's thinkingLevelMap before clampThinkingLevel runs, so thinkingLevel: "max" lands on the binding's high ceiling the same way the chat-completions path already does. Observable behavior matches your patch: app config stays on max, no more /run 400. Ships in the next release, at which point you can drop the pnpm patch.

[FredKSchott]

2.0.1 is out with this fix — you can drop the pnpm patch and update normally.