LongCat 2.0 / AtlasCloud sampling compatibility

Root cause and controlled reproduction

An official-API report described repeated OpenRouter HTTP 400 / AtlasCloud bad request failures on both SFW and NSFW cards. The relevant shared sampling settings included temperature 1.1 and Top-K 200. The generic controls permit these values for other models, but the current LongCat 2.0 endpoint does not.

Live diagnostic requests used only short synthetic instructions, not private chat text. OpenRouter's endpoint catalog reported AtlasCloud as the sole currently available provider for meituan/longcat-2.0 and advertised both parameters, without their accepted numeric ranges.

Controlled variation	Result
Original sampling profile (temperature 1.1, Top-K 200)	HTTP 400 / AtlasCloud bad request
Remove cache markers, remove reasoning, or simplify to system/user	Still HTTP 400
Remove all optional sampling settings	HTTP 200 with reply
Add only temperature 1.1	HTTP 400
Add only Top-K 200	HTTP 400
Add only Top-P 0.95, Min-P 0.16, frequency penalty 0.55, or presence penalty 0.35 (separate requests)	HTTP 200 for each
Full profile with temperature 1.0 and Top-K 100	HTTP 200 with reply
Temperature 1.001, Top-K 1	HTTP 400
Temperature 1.0, Top-K 101	HTTP 400
Temperature 0, Top-K 100	HTTP 200 with reply

This isolates two independent parameter-range rejections. The failure reproduced with a short benign prompt, so neither long context nor card content is necessary to trigger it.

Fix and scope

The existing sampling adaptation at the provider boundary now caps temperature at 1.0 for the exact meituan/longcat-2.0 model. Both OpenRouter request builders cap its enabled Top-K at 100. Values already inside the range, zero/unset Top-K, other sampling settings, saved user preferences, and other model IDs retain their behavior. Do not broaden this rule to other LongCat models or custom endpoints without verifying their limits.

Verification

• Both provider-boundary regression tests failed before the patch and passed after it; all 216 LLM tests passed.
• Workspace build and typecheck passed. The full server suite passed 1,605 tests, with the same seven previously reproduced baseline failures and six skipped tests; there were no new failure signatures. The final server build and 13 focused sampling/provider tests also passed after tightening fractional Top-K handling.
• Live tests through the patched OpenRouterProvider covered streaming and nonstreaming requests with the original shared parameters, three leading system messages, a trailing system instruction, and a cache breakpoint. Both sent temperature 1.0 / Top-K 100 and returned OK from AtlasCloud in one request.
• Those live tests retained high reasoning and the original 12,000 visible-token setting (44,768 effective max tokens). Both completed normally, ruling out those settings as the cause of this reproduced failure.
• No database migration, user-setting mutation, or UI change is required.

pnpm --filter @yumina/server exec tsx --test --test-force-exit src/lib/llm/*.test.ts
pnpm typecheck
pnpm build