Para qué sirve esta hoja

Veinte preguntas con el formato exacto del test del Caso II: cuatro opciones, una correcta, acierto $+0{,}5$, error $-0{,}125$, en blanco $0$. Las soluciones, con su porqué, están al final.

Ninguna de estas veinte preguntas aparece en el test real. Lo que se repite es el temario: la teoría del Tema A, que es la que habéis aplicado al construir la web y las slides. En el test real, además, cuatro preguntas se refieren a vuestra propia ficha de trazabilidad; esas no se pueden ensayar aquí, se contestan habiéndola rellenado.

Los precios que aparecen en los cálculos son los de calculadora_costes/precios.json con fecha 2026-10-02: Sonnet 5 a 3,00 USD por millón de tokens de entrada y 15,00 de salida; A100 de 80 GB a 2,00 USD por hora. En el test real se os darán los que hagan falta en el propio enunciado, igual que aquí.

Las veinte preguntas

1. De las cuatro piezas que distinguen a un agente de un chatbot, ¿cuál es la que convierte la secuencia en un bucle?

1. Que tenga herramientas disponibles.
2. Que vuelva a mirar el resultado de cada acción y decida otra vez.
3. Que alguien le haya dado permisos de antemano.
4. Que el modelo sea de tier alto.

2. Claude Code, Claude Cowork y opencode se diferencian en la puerta de entrada y en quién paga la llamada. ¿Qué hacen los tres exactamente igual?

1. Montar el contexto, llamar al modelo, ejecutar herramientas y repetir.
2. Entrenar el modelo con vuestros datos.
3. Garantizar que el modelo no se equivoque.
4. Ejecutarse en los servidores del proveedor.

3. Una sesión de cuatro vueltas arranca con 4.000 tokens de entrada y cada vuelta añade 2.500. ¿Cuántos tokens de entrada se facturan en total?

1. 4.000
2. 11.500
3. 31.000
4. 16.000

4. ¿Por qué ocurre lo de la pregunta anterior?

1. Porque el proveedor cobra una tarifa plana por sesión.
2. Porque la API no tiene memoria y el harness reenvía el historial completo en cada vuelta.
3. Porque el modelo reentrena sus pesos con la conversación.
4. Porque los tokens de salida se recuentan como entrada al facturar.

5. De las seis piezas del harness, ¿en cuál vive el riesgo operativo?

1. El system prompt.
2. La memoria.
3. Los permisos.
4. El bucle.

6. ¿Cuál de estos no es uno de los cinco bloques del fichero de instrucciones?

1. Rol.
2. Convenciones.
3. Restricciones.
4. Histórico de versiones del modelo.

7. Una empresa tiene 20 skills de 900 tokens cada una. ¿Cuál es el ahorro por llamada de la carga progresiva frente a meterlas todas en el system prompt, suponiendo que en cada llamada se abre una sola?

1. No hay ahorro: al final se cargan todas igual.
2. Unos 16.200 tokens por llamada.
3. Unos 900 tokens por llamada.
4. Unos 18.000 tokens por llamada.

8. Según la regla de reversibilidad, ¿qué nivel de permiso corresponde a una herramienta que envía un correo a un cliente?

1. Permitir siempre: es sólo texto.
2. Preguntar o denegar: sale de la organización y no se deshace.
3. Permitir siempre si el modelo es de tier alto.
4. Depende de la longitud del correo.

9. Tenéis cinco tipos de incidencia conocidos de antemano y queréis que las fáciles las resuelva un modelo barato y sólo las difíciles lleguen al caro. ¿Qué arquitectura es?

1. Cadena fija.
2. Router.
3. Orquestador con trabajadores.
4. Agente autónomo.

10. ¿Cuál es la señal de alarma de que habéis pagado por un agente lo que era un workflow?

1. Que el agente pida confirmación muchas veces.
2. Que la factura crezca con el número de usuarios.
3. Que siempre llame a las mismas herramientas en el mismo orden.
4. Que use un modelo abierto.

