Anthropic API 2026-10-21: temperature dà 400 anche a 1.0

Una richiesta a Claude con la versione API 2026-10-21 restituisce HTTP 400 se specifica temperature, top_p o top_k, anche con il valore predefinito: temperature: 1.0 fallisce con “temperature: Extra inputs are not permitted”. Sono i parametri di campionamento, che regolano la casualità con cui il modello sceglie ogni token successivo. La versione API si imposta nell’header anthropic-version e determina come la Messages API valida la richiesta e risponde; il valore precedente è 2023-06-01. Le versioni principali degli SDK pubblicate da Anthropic il 21 ottobre insieme alla nuova API (Python 2.0.0, TypeScript 1.0.0 e altre cinque) la inviano per impostazione predefinita. Questi SDK non espongono più i parametri di campionamento. Il 400 riguarda quindi il codice che costruisce direttamente il corpo della richiesta: client HTTP e campi aggiunti al body. Abbiamo provato otto tipi di richiesta con entrambe le versioni su Claude Sonnet 4.6 e Claude Sonnet 5.5, confrontato due versioni dell’SDK Python e ripetuto i test tramite Synthorai.

TL;DR

• Con 2026-10-21, temperature, top_p e top_k restituiscono 400 su Claude Sonnet 4.6 e Sonnet 5.5, anche con temperature: 1.0.
• 2026-10-21 rifiuta anche i blocchi document nei messaggi dell’assistente e citations nei blocchi di testo dell’utente.
• L’SDK Python 2.x di Anthropic invia la chiave come Authorization: Bearer; se una richiesta contiene entrambi gli header, l’API usa x-api-key.
• Tramite Synthorai, tutte le 32 richieste hanno restituito 200 con entrambi gli SDK, comprese le 12 che l’API Anthropic rifiuta con 2026-10-21.

Quali richieste restituiscono 400 con la versione API 2026-10-21?

I 400 dipendono da cinque modifiche: i tre parametri di campionamento, un blocco document inserito direttamente in un messaggio dell’assistente e citations in un blocco di testo di un messaggio dell’utente. Le citations sono riferimenti che collegano un blocco di testo a un passaggio di un documento. La tabella copre sei casi che falliscono e due che continuano a funzionare. Abbiamo inviato ogni caso una volta per modello e versione, direttamente all’API Anthropic. 200 indica che la richiesta è stata accettata; 400 che è stata rifiutata con invalid_request_error.

I messaggi di errore con la nuova versione:

Claude Sonnet 5.5 rifiutava già i valori di campionamento non predefiniti con 2023-06-01, ma con un messaggio diverso (“`temperature` is deprecated for this model.”). Accettava invece temperature: 1.0. Con 2026-10-21 il parametro non esiste più, quindi fallisce anche il valore predefinito. Claude Sonnet 4.6 accettava tutti i casi con la vecchia versione. La guida alla migrazione di Anthropic indica che le stesse regole valgono per il conteggio dei token e per ogni richiesta in un Message Batch (la Batch API, che esegue molte richieste in modo asincrono a un prezzo ridotto). Non indica una data di fine supporto per 2023-06-01.

Come si risolve ciascun errore 400?

Rimuovete i tre parametri di campionamento, spostate i documenti nei messaggi dell’utente ed eliminate citations dal testo inviato come utente. Senza parametri di campionamento, la richiesta usa i valori predefiniti, compreso temperature 1.0. Era già così per le richieste 2023-06-01 che non li specificavano. Le citazioni nelle risposte precedenti di Claude e "citations": {"enabled": true} sui documenti restano validi.

Con l’SDK Python, questa richiesta funziona con entrambe le versioni:

import anthropic

client = anthropic.Anthropic()  # 2.x sends anthropic-version: 2026-10-21

message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    # no temperature, top_p or top_k: the parameters no longer exist in 2.x
    messages=[{"role": "user", "content": "Summarize this memo in one sentence."}],
)
print(message.content[0].text)

