23 Preguntas de Práctica de Selección y optimización de modelos con Respuestas

1. 1. Una ruta de resumen de alto volumen necesita gastar menos tokens por llamada, así que un desarrollador decide bajar el effort de razonamiento. ¿Dónde va ese ajuste dentro de una petición a la Messages API?

   • A.En una cabecera HTTP de la petición, no en el cuerpo JSON enviado.
   • B.Dentro del objeto thinking, como un campo junto a su campo type.
   • C.En el nivel superior del cuerpo, como campo hermano de max_tokens.
   • D.Dentro del objeto output_config, como campo effort de ese objeto.✓ Respuesta

   El nivel de effort es un campo de output_config, no un parámetro de nivel superior ni parte del objeto thinking; ajusta la profundidad de razonamiento y el gasto de tokens dentro de un mismo modelo, por lo que es la primera palanca de calidad tras las mejoras gratuitas.

   Ref. QB-GJVN22Fuente: Anthropic Messages API reference - output_config.effortReportar un problema con esta pregunta

2. 2. Un servicio sobre un modelo antiguo fija un presupuesto de pensamiento con budget_tokens. Al cambiar la cadena del modelo por uno más nuevo, todas las peticiones fallan con HTTP 400. ¿Qué indica eso sobre la migración?

   • A.El parámetro solo está obsoleto: el servidor lo ignora y el cuerpo queda igual.
   • B.Un parámetro retirado en el modelo nuevo se rechaza, así que el cuerpo cambia.✓ Respuesta
   • C.Es un fallo pasajero del despliegue, así que el mismo cuerpo funcionará luego.
   • D.El presupuesto ahora viaja en una cabecera, así que ese valor sale del cuerpo.

   Un parámetro que el modelo nuevo ya no acepta se rechaza con un error de validación en vez de ignorarse en silencio, y el pensamiento adaptativo sustituye al presupuesto fijo, así que migrar es un cambio de código y no solo de cadena de modelo.

   Ref. QB-X2C6AYFuente: Anthropic model migration guide - removed request parametersReportar un problema con esta pregunta

3. 3. Un desarrollador quiere que un modelo actual razone más en los tickets difíciles y menos en los fáciles, sin ajustar un número a mano en cada petición. ¿Qué descripción corresponde a cómo se configura hoy el pensamiento extendido?

   • A.La profundidad la fija el nivel del modelo y la petición no influye en cuánto razona.
   • B.Se declara un presupuesto fijo de tokens por petición y el modelo debe gastarlo entero.
   • C.La profundidad depende de temperature, así que subirla alarga el razonamiento del modelo.
   • D.El pensamiento adaptativo deja que el modelo fije la profundidad y effort regula el gasto.✓ Respuesta

   Los modelos actuales usan pensamiento adaptativo, en el que el propio modelo varía cuánto razona en cada turno, y el nivel de effort regula el gasto total; el presupuesto fijo por petición pertenece a una generación anterior de la API.

   Ref. QB-FJHBVYFuente: Anthropic extended thinking documentation - adaptive thinkingReportar un problema con esta pregunta

4. 4. Un equipo transmite las respuestas y ve que los bloques thinking llegan con el texto vacío, porque display quedó en su valor por defecto. Concluye que no se generan ni se cobran tokens de razonamiento. ¿Por qué es errónea esa conclusión?

   • A.Un bloque thinking vacío indica que el modelo usó una ruta sin razonamiento.
   • B.Los tokens de pensamiento se cobran solo si se devuelve un resumen legible.
   • C.Los bloques van vacíos porque el razonamiento se aplaza al siguiente turno.
   • D.display solo controla la visibilidad: el razonamiento ocurre y se cobra igual.✓ Respuesta

   El ajuste display solo decide si vuelve un resumen legible del razonamiento; la cadena de pensamiento en bruto nunca se devuelve con ningún ajuste, y los tokens de pensamiento se generan y se cobran igualmente.

   Ref. QB-23E6T3Fuente: Anthropic extended thinking documentation - thinking display and billingReportar un problema con esta pregunta

5. 5. Para contener el gasto, un desarrollador fija max_tokens muy por debajo de lo que suelen necesitar las respuestas de esa ruta. Los usuarios reportan respuestas cortadas a media frase. ¿Qué ocurre en esas peticiones?

   • A.La generación se corta en el tope y devuelve stop_reason max_tokens: hay que reintentar.✓ Respuesta
   • B.El modelo reescribe la respuesta para que quepa: baja la calidad pero queda completa.
   • C.El texto restante queda en el servidor y se entrega en la siguiente petición del chat.
   • D.La petición se rechaza antes de generar, así que el intento truncado no se factura.

   max_tokens es un tope duro por respuesta del que el modelo no es consciente: al alcanzarlo la salida se trunca a mitad de idea con stop_reason max_tokens y los tokens ya generados se cobran, así que reintentar convierte un tope bajo en un ahorro falso.

   Ref. QB-JJKBD4Fuente: Anthropic Messages API reference - stop_reason max_tokensReportar un problema con esta pregunta

