Monitoraggio deprecazioni e migrazioni
I modelli vengono ritirati, i parametri vengono rinominati, i comportamenti cambiano. Questa pagina tiene traccia delle modifiche incompatibili in modo che gli aggiornamenti non ti colgano di sorpresa. Se costruisci sull'API, dalle un'occhiata periodicamente.
Perché è importante
Un ID di modello fissato verrà prima o poi deprecato e poi rimosso. Il codice che lo scrive in modo fisso si rompe. Un po' di igiene previene sorprese alle 2 di notte.
Regole di sopravvivenza
- Leggi gli ID dei modelli dalla configurazione, non disseminare valori letterali in tutta la base di codice — così migrare è una modifica di una sola riga.
- Tieni d'occhio gli annunci per le date di deprecazione e le sostituzioni consigliate.
- Riesegui le tue eval quando cambi modello — il comportamento può variare anche su un modello "più nuovo e migliore".
- Testa prima della scadenza, non dopo la rimozione.
Tipi comuni di modifica
| Modifica | Esempio | Cosa fare |
|---|---|---|
| Modello ritirato | Un ID di modello più vecchio smette di funzionare | Passa al successore consigliato; rivaluta |
| Parametro sostituito | Una manopola di reasoning/budget rimpiazzata da effort | Aggiorna le chiamate; vedi Thinking ed Effort |
| Cambio di default | Un nuovo modello/comportamento predefinito | Fissa intenzionalmente; verifica che i tuoi prompt funzionino ancora |
| Aggiornamento endpoint/SDK | Nuova versione major dell'SDK | Leggi la guida alla migrazione; aggiorna con cautela |
Monitoraggio attuale
Voce iniziale — sostituiscila con avvisi di deprecazione reali e referenziati man mano che vengono annunciati.
- Verifica i tuoi ID di modello rispetto alla tabella Modelli e prezzi attuali; se sei su un ID più vecchio, pianifica una migrazione.
- Nessun'altra modifica incompatibile registrata qui finora. Segui la documentazione ufficiale sui modelli per la pianificazione autorevole.