Se una richiesta richiede un valore di temperature non predefinito su un modello che lo accetta ancora, come Claude Sonnet 4.6, deve continuare a usare la vecchia versione. Con HTTP diretto, basta impostare esplicitamente l’header:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 256, "temperature": 0.2,
       "messages": [{"role": "user", "content": "Pick a number from 1 to 100."}]}'

Che cosa cambia negli SDK Anthropic?

Le versioni principali degli SDK che inviano 2026-10-21 sono Python 2.0.0, TypeScript 1.0.0, Go 2.0.0, Java 3.0.0, C# 13.0.0, PHP 1.0.0 e Ruby 2.0.0. Oltre alla versione API, cambiano il modo in cui viene inviata la chiave e il numero di credenziali che un client può gestire. Passano inoltre dalla licenza MIT alla Apache 2.0. Abbiamo installato le versioni 1.17.0 (l’ultima 1.x) e 2.3.0 dell’SDK Python e configurato entrambe per usare un server echo locale, che registra header e body di ogni richiesta ricevuta:

L’argomento temperature è stato rimosso dai metodi per i messaggi dell’SDK Python nella versione 1.0.0. Chi usa Python incontra quindi il 400 lato server solo tramite extra_body (l’opzione dell’SDK che aggiunge campi direttamente al corpo della richiesta), oppure con client HTTP e librerie che costruiscono il body autonomamente. L’header Bearer funziona con entrambe le versioni API: una richiesta con il solo Authorization: Bearer <key> ha restituito 200 anche con 2023-06-01. Il cambio di autenticazione e quello di versione possono quindi essere distribuiti separatamente.

Quale chiave viene usata quando si inviano entrambi gli header?

L’API Anthropic usa x-api-key quando una richiesta contiene entrambi gli header. Abbiamo inviato cinque combinazioni di header con entrambe le versioni:

Un proxy o gateway davanti a Claude può attribuire la richiesta a una chiave diversa da quella usata dall’API. Con l’SDK 2.x, il codice che aggiunge una seconda chiave tramite extra_headers={"X-Api-Key": other_key} invia ora due chiavi: quella del client in Authorization e l’altra in x-api-key. L’API Anthropic autentica la richiesta con other_key, mentre un proxy che legge solo Authorization la attribuisce alla chiave del client. Quote per chiave, log e limiti di spesa possono così finire sulla chiave sbagliata. La soluzione lato client indicata dalla guida è inviare la seconda chiave come Authorization: Bearer <other_key>. Lato proxy, occorre leggere entrambi gli header e applicare la precedenza dell’API (x-api-key per primo), oppure rifiutare le richieste i cui due header contengono chiavi diverse.

Che cosa si perde eliminando temperature?

Eliminare temperature incide meno di quanto potrebbe aspettarsi un team abituato a usare temperature: 0. La guida alla migrazione indica che Claude 4.7 e i modelli successivi accettano già solo i valori predefiniti, quindi per loro non cambia nulla. Su un modello che accetta ancora altri valori, come Claude Sonnet 4.6, una richiesta che abbassava temperature per rendere l’output più stabile perde quell’effetto. Nessun’altra impostazione lo sostituisce. Abbiamo misurato quanto contasse: 20 richieste per impostazione a Sonnet 4.6 con 2023-06-01, ciascuna con un ID di richiesta casuale aggiunto in fondo, così da non avere due richieste identiche.

Su queste risposte brevi, l’output di Sonnet 4.6 con la temperatura predefinita era concentrato su poche risposte quanto quello a 0. Rimuovere temperature: 0 ha quindi cambiato poco. Inoltre, temperature: 0 non garantiva il determinismo: ha restituito due numeri diversi in 20 tentativi. Il testo del prompt ha influito sull’output più dell’impostazione: senza l’ID di richiesta aggiunto in fondo, la risposta più frequente era 42 (17 su 20 con temperature: 0); con l’ID era 47. Se servono output ripetibili, confrontate le risposte nel codice o memorizzatele in cache: il parametro di campionamento non lo garantiva neppure prima.

Come gestisce Synthorai la versione API 2026-10-21?

