You have an editing integration that has worked for months on Claude Sonnet 4.6. It sets a temperature, forces a function call through tool_choice, and parses the reply expecting the tool output to be there. Today a teammate suggests moving to Sonnet 5.5, and the pitch sounds easy: same /v1/chat/completions request shape, just swap the model ID.
SpicyAPI's Claude Sonnet 4.5, 5 and 5.5 API version guide is written for exactly that moment. It starts from a point most migration posts skip: an editing integration carries more than a model name. It may depend on a sampling setting, a forced function call or a reply parser. All four Sonnet versions share one request shape on SpicyAPI, and they are still four different contracts. The guide's blunt version is that changing the model ID alone breaks a request.
Here is what changes, according to the guide. Sonnet 5 and 5.5 reject temperature, top_p and top_k. Sonnet 5.5 also rejects a forced tool_choice. And only 5.5 writes past 64,000 output tokens, with a ceiling of 128,000. If your integration sets any of those fields, the swap fails.
The failure is at least cheap. Unsupported fields return a 400 unsupported_parameter error before anything is charged. So the guide's advice is to keep a per-model allowlist of parameters instead of one shared parameter object. It adds a second warning that matters for your parser: 5.5 can skip the function, so you should validate the reply rather than assume the tool call came back.
Then there is the money. The prices in the guide are SpicyAPI's hosted rates in USD per million tokens. Sonnet 5 is listed at $1.90 in and $9.50 out, Sonnet 5.5 at $2 and $10, and Sonnet 4.6 at $3 and $15. The cost example leans on a roughly 30% tokenizer increase, which the guide attributes to Anthropic's migration guide, and the resulting 9% saving, in the post's own words, is not fixed for every document. Read that as an estimate to test on your own text, not a promise.
You should also weigh the source. The guide discloses that SpicyAPI sells access to every model it compares. That is a vendor telling you which of its products to use. What survives the sales context is the engineering: the parameter differences, the pre-charge 400, the allowlist, the reply validation.
Now the turn. APIs.io looked at SpicyAPI's own record and found the measurement mostly agrees with the post. SpicyAPI has 5 API pages in the catalog, and the guide lives on two of them: the OpenAI Compatible API, which is the chat completions endpoint every example calls, and the Models API, the model contract an agent reads first. The post even exposes that contract through the CLI and a spicyapi_model_get MCP tool. SpicyAPI scores 72.0 on the Kin Score, in the exemplar band, with access clarity at 92.1 and operational transparency at 86.8. Agent Readiness is 37.3, with idempotency and error semantics lit, and the sample code does send an Idempotency-Key and parse the documented error.
The weak spot is contract governance, at 22.0. OpenAPI examples and agent skills are unlit, even though the post tells readers to install an official SpicyAPI Skill. The agentic access profile counts 24 operations, 14 of them acting.
That leads to the catalog's closing point, and it affects you directly. The per-version table in this blog post is the most precise contract SpicyAPI publishes for Sonnet. It belongs in the Models API response, where an agent would find it without reading a 13-minute article. Today the clearest statement of what each version rejects sits in prose, not in the machine-readable contract your tooling reads.
So here is what you take back to your teammate. Do not swap the string. Build the per-model allowlist, drop the sampling fields and the forced tool_choice for 5.5, validate that the function call actually came back, and test the savings on your own documents. Treat the guide as useful engineering from a seller, and expect the contract itself to catch up with it.
Read the original: https://apis.io/2026/11/04/spicyapi-sonnet-guide-shows-four-contracts-behind-one-endpoint/