11. De los cuatro modos de trabajo, ¿cuál es el que «convierte un juguete en infraestructura» y también el que dispara la factura sin que nadie mire?

1. Interactivo.
2. Plan.
3. No interactivo (-p).
4. Programado (bajo cron).

12. El esfuerzo de razonamiento aparece en un tema de costes porque…

1. obliga a contratar un tier superior.
2. el razonamiento interno son tokens de salida, los caros.
3. consume más ventana de contexto de entrada.
4. multiplica el número de llamadas a herramientas.

13. De las cuatro capas que compiten por la ventana de contexto, ¿cuál es la única que crece sola mientras el agente trabaja?

1. El system prompt.
2. Las skills cargadas.
3. Los documentos recuperados por consulta.
4. El historial de la sesión.

14. ¿Cuál es la diferencia entre podar y compactar?

1. Podar borra resultados antiguos de herramientas; compactar resume lo anterior.
2. Podar es automático; compactar lo hace el usuario.
3. Podar conserva toda la información; compactar también.
4. Son dos nombres para la misma operación.

15. Tenéis un CSV de 50.000 filas que el agente necesita para responder. ¿Qué hacéis?

1. Pegarlo entero en el prompt: para eso están las ventanas de un millón.
2. Darle una herramienta que lo consulte y filtre antes de llegar al modelo.
3. Convertirlo a PDF, que ocupa menos tokens.
4. Subir el esfuerzo de razonamiento para que lo procese mejor.

16. ¿Por qué un token de salida cuesta más que uno de entrada?

1. Porque la salida se almacena en los servidores del proveedor.
2. Porque generar exige una pasada del modelo por token, mientras que leer la entrada se paraleliza.
3. Porque la salida consume ventana de contexto y la entrada no.
4. Es una convención comercial sin base técnica.

17. Una consulta típica gasta 8.000 tokens de entrada y 1.000 de salida con Sonnet 5 (3,00 y 15,00 USD por millón). ¿Cuánto cuesta esa consulta?

1. 0,015 USD
2. 0,024 USD
3. 0,039 USD
4. 0,144 USD

18. De las tres palancas de coste, ¿cuál es la única que cambia lo que el usuario percibe?

1. Bajar de tier.
2. La caché de prompt.
3. La API de lotes (batch).
4. Ninguna de las tres: por eso se usan.

19. Vuestro contador de tokens leídos de caché sale a cero llamada tras llamada, aunque el system prompt es el mismo. ¿Cuál de estas es la causa más probable?

1. Habéis metido la fecha y la hora al principio del system prompt.
2. Estáis usando un modelo de tier bajo, que no admite caché.
3. La caché sólo funciona con la API de lotes.
4. El historial de la sesión es demasiado corto.

20. Servir un modelo propio os cuesta 1.440 USD al mes de GPU y cada consulta por API os costaría 0,039 USD. ¿A partir de cuántas consultas al mes empieza a compensar el servidor, mirando sólo esas dos cifras?

1. Unas 3.700
2. Unas 36.900
3. Unas 369.000
4. Nunca compensa: la API siempre es más barata.

Soluciones

1 — (b). El bucle es volver a decidir a la vista del resultado. Las otras tres piezas (herramientas, criterio de parada, permisos) son necesarias, pero el «otra vez» es lo que lo hace agente. Quitadle cualquiera de las cuatro y vuelve a ser un chatbot con buena prensa.

2 — (a). Los tres harnesses hacen lo mismo: montar el contexto, llamar al modelo, ejecutar herramientas y repetir. Ninguno entrena nada (b), ninguno garantiza la corrección (c), y Claude Code y opencode corren en vuestra máquina (d).

3 — (c). $4.000 + 6.500 + 9.000 + 11.500 = 31.000$. La opción (b) es lo que pagaríais si sólo contarais la última llamada, que es el error clásico; (d) es la suma de los incrementos.