6. 6. Un generador de informes pide a un modelo actual un documento muy largo y fija un max_tokens acorde, sin streaming. La llamada falla con un timeout HTTP antes de devolver contenido. ¿Cuál es la corrección adecuada?

   • A.Repartirla en llamadas paralelas para que cada una vuelva antes del corte.
   • B.Bajar max_tokens hasta que la respuesta entre en el timeout por defecto.
   • C.Subir los reintentos del cliente para que alguna de las llamadas sí termine.
   • D.Enviar la petición en streaming y armar la respuesta con el ayudante final.✓ Respuesta

   Una petición sin streaming mantiene la conexión abierta hasta generar toda la respuesta, así que un tope de salida grande supera el timeout HTTP; el streaming mantiene el flujo y el ayudante de mensaje final rearma la respuesta completa cuando no hacen falta los eventos.

   Ref. QB-Z23UM2Fuente: Anthropic SDK guidance - streaming required for large max_tokensReportar un problema con esta pregunta

7. 7. Un equipo activa streaming en todo un producto de chat y espera que baje la factura mensual. Las cifras de uso no se mueven. ¿Qué cambia realmente el streaming?

   • A.Comprime la respuesta en tránsito, así que se facturan menos tokens de salida.
   • B.Reutiliza los tokens del turno anterior, así el contexto repetido se cobra una vez.
   • C.Muestra los tokens según se generan: baja la latencia percibida y el riesgo de corte.✓ Respuesta
   • D.Detiene la generación cuando el cliente ya muestra bastante texto y ahorra tokens.

   El streaming cambia cómo se entregan los mismos tokens, no cuántos se generan, así que la facturación es idéntica; sus ventajas son la latencia percibida por quien espera y evitar timeouts en salidas largas.

   Ref. QB-HJ8Z73Fuente: Anthropic streaming documentation - purpose of streamingReportar un problema con esta pregunta

8. 8. Cuarenta mil tickets de soporte deben clasificarse antes del informe de la mañana y nadie espera ningún resultado concreto. ¿Qué enfoque encaja mejor con esa restricción?

   • A.Enviar el trabajo a la Message Batches API y leer los resultados al terminar.✓ Respuesta
   • B.Bajar al modelo más pequeño para todo, ya que el volumen es lo que se paga.
   • C.Lanzar las llamadas en paralelo desde muchos workers, pues así baja el coste.
   • D.Enviar las llamadas de una en una con streaming, la entrega más barata que hay.

   El procesamiento por lotes cambia latencia por coste: las mismas peticiones enviadas de forma asíncrona se facturan con descuento frente al tiempo real, y la ventana nocturna es justo la tolerancia que un lote necesita. Paralelizar acorta el reloj, no el precio por token.

   Ref. QB-435U56Fuente: Anthropic Message Batches API - asynchronous processing discountReportar un problema con esta pregunta

9. 9. Un lote de varios miles de peticiones termina y un desarrollador empareja los resultados con la lista de entrada por posición. Algunos registros quedan con la salida de otro ticket. ¿Qué regla se incumple?

   • A.Los resultados se paginan y solo la primera página coincide con el orden inicial.
   • B.Los resultados omiten los fallos, la lista se desplaza y hay que rellenar huecos.
   • C.Los resultados llegan en orden arbitrario y hay que casarlos por su custom_id.✓ Respuesta
   • D.Los resultados vienen por hora de término y hay que ordenarlos antes de casarlos.

   La Batches API devuelve cada resultado identificado por el custom_id que envió el llamador y en cualquier orden, así que la posición en el flujo de resultados no guarda relación con la de la lista enviada; casar por índice mezcla los registros en silencio.

   Ref. QB-MJAZQ6Fuente: Anthropic Message Batches API - results are returned by custom_id in any orderReportar un problema con esta pregunta