Synthorai accetta richieste con entrambe le versioni API e da entrambi gli SDK. Passare all’SDK 2.x o inviare anthropic-version: 2026-10-21 non interrompe quindi una richiesta che prima funzionava. Abbiamo ripetuto tramite Synthorai la matrice di 16 casi per i due modelli, con entrambi i valori di anthropic-version: tutte le 32 richieste hanno restituito 200, comprese le 12 che l’API Anthropic rifiuta con 2026-10-21. Gli SDK Python 1.17.0 (che invia x-api-key) e 2.3.0 (che invia Authorization: Bearer) hanno funzionato entrambi con base_url="https://synthorai.io" e la stessa chiave, anche inviando temperature tramite extra_body.

Synthorai si comporta così per quattro motivi:

• Un modello, più piattaforme. Un modello Claude può essere servito dall’API Anthropic, da Amazon Bedrock o da Google Cloud Vertex AI. Ogni piattaforma richiede una propria stringa di versione. Synthorai invia a ciascuna la versione attesa, quindi l’header anthropic-version del client non determina come viene validata la richiesta.
• Client diversi durante la migrazione. I team aggiornano un servizio alla volta. Per settimane, lo stesso account invia quindi 2023-06-01 dall’SDK 1.x e 2026-10-21 dall’SDK 2.x. Accettare entrambi permette di migrare ogni servizio con i propri tempi, e la stessa chiave funziona con l’header di autenticazione di entrambi gli SDK.
• Cambio di modello senza cambiare codice. Il codice che imposta temperature: 0.2 per Claude Sonnet 4.6 continua a funzionare quando il nome del modello cambia in Claude Sonnet 5.5, che non accetta quel parametro, anziché fallire al passaggio.
• Nessuna richiesta fallita per un valore predefinito. temperature: 1.0 è il valore che il modello usa comunque. Rifiutarlo farebbe fallire la richiesta senza cambiare l’output.

Il compromesso è che un 200 non significa che tutti i parametri abbiano avuto effetto. Sonnet 5.5 accetta solo i valori di campionamento predefiniti: una richiesta con temperature: 0.2 inviata tramite Synthorai riesce, ma non può ridurne la casualità. Se il vostro output dipende da un valore di campionamento, confrontate i risultati con e senza quel valore sui vostri prompt. La misurazione precedente ha rilevato un effetto ridotto sulle risposte brevi.

Che cosa controllare prima dell’aggiornamento?

Domande frequenti

Perché la mia richiesta a Claude fallisce con “temperature: Extra inputs are not permitted”? La richiesta è stata inviata con anthropic-version: 2026-10-21, che non prevede più il parametro temperature. Qualsiasi valore restituisce quindi 400, compreso 1.0. Le nuove versioni principali degli SDK inviano questa versione per impostazione predefinita. Rimuovete il parametro, oppure fissate 2023-06-01 per le richieste che richiedono un valore non predefinito su un modello che lo accetta ancora.

anthropic-version 2023-06-01 verrà ritirata? Anthropic non ha annunciato una data di fine supporto per 2023-06-01: né la guida alla migrazione né le note di rilascio dell’API del 21 ottobre ne indicano una. Le richieste che impostano esplicitamente l’header mantengono il comportamento precedente. Una singola richiesta può quindi continuare a usare temperature su Claude Sonnet 4.6.

L’API Anthropic accetta ancora l’header x-api-key? L’API Anthropic accetta sia x-api-key sia Authorization: Bearer con entrambe le versioni; sono cambiati solo gli header inviati dagli SDK. Quando sono presenti entrambi, l’API usa x-api-key.

Altri articoli

• Costo di Claude Sonnet 5.5: quanto costa il modello rispetto a Sonnet 5
• Controlli del ragionamento degli LLM: le impostazioni di ragionamento accettate dai modelli Claude più recenti
• Violazione di OpenCode: proteggere le chiavi API: limitare ciò che può fare una chiave compromessa
• Limiti di frequenza delle API LLM: come vengono conteggiati i limiti per chiave

← Torna al blog