Add Cloudflare-managed Anthropic Claude Opus 4.8 catalog lane

[stackbilt-admin]

Context

Cloudflare now documents a model page for Claude Opus 4.8 under the AI models catalog:

• Docs: https://developers.cloudflare.com/ai/models/anthropic/claude-opus-4.8/
• Model ID: anthropic/claude-opus-4.8
• Worker binding example: await env.AI.run("anthropic/claude-opus-4.8", { max_tokens, messages })
• REST example: POST /client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/v1/messages with a Cloudflare API token
• Documented context window: 1,000,000 tokens
• Example response includes gatewayMetadata.keySource = "Unified", which indicates Cloudflare-managed/unified provider access rather than direct Anthropic API-key usage.

This is relevant to the StackBilt Cloudflare-credit routing policy because it gives us a Cloudflare-native frontier Claude lane alongside Workers AI open models.

Current repo state

@stackbilt/llm-providers@1.14.2 includes Cloudflare catalog entries for:

• @cf/moonshotai/kimi-k2.6
• @cf/zai-org/glm-4.7-flash
• deepseek/deepseek-v4-pro

It does not appear to include Cloudflare provider support/catalog metadata for:

• anthropic/claude-opus-4.8

The direct Anthropic provider has older direct Anthropic model IDs such as claude-opus-4-6-20250618, but this new route is materially different because billing/auth/transport is Cloudflare-managed.

Desired behavior

Add a Cloudflare provider/catalog entry for the Cloudflare-managed Anthropic route, exposed downstream as a gateway-selectable alias such as:

cloudflare/anthropic/claude-opus-4.8

Provider-native model string should remain:

anthropic/claude-opus-4.8

Suggested catalog metadata

Initial conservative metadata, subject to live smoke and pricing review:

• provider: cloudflare
• model: anthropic/claude-opus-4.8
• lifecycle: active
• use cases: HIGH_PERFORMANCE, LONG_CONTEXT, TOOL_CALLING, possibly BALANCED only if pricing/routing policy allows
• max context: 1_000_000
• streaming: likely true, but verify through Cloudflare endpoint/binding
• tool calling: likely true given Anthropic message semantics, but verify before marking Codex/Claude tool-safe
• vision: unknown from the Cloudflare page; do not mark unless documented or verified
• cost: do not hardcode zero; Cloudflare docs link pricing to dashboard, so either leave unknown/placeholder or add explicit Cloudflare-dashboard-derived rates when available
• description: Cloudflare-managed Anthropic Claude Opus 4.8 frontier model with 1M context

Implementation notes

This may need more than adding a string to the existing Workers AI model list:

• The model ID is not an @cf/... Workers model; it is a provider-managed Cloudflare AI model.
• Cloudflare documents both env.AI.run("anthropic/claude-opus-4.8", ...) and the /ai/v1/messages REST endpoint.
• The current Cloudflare provider should be checked for whether it correctly handles Anthropic-style message responses for this route, including content[], stop_reason, usage, and gatewayMetadata.
• If AI Gateway metadata/cache headers differ for /ai/v1/messages vs /ai/run/@cf/..., keep that difference visible in route-plan/cache metadata.

Acceptance criteria

• CloudflareProvider.getModels() includes anthropic/claude-opus-4.8.
• Public model catalog exposes the Cloudflare-managed Anthropic lane with accurate context/capability metadata.
• Downstream gateway /models exposes cloudflare/anthropic/claude-opus-4.8 after consuming the release.
• Unit tests cover model lookup, capabilities, route planning, and response normalization for an Anthropic-shaped Cloudflare response.
• Live smoke, if account access is available, proves a minimal Cloudflare REST or binding call returns successfully without an Anthropic API key.
• Do not mark this route Codex/Claude tool-loop safe until tool-call behavior is verified through llm-gateway.

Source

Cloudflare docs verified 2026-06-10: https://developers.cloudflare.com/ai/models/anthropic/claude-opus-4.8/

[stackbilt-admin]

Dogfood update 2026-06-10: attempted to use aegis claude through local llm-gateway to work this issue in a non-mutating sandboxed session.

Useful findings for this issue:

• A Cloudflare explicit alias through the Claude Messages path is not currently safe to assume working. Minimal probe with cloudflare/@cf/moonshotai/kimi-k2.6 through /v1/messages repeatedly returned gateway 502 provider_error: Cloudflare AI request failed (200).
• The failure occurred for a tiny prompt, with and without Claude Code tool schemas in nearby retries, so the first suspect is Cloudflare provider response-envelope/stream normalization rather than task complexity.
• A direct/control model through the same aegis claude launcher completed, which narrows the issue to Cloudflare provider/gateway handling.

Implications for anthropic/claude-opus-4.8 support:

• Do not implement this as catalog metadata only. Add response-normalization tests for Cloudflare responses that are Anthropic-shaped or Cloudflare-unified-envelope-shaped.
• Add a fixture for HTTP 200 responses that should be considered success even when the envelope differs from existing Workers AI @cf/... models.
• Keep supportsTools / tool-loop-safe metadata conservative until a live /v1/messages smoke proves Claude Code tool schemas work through this Cloudflare-managed Anthropic route.
• The model should be differentiated from direct Anthropic provider models in metadata because auth, billing, gateway metadata, and response envelope come through Cloudflare.

AEGIS launcher dogfood also found and fixed a stdin issue: local gateway startup could consume piped prompts before Claude Code received them. That is being committed in AEGIS with a regression test, and it improves future printf ... | aegis claude --print dogfood runs.

[stackbilt-admin]

Fix/release update 2026-06-10:

Published provider release:

• @stackbilt/llm-providers@1.14.4
• Release: https://github.com/Stackbilt-dev/llm-providers/releases/tag/v1.14.4
• Commit: 1cc5210

Relevant fixes for this issue:

• Cloudflare reasoning models that return choices[0].message.content: null with reasoning_content now normalize that text instead of surfacing as empty output.
• CloudflareProvider.streamResponse() now normalizes non-streaming chat-completion JSON through the same parser as generateResponse(). This is required for local gateways that ask Cloudflare for JSON and synthesize Claude/Codex client streams.

Why this matters for anthropic/claude-opus-4.8:

• The Cloudflare-managed Anthropic route should not be added as catalog metadata only. The provider must preserve Anthropic/Cloudflare response envelopes through both non-stream and synthesized-stream paths.
• The Kimi dogfood exposed exactly that class of bug: transport worked, but stream normalization dropped valid chat-completion content.

Validation:

• npm run typecheck
• npm test: 444/444
• npm run test:package
• Downstream llm-gateway consumed 1.14.4 and live-smoked Kimi successfully through both /v1/messages and /v1/responses.