10. 10. Un desarrollador toma una petición en tiempo real que usa streaming y envía esos mismos parámetros dentro de un lote. El lote se rechaza por inválido. ¿Qué explica el rechazo?

    • A.Falla porque una petición con streaming exige una cabecera igual en el lote.
    • B.El lote acepta streaming solo si todas sus peticiones piden también ese formato.
    • C.El streaming no está disponible dentro de un lote, que se lee entero al terminar.✓ Respuesta
    • D.El streaming sí se permite en lotes, así que el fallo viene del tamaño del lote.

    Las entradas de un lote se procesan de forma asíncrona y sus resultados se recuperan cuando el lote termina, así que el streaming por petición no tiene sentido y el parámetro no se acepta; el streaming pertenece a la ruta en tiempo real, donde alguien espera.

    Ref. QB-2EW74PFuente: Anthropic Message Batches API - unsupported request parametersReportar un problema con esta pregunta

11. 11. Un agente cachea un sistema largo y lo reutiliza entre turnos. Una release añade una herramienta a la lista y las lecturas de caché caen a cero en todas las peticiones siguientes. ¿Por qué cuesta tanto ese cambio?

    • A.La lista de tools queda fuera del prefijo cacheado, así que la caída viene del system.
    • B.Cambiar tools reinicia la vida de la caché: la entrada caduca antes pero se rehace luego.
    • C.Las definiciones de tools se cachean aparte, así que solo se borra la entrada de esa tool.
    • D.Las tools se renderizan antes que system y messages, y el cambio invalida lo que sigue.✓ Respuesta

    La caché de prompt es una coincidencia de prefijo que se renderiza en el orden tools, luego system y luego messages, y un cambio de un solo byte en el prefijo invalida todo lo posterior, de modo que editar la lista de tools arrastra al system y al historial.

    Ref. QB-HWQ2HNFuente: Anthropic prompt caching documentation - cache invalidation hierarchyReportar un problema con esta pregunta

12. 12. Un servicio cachea un sistema largo, pero cache_read_input_tokens es cero en cada petición repetida. El sistema lo arma un ayudante que estampa la hora actual en su primera línea. ¿Qué debe hacer el desarrollador?

    • A.Alargar la vida de la caché para que la entrada sobreviva entre las llamadas.
    • B.Mover la marca de tiempo al inicio del sistema para que el resto sea estable.
    • C.Añadir más puntos de caché para que alguno quede antes de la línea variable.
    • D.Sacar la marca de tiempo del prefijo y ponerla tras el último punto de caché.✓ Respuesta

    Cualquier byte que difiera entre peticiones rompe la coincidencia de prefijo para todo lo posterior, así que una marca de tiempo o un id por petición en el system impide cachear en silencio; el contenido volátil va tras el último punto de caché, donde no invalida lo estable.

    Ref. QB-3E9J9QFuente: Anthropic prompt caching documentation - silent invalidatorsReportar un problema con esta pregunta

13. 13. Un desarrollador revisa el uso de una petición cacheada y ve un input_tokens pequeño junto a un cache_read_input_tokens grande. ¿Qué representa esa cifra pequeña de input_tokens?

    • A.Los tokens que el modelo atendió de verdad, ya descartado el prefijo fijo.
    • B.Los tokens que esta petición escribió en la caché antes de poder leerlos.
    • C.El tamaño total del prompt, con los tokens cacheados contados otra vez ahí.
    • D.Los tokens posteriores al último punto de caché que no se sirvieron de caché.✓ Respuesta

    input_tokens cuenta solo la entrada no cacheada de esa petición; cache_read_input_tokens y cache_creation_input_tokens se informan por separado, y la entrada total de la llamada es la suma de las tres cifras.

    Ref. QB-JW3DPPFuente: Anthropic prompt caching documentation - usage fieldsReportar un problema con esta pregunta

14. 14. Un desarrollador añade caché de prompt a un endpoint cuyo tráfico son casi todo peticiones únicas sin prefijo compartido entre usuarios. La factura sube un poco. ¿Por qué?

    • A.Las lecturas cuestan igual que la entrada normal, así que solo añaden coste.
    • B.La caché cobra el prefijo dos veces: como entrada y como entrada de caché.
    • C.Cada petición paga el sobrecoste de escritura y ninguna llega a leer nada.✓ Respuesta
    • D.Las entradas se cobran por toda su vida útil, así que una ociosa sigue costando.

    Escribir un prefijo en la caché cuesta algo más que esa misma entrada sin cachear, mientras que una lectura de caché cuesta bastante menos, así que la caché solo compensa cuando el prefijo se reutiliza de verdad; el tráfico de un solo uso paga la escritura y nunca cobra el descuento.

    Ref. QB-4EMVERFuente: Anthropic prompt caching documentation - cache write and read pricing multipliersReportar un problema con esta pregunta

