[Workers AI] Update model reasoning efforts

[KastanDay]

Update model docs to use the newly exposed reasoning_effort value from our /ai/models/search API.

The Model Info table now shows the supported reasoning efforts, sometimes including none (aka the standard for reasoning-disabled), instead of only "yes/no".

"Yes/No" is still used for models without a reasoning_effort property, and for models whose reasoning can be turned on or off but has no effort levels (for example Gemma 4 and GLM-4.7-Flash).

Models whose reasoning is mandatory w/ no effort levels (Kimi K2.7 Code) show "Always on".

It also appears correctly in the "API Schemas"

• Related SDK generator work: cloudflare/ai/sdk!1778.
• Related binding types: workerd #7437.

CSS styling

Before: 20 of 65 "Model Info" tables used "striped table rows" styling, while 45 of 65 model tables were "plain" without striping.
The striping makes the code-styled reasoning effort low-contrast and hard to read.
After: Model Info now explicitly opts out of striping; ordinary long documentation tables retain striping.

Example of the "striped table rows"

Validation:

• Regenerated the changed model schemas by running the SDK branch's GET /ai/models/schema handler against a fresh production ConfigAPI dump. Only reasoning models were updated; unrelated schema drift was left alone.
• Generated the public OpenAPI schema with apps/rest-api/scripts/build-openapi-schema.ts from the related SDK branch against a fresh production ConfigAPI catalogue.

Documentation checklist

• The change adheres to the documentation style guide.

[cloudflare-docs-bot]

AI Review

✅ Reviewed 22ff226 · 0 findings · incremental

Not reviewed (1)

• src/content/workers-ai-models/nemotron-3-120b-a12b.json — patch omitted by GitHub (file too large)

Commands

• /review Run a review now.
• /full-review Review the entire PR diff.
• /disable-auto-review Stop automatic reviews.
• /rebase Rebase against production.

[KastanDay]

Review

⚠️ 1 warning, 💡 2 suggestions found in commit 1ee7933.

👉 Fix in your agent 👈

Fix the following review findings in PR #33541 (https://github.com/cloudflare/cloudflare-docs/pull/33541).

Before making changes, review each finding and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g. the fix requires disproportionate effort for minimal benefit,
  or the finding is factually incorrect), explain why
- If you need clarification before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

After triaging, follow this order:
1. Post a comment on this PR for any findings you are skipping, with the finding ID and your reasoning.
2. Then commit the fixes for the legitimate findings.

The comment must come before the commit — the bot reads PR comments when a new
push triggers a review, so skip comments posted after the push will be missed.

---

## Code Review

### Warnings (1)

#### CR-f87511b277c8 · Inverted reasoning-effort alias mapping
- **File:** `src/content/workers-ai-models/glm-5.3-flash.json` line 31
- **Issue:** The new `normalizes_to` maps the `minimal` alias to `max` (the highest supported effort) even though this model supports `low` as its floor. The sibling model in the same PR (`glm-5.2.json`) maps `minimal` to `none` (the lowest level), and `glm-5.3.json` (same supported efforts `[max, high, low]`, mandatory reasoning) does not define a `minimal` alias at all. As written, a user passing `reasoning_effort: "minimal"` — which the schema description at lines 335/1586/2407/3658 advertises as a compatibility alias — silently gets maximum reasoning effort instead of the closest (lowest) level, inverting their intent and yielding the most expensive/slowest output.
- **Fix:** Map `minimal` to `low` (the closest supported level), consistent with the `glm-5.2.json` convention, or confirm with the model team that all unsupported aliases intentionally fall back to the default (`max`). If intentional, consider documenting the fallback-to-max behavior explicitly; if not, update the alias list in the `normalizes_to` block and the matching schema descriptions.

### Suggestions (2)

