Integrate SCX.ai as a provider for GLM-5.2 and Qwen3.8 Max

[bhuvan2134686]

Summary

Adds SCX.ai as an inference provider on the AI Gateway, along with the two models it serves that aren't in the registry yet: GLM-5.2 and Qwen3.8 Max. The registry currently tops out at GLM-4.7 and has no Qwen Max tier, so this makes the gateway the first place either model is routable.

SCX.ai runs OpenAI-compatible inference on renewable-powered infrastructure in Australia. We're the provider — happy to change anything you'd like about the entries.

Endpoints added (USD per 1M tokens)

Model key	Provider model id	Input	Cached input	Output	Context	Max completion
glm-5.2:scx-ai	GLM-5.2	$0.66	$0.165	$2.3106	1M	131,072
qwen3.8-max:scx-ai	Qwen3.8-Max	$1.815	$0.21	$5.4461	1M	131,072

Both are ptbEnabled: true. Glad to coordinate on a managed key so credits routing works — let us know where to send it, and we can flip these to false in the meantime if you'd rather land the BYOK path first.

Verified live against api.scx.ai

Checked before writing the entries, rather than transcribing a docs page:

• GET /v1/models — canonical ids are GLM-5.2 and Qwen3.8-Max
• Both reject max_tokens: 200000 with Range of max_tokens should be [1, 131072], hence maxCompletionTokens: 131_072
• Errors come back as {"error":{"message":…}}, which BaseProvider.buildErrorMessage already parses — no override needed
• Usage is standard OpenAI shape including prompt_tokens_details.cached_tokens, so OpenAIUsageProcessor is correct

One thing to flag

I added scx-ai to ResponsesAPIEnabledProviders under the "chat completions only" group, since we're a plain OpenAI chat-completions endpoint and BaseProvider handles the Responses → Chat Completions mapping. Happy to drop that one line if you'd rather gate it until you've exercised it yourselves.

Component/Service

What part of Helicone does this affect?

• Web (Frontend)
• Jawn (Backend)
• Worker (Proxy)
• Bifrost (Marketing)
• AI Gateway
• Packages
• Infrastructure/Docker
• Documentation

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Performance improvement
• Refactoring

Testing

• Added/updated unit tests
• Added/updated integration tests
• Tested locally
• Verified in staging environment
• E2E tests pass (if applicable)

Runs clean locally:

• worker/test/ai-gateway/registry-zai.spec.ts — 41 passed (11 new SCX cases)
• worker/test/ai-gateway/registry-alibaba.spec.ts — 244 passed (7 new SCX cases)
• packages suite — 578 passed
• Registry snapshots regenerated with npx jest --updateSnapshot __tests__/cost/registrySnapshots.test.ts
• e2e/tests/nightly/gateway.test.ts — added the scx-ai entry its meta-test requires (the live call there needs a Helicone-managed SCX key)

Technical Considerations

• Database migrations included (if needed)
• API changes documented
• Breaking changes noted
• Performance impact considered

Follows the structure of the Canopy Wave integration (#5292): provider class, providers/index.ts, priorities.ts, provider-helpers.ts, providers/mappings.ts, getUsageProcessor.ts, web/data/providers.ts plus logo, author endpoints, and the worker/test/setup.ts mocks.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[vercel]

@bhuvan2134686 is attempting to deploy a commit to the Helicone Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[bhuvan2134686]

Went back through the other providers to make sure this entry follows the same conventions, and found one thing I had missed — pushed as ec7caa6.

e2e/tests/nightly/gateway.test.ts has a meta-test asserting every key in providers has an entry in BASIC_PROVIDER_TESTS. Added 'scx': { model: 'glm-5.2/scx' }. The live call in that suite will need a Helicone-managed SCX key to pass, so it may be worth landing that entry alongside the key rather than before it — happy to split it out if you prefer.

While checking: canopywave is currently missing from that same map, so the meta-test looks like it fails on main today. Left alone here since it is outside this PR, but flagging it.

Everything else lines up with existing providers:

• rateLimits omitted (66 of 311 endpoint entries set it), quantization set only where known — fp8 on GLM-5.2, omitted on Qwen3.8 Max
• ptbEnabled: true matching 303 of 311 entries
• provider class exposes pricingPages / modelPages like every other provider, no buildErrorMessage override since the base implementation already parses our error shape
• web/components/templates/requests/colors.ts left alone — both maps there are Partial, and the recent providers (canopywave, baseten, cerebras) are not in them either
• generated artifacts that carry the ProviderName enum (web/lib/clients/jawnTypes/*, bifrost/lib/clients/jawnTypes/*, docs/swagger.json, valhalla/jawn/src/tsoa-build/*, helicone-mcp/src/types/public.ts) are untouched, same as the Canopy Wave PR — they will need a codegen run on your side to pick up SCX

[bhuvan2134686]

Renamed the provider id from scx to scx-ai in fa3b263 so it matches how we are named everywhere else — the display name was already SCX.ai. Model keys are now glm-5.2/scx-ai and qwen3.8-max/scx-ai; PR description updated to match.

The rename covers the provider map, priorities, provider-helpers, getUsageProcessor, web/data/providers.ts, both endpoint files, the worker mocks, the gateway specs and the nightly map, plus renames of providers/scx.ts → providers/scx-ai.ts and the logo asset. The uppercase ProviderName stays SCX, following xai → X and google-ai-studio → GOOGLE.

Re-ran after the rename: 285 gateway tests, 578 packages tests, snapshots regenerated, typecheck clean.