15. 15. Un agente de larga duración activa la compactación del servidor. El desarrollador solo añade el texto de la respuesta a la lista de mensajes y el contexto sigue creciendo como si nada. ¿Qué salió mal?

    • A.Hay que añadir el contenido completo, porque los bloques de compactación van ahí.✓ Respuesta
    • B.La compactación exige que el llamador borre antes los turnos viejos para actuar.
    • C.La compactación solo toca resultados de tools, así que un chat de texto no cambia.
    • D.El resumen llega en la respuesta siguiente, así que hace falta un turno más aún.

    La compactación resume el contexto anterior en el servidor y devuelve ese estado como bloques dentro del contenido de la respuesta, así que añadir solo el texto extraído lo pierde en silencio y la conversación vuelve al historial completo; borrar bloques es otro mecanismo distinto.

    Ref. QB-KWEQUQFuente: Anthropic context management documentation - compaction versus context editingReportar un problema con esta pregunta

16. 16. Antes de lanzar una ruta que mete un documento grande en cada prompt, un desarrollador quiere un tamaño de entrada exacto para presupuestar. ¿Cuál es la forma correcta de obtenerlo?

    • A.Mandar una petición y leer los tokens de salida, que siguen de cerca la entrada.
    • B.Dividir el número de caracteres entre cuatro, la razón citada para prosa inglesa.
    • C.Llamar al endpoint de conteo de tokens con el mismo modelo, sistema y mensajes.✓ Respuesta
    • D.Pasar un tokenizador de terceros por el texto y usar la cifra que ese reporta.

    El endpoint count_tokens cuenta la petición tal como lo haría la API, incluidos el system y las definiciones de tools, así que es la única cifra fiable previa; los tokenizadores de terceros son de otros vocabularios y las reglas por caracteres varían con el idioma.

    Ref. QB-5EY7MSFuente: Anthropic token counting endpoint - /v1/messages/count_tokensReportar un problema con esta pregunta

17. 17. Un desarrollador elige entre dos modelos para una ruta que debe aceptar entradas muy grandes y necesita la capacidad de contexto y las funciones de cada candidato. ¿Cómo se resuelve bien en código?

    • A.Mandar prompts cada vez mayores hasta que uno falle y tomar ese tamaño.
    • B.Suponer que toda la familia comparte límites, pues siguen a ese nombre.
    • C.Consultar la Models API por la entrada actual y leer sus campos de límites.✓ Respuesta
    • D.Fijar en una constante del código las cifras del anuncio de ese nivel.

    La capacidad, el precio y el contexto difieren de un modelo a otro y cambian con cada lanzamiento, así que los valores actuales se descubren consultando la Models API o leyendo la documentación vigente, no de memoria, por ensayo y error ni deduciéndolos del nombre.

    Ref. QB-MWS22SFuente: Anthropic Models API - GET /v1/models capability discoveryReportar un problema con esta pregunta

18. 18. Una ruta usa un modelo de frontera con effort bajo. Un modelo más barato con effort alto tiene menor precio por token, pero necesita más turnos y más reintentos para el mismo trabajo. ¿Cómo se decide?

    • A.Comparar la latencia inicial, pues un modelo más rápido termina el trabajo por menos.
    • B.Comparar el coste por tarea completada, pues turnos y reintentos van a la factura.✓ Respuesta
    • C.Comparar solo el precio de salida, pues la salida domina lo que cuesta una petición.
    • D.Comparar el precio por token de entrada, pues la factura se calcula con esa cifra.

    La guía de Anthropic es juzgar el coste por tarea completada y no el precio por token: un modelo más capaz con un nivel de effort más bajo suele resolver la tarea en menos turnos y con menos reintentos, así que puede salir más barato aunque su tarifa sea mayor.

    Ref. QB-WDGVDHFuente: Anthropic cost optimization guidance - cost per completed taskReportar un problema con esta pregunta

19. 19. Para gastar menos, un equipo propone enrutar las peticiones fáciles a un modelo pequeño y las difíciles a uno grande, con el mismo sistema largo cacheado en ambas rutas. ¿Qué consecuencia deben sopesar antes?

    • A.La caché es por modelo, así que el prefijo común se cachea y se paga en cada ruta.✓ Respuesta
    • B.El router debe ser otra llamada al modelo, y ese salto es lo que encarece la cascada.
    • C.Enrutar obliga a reenviar el prefijo sin cachear, pues solo un modelo puede tenerlo.
    • D.La caché se comparte entre modelos, así que la segunda ruta lee gratis la primera.

    Las cachés de prompt están acotadas a un solo modelo, así que una cascada no puede reutilizar en otro el prefijo cacheado del primero y duplica el coste de escritura en ambas rutas; conviene medir antes la alternativa simple: un modelo capaz con menos effort.

    Ref. QB-DWAQTGFuente: Anthropic prompt caching documentation - caches are model-scopedReportar un problema con esta pregunta