4 — (b). Cada llamada a la API es independiente. Para que el modelo «recuerde» la vuelta anterior, el harness le reenvía toda la conversación, de modo que una sesión de $N$ vueltas cuesta la suma de $N$ contextos que crecen. De ahí que la factura crezca de forma cuadrática con la longitud de la sesión si no se gestiona el contexto.

5 — (c). Los permisos deciden qué se ejecuta sin preguntar. Un system prompt malo da respuestas malas; un permiso mal puesto borra una carpeta o manda un correo.

6 — (d). Los cinco son rol, convenciones, restricciones, contexto del proyecto y política de IA. El fichero se versiona con el repositorio, así que el histórico lo lleva git, no el propio fichero.

7 — (b). Cargarlas todas cuesta $20 \times 900 = 18.000$ tokens por llamada. Con carga progresiva se pagan 900 de índice más los 900 del manual que toque, es decir 1.800: el ahorro es de 16.200 tokens por llamada. La opción (d) confunde el coste total con el ahorro.

8 — (b). La regla es por la consecuencia de la acción, no por la apariencia de la herramienta: lo que se deshace con un git revert puede ir solo; lo que sale de la empresa pide confirmación humana.

9 — (b). Router: un modelo barato clasifica y sólo lo difícil llega al modelo caro. Es ahorro grande con cambio pequeño, y se aplica cuando las ramas son conocidas. El orquestador (c) es para partir una tarea en trozos independientes; el autónomo (d), para cuando ni vosotros sabéis los pasos.

10 — (c). Si siempre llama a las mismas tres herramientas en el mismo orden, los pasos se conocían de antemano y se podían escribir. El coste de un workflow se calcula; el de un agente sólo se acota.

11 — (d). El modo programado bajo cron es el que deja de necesitar a una persona delante, y por eso mismo es el que puede estar gastando todas las noches sin que nadie lo mire.

12 — (b). El razonamiento previo a la respuesta son tokens de salida, que se facturan unas cinco veces más caros que los de entrada. Es la partida que no se ve en la respuesta y sí en la factura.

13 — (d). Las otras tres las controláis vosotros: el system prompt es fijo, las skills se cargan bajo demanda y los documentos entran por consulta. El historial crece solo mientras el agente trabaja.

14 — (a). Las dos pierden información, y hay que elegir cuál duele menos. Compactar conserva el hilo y pierde el detalle; podar conserva el detalle reciente y pierde lo antiguo entero.

15 — (b). La regla: entra en el contexto lo que el modelo necesita leer entero para razonar; se toca con una herramienta lo que necesita consultar. 50.000 filas son unos 2 millones de tokens, y cada token que no mandáis es un token que no pagáis.

16 — (b). Leer la entrada se paraleliza; escribir la salida es secuencial, una pasada del modelo por cada token generado.

17 — (c). $C = 3{,}00 \cdot \frac{8.000}{10^6} + 15{,}00 \cdot \frac{1.000}{10^6} = 0{,}024 + 0{,}015 = 0{,}039$ USD. Las opciones (a) y (b) son cada sumando por separado, que es el despiste habitual.

18 — (c). El batch introduce latencia: la respuesta puede tardar hasta 24 horas, de modo que no sirve para nada conversacional. Bajar de tier y la caché no cambian lo que el usuario ve, y las tres son compatibles entre sí.

19 — (a). La caché casa por prefijo exacto: un solo byte distinto al principio invalida todo lo que viene detrás. Los tres asesinos silenciosos son la fecha y hora en el system prompt, un identificador aleatorio por petición y un diccionario serializado sin ordenar las claves. Lo estable va delante; lo que cambia, detrás.

20 — (b). $N^\star = C_{\text{servidor}} / c_{\text{consulta}} = 1.440 / 0{,}039 \approx 36.900$ consultas al mes. Aviso para el caso real: esa cifra es sólo la GPU. Sumando personal, redundancia, actualización y la ocupación que de verdad tengáis, el umbral sube bastante, y por eso la comparación honesta es coste total de propiedad contra coste total de propiedad.