add-gateway-model: check the provider's docs for rejected parameters

[adambalogh]

Why

GPT-6 Astra was added with correct pricing, correct aliases, correct responses_api_for_tools, and a green unit suite — and 400ed on every request, because it rejects temperature (fix: #154). The skill already listed supports_temperature=False among the optional fields, but nothing in the process said to go find out whether it was needed. Pricing gets looked up as a matter of course; the supported-parameter list is on the same docs and nobody reads it.

What changed

.claude/skills/add-gateway-model/SKILL.md — new section "Parameter restrictions are the thing that bites", plus a step 8: read the provider's API docs for the model's supported parameters and set the matching flags. Three traps, written down:

• Restrictions don't travel down a family. Copying the closest sibling's ModelConfig is right for pricing shape, request shaping and responses_api_for_tools, and wrong for this.
• langchain-openai strips temperature for names starting with gpt-5, and only those — so the whole gpt-5.6 family worked without the flag and the first gpt-6-* model did not. "The sibling works" proves nothing; the sibling may be surviving on a provider-package special case keyed to its name.
• Reasoning-first flagships are where the field keeps getting dropped (Opus 4.7+, o-series, gpt-5, GPT-6). Assume rejected until the docs say otherwise.

Where to look, for the specific model: its own reference page, the provider's reasoning-model guide (which lists the unsupported sampling params once for the whole family rather than per model), and the release changelog — where removals land first and often only, in the weeks after a launch. Cite what you found in the PR body next to the pricing citation.

And the default when the docs are still a stub: register supports_temperature=False. Omitting a field the model would have accepted costs a sampling knob no client varies (every client pins temperature: 0.0); sending one it rejects costs 100% of its requests.

The live suite (test_provider_usage_integration.py, workflow_dispatch only) stays mentioned as the fallback for contradictory docs, explicitly not part of a routine model addition.

test_provider_usage_integration.py — NEW_CHAT_MODELS now points at the actual newest models per provider (gpt-6-astra, claude-fable-5-1); it still listed gpt-5.6-luna and Sonnet 5, so a dispatch was exercising last quarter's flagships.

.github/workflows/test.yml — the live-provider-usage job exported NOUS_API_KEY, but the suite reads OPENROUTER_API_KEY (the provider was renamed), so the job failed in its own key-check step before running anything. It now accepts either secret name: ${{ secrets.OPENROUTER_API_KEY || secrets.NOUS_API_KEY }}. Worth a maintainer's eye — I can't see which secret the repo actually holds; if it's neither, the check step now says so clearly instead of failing later.

Merge order

Land after #154. The skill's closing line ("llm_backend passes None for a flagged field, which every langchain-<provider> package turns into omit-the-key") describes the behavior that PR introduces for non-Anthropic providers.

Verification

make lint clean; unit suite green (403 passed, 6 skipped, 117 subtests); workflow YAML parses. No live provider calls were made.

🤖 Generated with Claude Code

https://claude.ai/code/session_019GiCnGpGxLEusqVUS6zUHw