20. 20. Un servicio en TypeScript fija el timeout del cliente en 30, con la intención de treinta segundos. Las peticiones largas empiezan a fallar casi de inmediato. ¿Cuál es la causa?

    • A.El valor se recorta al mínimo que admite el cliente, muy por debajo de un segundo.
    • B.En ese SDK el timeout se fija por petición, así que el valor del cliente no se usó.
    • C.El timeout es un límite por token, así que una generación larga lo agota igualmente.
    • D.Ese SDK expresa el timeout en milisegundos, así que quedó un límite de treinta ms.✓ Respuesta

    Las unidades del timeout difieren entre los SDK oficiales: unos toman segundos, otros milisegundos y otros un tipo de duración, así que un número copiado de un lenguaje a otro cambia de significado en silencio; conviene verificar la unidad del SDK en uso.

    Ref. QB-P57CHWFuente: Anthropic SDK client configuration - timeout units by SDKReportar un problema con esta pregunta

21. 21. Un endpoint sensible a la latencia fija un timeout amplio y deja los reintentos automáticos por defecto. Un usuario reporta una petición que colgó mucho más que el timeout antes de fallar. ¿Qué lo explica?

    • A.Los timeouts se reintentan, así que el peor caso es el timeout por cada intento.✓ Respuesta
    • B.El timeout cubre solo la conexión, así que el tiempo de generación no cuenta ahí.
    • C.El timeout se reinicia con cada evento del stream, y un stream lento lo alarga.
    • D.Los reintentos esperan tras el límite de tasa, así que la demora es de cola pura.

    Un timeout es una de las fallas que el SDK reintenta automáticamente, así que el reloj total puede llegar al timeout multiplicado por el número de intentos, es decir la llamada inicial más los reintentos configurados; ambos ajustes se presupuestan juntos.

    Ref. QB-7NCH4XFuente: Anthropic SDK client configuration - timeouts are retriedReportar un problema con esta pregunta

22. 22. Una integración envuelve todas las llamadas en un único catch amplio que registra y reintenta. Ahora reintenta sin fin las peticiones mal formadas y se rinde pronto ante los límites de tasa. ¿Cómo reestructurarla?

    • A.Reintentar todo fallo con espera, ya que un error permanente volverá a fallar barato.
    • B.Capturar las excepciones tipadas de más concreta a más amplia y reintentar solo unas.✓ Respuesta
    • C.Comparar el texto del mensaje de cada error para cubrir los fallos que vayan surgiendo.
    • D.Tratar como reintentable todo error con código y saltar solo los fallos de conexión.

    Los SDK exponen clases de excepción tipadas, y una cadena de más concreta a más amplia es lo que separa los fallos reintentables como límites de tasa, errores de servidor y problemas de conexión de los permanentes como una petición mal formada o credenciales inválidas.

    Ref. QB-Q5JPPXFuente: Anthropic SDK error handling - typed exception classesReportar un problema con esta pregunta

23. 23. Una función de chat envía solo el mensaje de usuario más reciente en cada turno y Claude pierde el hilo de los detalles anteriores. ¿Qué debe cambiar el desarrollador?

    • A.Activar el streaming, que mantiene viva la conexión y conserva el orden de turnos.
    • B.Reenviar toda la conversación cada turno, pues la API no guarda estado entre llamadas.✓ Respuesta
    • C.Poner un id de conversación en cada llamada para que el servidor una los turnos.
    • D.Subir max_tokens para que el modelo tenga sitio donde recordar los turnos previos.

    La Messages API no tiene estado, así que cada petición se responde solo con lo que ella contiene y el historial debe reenviarse en cada turno; ese historial creciente es el mayor coste de las conversaciones largas, por lo que casi todo él debería llegar como lecturas de caché.

    Ref. QB-8NQU9YFuente: Anthropic Messages API - stateless conversation historyReportar un problema con esta pregunta

Preguntas de práctica basadas en la guía oficial del examen Claude Certified Developer – Foundations (CCDV-F) y la documentación pública de Anthropic. Es una herramienta de estudio independiente, no afiliada ni respaldada por Anthropic, y no otorga certificación. Lo administra Pearson VUE; Anthropic publica el número de preguntas, el límite de tiempo, la puntuación de aprobación y la tarifa vigentes en la guía oficial del examen CCDV-F. Página oficial de la certificación →