#### CR-7f36cb801743 · Unvalidated sort fallback
- **File:** `src/util/models/model-format.ts` line 62
- **Issue:** The sort comparator maps any effort value not present in the hard-coded `reasoningEffortOrder` list to `Number.MAX_SAFE_INTEGER`, so an unknown or newly introduced effort level (e.g. "ultra") silently renders at the end of the list in data order rather than in its natural position, with no indication that the order list is out of sync with the upstream data.
- **Fix:** Consider validating `supported_efforts` values against `reasoningEffortOrder` (e.g. log or surface unknown values) or documenting that the order list must be kept in sync with upstream effort levels, so new levels don't silently mis-sort.

#### CR-e42218523884 · Metadata ignored in primary branch
- **File:** `src/util/models/model-format.ts` line 67
- **Issue:** When `supported_efforts` is non-empty the function returns the effort list and never consults `metadata.mandatory`, `metadata.default_enabled`, or the `reasoning` argument. A model that supports efforts but is off by default (`default_enabled: false`) would render as if reasoning is on with a "(default)" effort, and a `mandatory: true` model would show a selectable list instead of "Always on" — the off-by-default/mandatory signal is dropped for the most common (list) case.
- **Fix:** If the data can combine `supported_efforts` with `default_enabled: false` or `mandatory: true`, decide and document the precedence, or surface the off/mandatory state in the returned list so the UI doesn't imply reasoning is enabled/optional when it isn't.

Code Review

This code review is in beta and may not always be helpful — use your judgment.

Warnings (1)

File Issue
workers-ai-models/glm-5.3-flash.json line 31 Inverted reasoning-effort alias mapping — The new normalizes_to maps the minimal alias to max (the highest supported effort) even though this model supports low as its floor. The sibling model in the same PR (glm-5.2.json) maps minimal to none (the lowest level), and glm-5.3.json (same supported efforts [max, high, low], mandatory reasoning) does not define a minimal alias at all. As written, a user passing reasoning_effort: "minimal" — which the schema description at lines 335/1586/2407/3658 advertises as a compatibility alias — silently gets maximum reasoning effort instead of the closest (lowest) level, inverting their intent and yielding the most expensive/slowest output. Fix: Map minimal to low (the closest supported level), consistent with the glm-5.2.json convention, or confirm with the model team that all unsupported aliases intentionally fall back to the default (max). If intentional, consider documenting the fallback-to-max behavior explicitly; if not, update the alias list in the normalizes_to block and the matching schema descriptions.
Suggestions (2)

File Issue
src/util/models/model-format.ts line 62 Unvalidated sort fallback — The sort comparator maps any effort value not present in the hard-coded reasoningEffortOrder list to Number.MAX_SAFE_INTEGER, so an unknown or newly introduced effort level (e.g. "ultra") silently renders at the end of the list in data order rather than in its natural position, with no indication that the order list is out of sync with the upstream data. Fix: Consider validating supported_efforts values against reasoningEffortOrder (e.g. log or surface unknown values) or documenting that the order list must be kept in sync with upstream effort levels, so new levels don't silently mis-sort.
src/util/models/model-format.ts line 67 Metadata ignored in primary branch — When supported_efforts is non-empty the function returns the effort list and never consults metadata.mandatory, metadata.default_enabled, or the reasoning argument. A model that supports efforts but is off by default (default_enabled: false) would render as if reasoning is on with a "(default)" effort, and a mandatory: true model would show a selectable list instead of "Always on" — the off-by-default/mandatory signal is dropped for the most common (list) case. Fix: If the data can combine supported_efforts with default_enabled: false or mandatory: true, decide and document the precedence, or surface the off/mandatory state in the returned list so the UI doesn't imply reasoning is enabled/optional when it isn't.

Conventions

No convention issues found.

Style Guide Review

No style-guide issues found.

Commands

All the review comments are good as is, should not change.

1. For GLM-5.3-flash, this is intentional. All unsupported aliases intentionally fall back to the default (max). That matches the upstream provider, what z.ai does.
2. The sort order of reasoning efforts is not that important. Unknown efforts go at end of list.
3. This is good as is. The worst case is "reasoning is default off (rare), but we list (default) next to a reasoning effort. But that's still valid, because when reasoning is on, that's the default effort." not worth the confusing docs for a non-existent edge case of default off reasoning. we always default on reasoning.