Interpretación de las nuevas funciones: salida extendida de Claude API, generador de prompts y panel de uso

Esta actualización de Claude API se centra principalmente en resolver tres cosas: respuestas más largas, depuración más rápida y costes más transparentes. A continuación, siguiendo el recorrido más habitual de los desarrolladores, desgloso las nuevas funciones de Claude API y aporto puntos clave de uso que puedes copiar tal cual.

Salida extendida de Claude API: Sonnet 3.5 duplica la salida máxima

En Claude API, el límite máximo de tokens de salida de Claude Sonnet 3.5 se ha incrementado de 4096 a 8192, lo que lo hace adecuado para resúmenes más largos, generación de código e instrucciones de varios pasos. Para habilitar la salida extendida, es necesario añadir en la solicitud el encabezado beta especificado.

El método es muy directo: al llamar a Claude API, añade el encabezado anthropic-beta: max-tokens-3-5-sonnet-2024-07-15 y configura max_tokens con el valor que necesites. Se recomienda definir también una estructura de salida clara (por ejemplo, por puntos, por secciones, campos JSON); de lo contrario, que sea más largo no necesariamente será más legible.

Actualización del Workbench de la consola: el generador de prompts es más adecuado para “redactar rápido”

El Workbench de la consola de Claude incorpora un generador de prompts: basta con describir la tarea en una frase (por ejemplo, “clasificar y procesar solicitudes entrantes de soporte al cliente”) y te ofrecerá una plantilla de prompt más completa. Para quienes suelen escribir instrucciones de system y necesitan estandarizar el formato de salida, esta función ahorra muchas iteraciones de prueba y error.

Un uso más práctico es: primero, deja que el generador produzca una versión “ejecutable”, y luego incorpora tus restricciones reales, como validación de campos, manejo de fallos (fallback), longitud de salida y estilo de lenguaje. Por último, vuelve a volcar el prompt final en el system de Claude API o en la primera instrucción de user, y listo.

Modo de evaluación: antes de usar Claude API, compara prompts con una pasada

El modo de evaluación del Workbench permite comparar en paralelo las salidas de dos o más prompts y puntuar los resultados con una escala de 5 puntos. Es especialmente útil para pruebas A/B de “misma tarea, distintas redacciones”: por ejemplo, para extraer campos, uno orientado a la robustez y otro a la concisión.

Se recomienda fijar, antes del lanzamiento, un pequeño conjunto de muestras: 3–10 entradas típicas y 1 entrada extrema, y luego usar el modo de evaluación para seleccionar la solución más estable. Así, tras poner Claude API en producción, es menos probable que aparezcan desviaciones de formato, campos sin completar o explicaciones excesivamente largas.

Panel de uso y costes: entender claramente el coste de Claude API

La consola para desarrolladores añade las pestañas de “Uso” y “Costes”, que permiten seguir el consumo por importe en dólares, cantidad de tokens y clave de API. Para escenarios con múltiples entornos (pruebas/preproducción/producción) o con varias personas/equipos compartiendo la misma cuenta, este cambio es clave.

En la gestión práctica, se recomienda dividir las claves de API por línea de negocio y, cada vez que se modifique el prompt o se aumente max_tokens, volver al panel para comparar los cambios en tokens. El coste de Claude API a menudo no proviene del modelo en sí, sino de que el prompt y la salida se alargan y el consumo se amplifica de forma silenciosa.

Notas de versión y recursos de aprendizaje: no vuelvas a “adivinar” las actualizaciones

La documentación oficial se ha complementado con notas de versión más completas, que cubren Claude API, la consola y las actualizaciones del lado de la aplicación, facilitando consultar los motivos de los cambios y su alcance. Además, se han añadido cursos y guías tipo Cookbook, centrados en capacidades de uso frecuente como citas, RAG (generación aumentada por recuperación) y clasificación.

Si ya estás usando Claude API para RAG, clasificación o extracción estructurada, se recomienda incorporar las “notas de versión” como un elemento de revisión rutinaria: si se ajusta el comportamiento de la interfaz, los límites o las prácticas recomendadas, podrás detectar el problema antes de que se manifieste como un error en producción.