Vigilancia de obsolescencia y migración
Los modelos se retiran, los parámetros se renombran, los comportamientos cambian. Esta página realiza el seguimiento de los cambios incompatibles para que las actualizaciones no te sorprendan. Si construyes sobre la API, revísala periódicamente.
Por qué esto importa
Un ID de modelo fijado acabará quedando obsoleto y luego será eliminado. El código que lo codifica a mano se rompe. Un poco de higiene evita sorpresas a las 2 de la madrugada.
Reglas de supervivencia
- Lee los IDs de modelo desde la configuración, nunca repartas literales por el código — así migrar es un cambio de una sola línea.
- Vigila los anuncios para conocer las fechas de obsolescencia y los reemplazos recomendados.
- Vuelve a ejecutar tus evals cuando cambies de modelo — el comportamiento puede variar incluso en un modelo "más nuevo y mejor".
- Prueba antes de la fecha límite, no después de la eliminación.
Tipos comunes de cambio
| Cambio | Ejemplo | Qué hacer |
|---|---|---|
| Modelo retirado | Un ID de modelo antiguo deja de funcionar | Pasa al sucesor recomendado; vuelve a evaluar |
| Parámetro sustituido | Un control de razonamiento/presupuesto reemplazado por effort | Actualiza las llamadas; consulta Pensamiento y esfuerzo |
| Cambio de predeterminado | Un nuevo modelo/comportamiento predeterminado | Fija el modelo de forma intencionada; verifica que tus prompts siguen funcionando |
| Actualización de endpoint/SDK | Nueva versión mayor del SDK | Lee la guía de migración; actualiza de forma deliberada |
Vigilancia actual
Muestra — sustitúyela por avisos de obsolescencia reales y con fuente a medida que se anuncien.
- Confirma tus IDs de modelo contra la tabla Modelos y precios actuales; si estás en un ID antiguo, planifica una migración.
- No hay ningún otro cambio incompatible registrado aquí todavía. Sigue la documentación oficial de modelos para conocer el calendario autorizado.