Ejercicios — Guía Práctica de Claude

1. Claude Haiku 4.5 — claude-haiku-4-5 ($1/$5)
2. Claude Sonnet 4.6 — claude-sonnet-4-6 ($3/$15)
3. Claude Opus 4.8 — claude-opus-4-8 ($5/$25)
4. Claude Fable 5 — claude-fable-5 ($10/$50)

Los IDs van exactos, sin sufijos de fecha.

• (a) 2,000 × 1.3 = ~2,600 tokens.
• (b) 200,000 / 1.3 ≈ ~154,000 palabras — una novela entera y sobra.

(1) El comportamiento del modelo se guía por principios explícitos y escritos (una "constitución": ser útil, honesto, evitar daño) en lugar de depender solo de millones de calificaciones humanas implícitas. (2) Durante el entrenamiento, el modelo critica y revisa sus propias respuestas contra esos principios, lo que escala mejor que la supervisión humana directa. Efecto visible: un asistente que admite incertidumbre y explica sus negativas.

El modelo tiene un corte de conocimiento: no sabe nada posterior a su fecha de entrenamiento. Ante un evento reciente, o bien dice que no sabe, o bien alucina una respuesta plausible — y el tono seguro no se correlaciona con la exactitud. Para eventos recientes: búsqueda web activada o una fuente directa.

• (a) Haiku 4.5 — extracción simple y masiva; el volumen hace crítico el precio.
• (b) Sonnet 4.6 (o Haiku) — conversación general; el balance velocidad/precio importa más que la potencia máxima.
• (c) Opus 4.8 — análisis serio de alto valor, el default para trabajo importante.
• (d) Fable 5 — trabajo agéntico de larga duración, su especialidad declarada.

• (a) App (claude.ai) — conversación de estudio, con un Proyecto de la materia.
• (b) API — programático, repetitivo, sin humano en el medio.
• (c) Claude Code — multi-archivo sobre un repo, con tests como verificación.
• (d) App — interfaz amigable, cero instalación, cero código.

Entrada: 0.012M × $3 = $0.036. Salida: 0.0025M × $15 = $0.0375. Total: $0.0735 — nota que la salida costó más que la entrada con 5 veces menos tokens.

• (a) (3 × 150,000 + 20,000) × 1.3 = 470,000 × 1.3 = ~611,000 tokens.
• (b) Sí: 611K < 1M (ventana de Opus 4.8), queda ~39% libre para la conversación.
• (c) No: 611K > 200K (ventana de Haiku). Habría que partir el material o usar otro modelo.

• (a) No crítica — concepto estable; un error sería raro y lo detectarías al estudiar.
• (b) SÍ, siempre — textos legales citados: candidato clásico a alucinación. Buscá el texto oficial.
• (c) No — no hay hechos verificables en juego.
• (d) Verificación barata — probablemente cierto, pero probarlo toma 10 segundos en tu terminal; las funciones inventadas existen.
• (e) SÍ, siempre — estadística + cita de estudio = verificá que el estudio exista y diga eso.

Por día: entrada 500 × 2,000 = 1M tokens; salida 500 × 300 = 0.15M.

• Fable 5: 1 × $10 + 0.15 × $50 = $10 + $7.50 = $17.50/día.
• Haiku 4.5: 1 × $1 + 0.15 × $5 = $1 + $0.75 = $1.75/día.

Ahorro: $15.75/día × 365 = $5,748.75 al año — por cambiar una línea de código. La elección de modelo es la decisión de costos más importante de cualquier app.

Confunde ventana de contexto (cuánto cabe en UNA conversación a la vez) con memoria persistente (que no existe). La realidad: cada conversación arranca de cero; dentro de una conversación, el modelo "ve" lo que está en el contexto (hasta 1M tokens), y al cerrarla, nada persiste. Las excepciones son funciones explícitas de la app — como los Proyectos, que persisten instrucciones y archivos (no conversaciones) — o el historial que TU código reenvía cuando usás la API.

Respuesta personal. Criterios de autoevaluación: (1) cada tarea tiene superficie asignada por el criterio "quién consume el resultado" (vos → app; repo → Claude Code; programa → API); (2) los modelos arrancan por el más barato plausible; (3) la justificación del "no obvio" muestra trade-offs reales — p. ej. "para resumir lecturas la opción obvia era la API, pero elegí Proyectos en claude.ai porque quiero repreguntar interactivamente, no procesar en lote".

Contexto, tarea, formato, restricciones. Ejemplo: "Estoy en primer año y nunca programé [contexto]; explicame qué es un bucle for con un ejemplo en Python [tarea]; en menos de 200 palabras y con el código comentado [formato]; sin mencionar while todavía, no lo hemos visto [restricciones]."

Persisten: las instrucciones del Proyecto y los archivos cargados — todas las conversaciones nuevas arrancan con ese contexto. No persiste: el historial de cada conversación — cada chat dentro del Proyecto es independiente de los demás.

Un artefacto es contenido sustancial (documento, código, diagrama, mini-app) que Claude genera en un panel separado del chat, donde podés verlo, iterarlo y exportarlo sin que se mezcle con la conversación. Ejemplos: un quiz interactivo de práctica para el parcial; un diagrama de los temas del ciclo conectados por dependencias.

• (a) No — conocimiento estable y atemporal.
• (b) Sí — convocatorias cambian cada año; además querés la fuente oficial.
• (c) No — la fuente es tu PDF; la web solo metería ruido.
• (d) Sí — versiones de software cambian constantemente; posterior al corte de conocimiento.

Porque el objetivo del estudiante es aprender, no obtener respuestas. Si Claude resuelve todo de una, el estudiante consume soluciones sin construir la habilidad — y el examen lo rinde solo. El modo socrático fuerza práctica de recuperación y generación: intentar antes de recibir, que es de lo más respaldado en la investigación del aprendizaje. La respuesta completa sigue disponible — pero a pedido explícito, como decisión consciente.

• (a) Señales: la respuesta no usa la terminología/notación del PDF, no cita secciones, o incluye temas que el documento no toca. Prueba directa: "¿en qué sección del documento está eso?"
• (b) Fórmula de anclaje: "Según el documento que subí (citá la sección), ¿...? Si la respuesta no está en el documento, decime explícitamente 'no está en el material' antes de agregar conocimiento general."

El borrador lo escribís vos (paso 4). Razones: (1) escribir es donde ocurre el aprendizaje — organizar ideas propias construye comprensión que leer no construye; (2) integridad académica — un texto generado y entregado como propio es plagio en la mayoría de las políticas universitarias; (3) calidad — Claude revisa mejor un texto tuyo (estructura, claridad) de lo que vos podés verificar un texto suyo (¿inventó algo?). Claude entra antes (estructura, fuentes) y después (revisión por capas), no en el medio.

Una secuencia razonable:

1. "Describí este dataset: variables, tipos, faltantes, valores raros o imposibles."
2. "¿Qué problemas de calidad ves y cómo afectaría cada uno a las conclusiones?"
3. "Calculá descriptivos de las variables clave y cruzá horas de estudio con rendimiento autorreportado. Generá un artefacto con los 3 gráficos más informativos."
4. "Formulá los 3 hallazgos principales — y para cada uno, qué NO podemos concluir dada la muestra y el diseño."

El patrón: explorar → limpiar → analizar/visualizar → interpretar con freno.

(1) Anonimizar antes de subir: eliminar nombres, carnets y teléfonos; si hace falta distinguir personas, reemplazar por IDs genéricos (M001, M002). Las estadísticas salen igual de columnas como carrera, año, asistencia. (2) Verificar que ninguna combinación de columnas re-identifique (si solo hay una estudiante de Arquitectura de 5.º año, "carrera+año" la identifica). Regla de fondo: datos personales de terceros no se suben sin anonimizar — por respeto, por normas universitarias y por ley.

Ejemplo de referencia:

"Trabajá sobre los PDFs de este Proyecto (unidades 3 y 4) [fuente]. Creá una mini-app de quiz con 20 preguntas: 12 de selección múltiple, 5 de verdadero/falso con justificación y 3 de respuesta corta [tipos]. Al fallar, mostrá la respuesta correcta + por qué + en qué sección del material estudiarlo [comportamiento al fallar]. Dificultad creciente: las últimas 5 deben combinar dos temas a la vez, como hace mi profesor [criterio]. Al final, mostrame mi puntaje por tema para saber qué repasar."

Lo evaluable: que cada requisito esté especificado y verificable, no "haceme un quiz bonito".

1. Instrucciones vagas o sin la cláusula explícita ("basate en los PDFs", "guiame con preguntas ANTES de dar soluciones"). Diagnóstico: releé tus instrucciones — ¿son órdenes verificables o deseos generales?
2. Conversación fuera del Proyecto. Clásico: abriste un chat suelto creyendo que estabas dentro. Diagnóstico: verificá en qué contexto está la conversación.
3. Archivos mal cargados o ilegibles (escaneos de pésima calidad, PDFs protegidos). Diagnóstico: preguntá "listá los documentos que tenés disponibles y el título de sus secciones".
4. Preguntas que no activan el material (preguntás cosas que tus PDFs no cubren — Claude completa con conocimiento general, correctamente). Diagnóstico: probá con una pregunta que SÍ esté literalmente en el material.

Respuesta personal. Criterios de autoevaluación: (1) cada flujo nombra Proyecto y archivos concretos, no genéricos; (2) los prompts incluyen formato y restricciones; (3) la ejecución real produjo un artefacto o resultado usable (plan de estudio, guía, análisis); (4) la reflexión identifica al menos un ajuste específico ("las 10 preguntas diagnósticas eran muy fáciles: pedir nivel parcial, no nivel tarea").

"...en un bucle con herramientas". El modelo decide una acción (leer archivo, ejecutar comando), la herramienta la ejecuta, el resultado vuelve al modelo, y el ciclo se repite hasta completar la tarea. Eso lo diferencia del chat: el chat solo produce texto; el agente actúa y observa las consecuencias de sus acciones.

Terminal (CLI), web, app de escritorio y extensión de IDE (VS Code, JetBrains). Para el día a día estudiantil, terminal o extensión de IDE son las naturales: la terminal es la experiencia más completa; el IDE suma ver los diffs integrados donde ya trabajás.

1. Comandos — ¿cómo se corre, prueba y construye esto?
2. Estructura — ¿dónde está cada cosa?
3. Convenciones — ¿cómo escribimos código acá?
4. Advertencias — ¿qué no se toca y por qué?

Entender un repo ajeno — es solo lectura: el agente no edita ni ejecuta nada con efectos. Conviene empezar ahí porque aprendés la dinámica de la herramienta (permisos, estilo de trabajo, calidad de respuestas) sin posibilidad de romper nada, y de paso producís algo valioso (el mapa del proyecto).

"El script generar_reporte.py tarda ~4 minutos con el CSV de 50,000 filas de data/ventas.csv [contexto]. Objetivo: bajarlo a menos de 30 segundos [objetivo]. Criterio: el test tests/test_reporte.py sigue pasando (mismo output exacto) y el tiempo medido con time python generar_reporte.py baja de 30s [criterio verificable]. Restricciones: sin dependencias nuevas; sospecho del bucle que lee fila por fila — probá pandas vectorizado que ya está en requirements [restricciones + pista]."

Que se escriba antes y falle garantiza que el test reproduce el bug real — si pasara de entrada, no está probando el bug (o el bug no es el que creés). Que después pase demuestra que el arreglo funciona para ese caso. Que quede en la suite garantiza que el bug no regresa sin que nadie lo note (test de regresión). Sin esta disciplina, "lo arreglé" es una opinión; con ella, es un hecho verificable.

Previene que el agente cambie el comportamiento y ajuste los tests para que coincidan — que es lo contrario de refactorizar. Ejemplo: al extraer la lógica de descuentos, el agente introduce un redondeo distinto; el test assert total == 10.50 falla; sin la cláusula, el camino corto es cambiar el test a 10.49 y declarar éxito. Con la cláusula, el agente debe preservar el comportamiento original — que es la definición misma de refactor.

(1) El sistema de permisos de Claude Code: pide aprobación antes de acciones con efecto (editar, ejecutar comandos) — control fino, acción por acción, ANTES de que pase. (2) La rama de git: trabajar siempre en una rama dedicada hace que cualquier desastre se descarte borrando la rama — red de seguridad gruesa, DESPUÉS de que pasó. Se complementan: el permiso evita el daño puntual; la rama hace reversible el daño acumulado.

Agregar la regla al CLAUDE.md: "Usamos [librería] v3 — no sugerir sintaxis de v2 (en particular, X cambió a Y)". Corregirlo en el chat solo arregla esa sesión: el agente no retiene memoria entre sesiones, así que mañana repetirá el error. CLAUDE.md se lee automáticamente al inicio de cada sesión — es la memoria persistente del proyecto. Regla general: error repetido = regla nueva en CLAUDE.md.

Aceptás solo la línea del typo; rechazás el resto. No porque los otros cambios sean necesariamente malos, sino porque (1) no fueron pedidos ni revisables en este contexto — un timeout ×10 puede tener consecuencias serias que nadie evaluó; (2) mezclan propósitos en un mismo commit, lo que arruina el historial y complica revertir. Le decís: "revertí config.py y requirements.txt. Si creés que el timeout y la librería valen la pena, explicame el porqué de cada uno y los hacemos como tareas separadas." Y de paso, al CLAUDE.md: "no hacer cambios fuera del alcance del pedido; proponerlos por separado".

División razonable:

1. Modelos y base: entidades Alumno, Evaluación, Nota + esquema + tests de modelos.
2. CRUD de alumnos y evaluaciones: endpoints/comandos básicos + tests.
3. Lógica de ponderaciones: cálculo de nota final con reglas de la cátedra + tests exhaustivos (acá viven los bugs caros).
4. Reportes: consultas de notas por alumno/grupo + tests.
5. Exportación a Excel: sobre los reportes ya probados.

El orden correcto es el de dependencias + riesgo: cada etapa usa las anteriores ya revisadas, y la lógica más delicada (ponderaciones) llega cuando la base es sólida y ella sola concentra tu atención de revisión. Anti-patrón: empezar por la exportación a Excel "porque es lo visible".

Respuesta personal. Autoevaluación: (1) el CLAUDE.md tiene las 4 secciones y al menos una regla anti-error-personal; (2) el pedido tiene criterio de éxito verificable por el agente (tests, comando, output esperado); (3) el veredicto del diff documenta al menos una decisión no trivial (algo que preguntaste, rechazaste o pediste cambiar — si aceptaste todo a la primera, revisá si de verdad leíste el diff).

import anthropic

client = anthropic.Anthropic()
respuesta = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Explicame qué es una variable."}],
)
print(respuesta.content[0].text)

Olvidos típicos: max_tokens (es obligatorio), el [0] en content (es una lista de bloques), y el formato exacto del mensaje (role + content).

El cliente busca automáticamente la variable de entorno ANTHROPIC_API_KEY — por eso el código no necesita (ni debe) conocer la key. La segunda forma funciona, pero pone el secreto dentro del archivo: cuando ese archivo llegue a GitHub (llegará), bots la encontrarán en minutos y gastarán tu saldo. Key en el código = key quemada.

• (a) Válida — un solo mensaje de user, el caso más simple.
• (b) Inválida — el primero siempre debe ser user.
• (c) Válida — alternancia perfecta; es la forma de un tercer turno.
• (d) Inválida — dos user consecutivos rompen la alternancia → error 400.

El system define comportamiento persistente con mayor peso: instrucciones de rol que el modelo trata como reglas del juego, separadas de la conversación. Como mensaje de user también suele funcionar, pero compite con el resto de la conversación y puede diluirse a medida que el historial crece. Regla: instrucciones de comportamiento → system; contenido de la conversación → messages.

• (a) Todo lo que mandaste: el system prompt + el historial completo + la pregunta nueva. No solo "tu pregunta" — por eso los historiales largos encarecen los turnos.
• (b) 0.0042M × $5 + 0.00085M × $25 = $0.021 + $0.02125 = $0.04225.

Hipótesis #1 (con mucha ventaja): no se reenvía el historial — el request manda solo el último mensaje. Línea a buscar: el messages= del create(); si dice algo como messages=[{"role": "user", "content": pregunta}] dentro del bucle, ahí está. Corrección: mantener una lista historial, hacer append del mensaje de user antes del request Y del de assistant después, y pasar messages=historial. La API es stateless: la memoria es tu lista.

• (a) create() — salidas de una palabra, sin nadie mirando; streaming no aporta.
• (b) Streaming — interfaz interactiva: ver el texto fluir cambia la experiencia.
• (c) Streaming, obligatorio — salida larga: sin streaming, riesgo real de timeout antes de terminar la generación.
• (d) create() alcanza si los resúmenes son cortos; si fueran largos, streaming aunque nadie mire (por el timeout). Bonus: este caso es candidato ideal a Batches API (cap. 5).

• 401 — key inválida/ausente → anthropic.AuthenticationError. No se arregla reintentando: hay que corregir la configuración.
• 429 — rate limit (demasiados requests/tokens por minuto) → anthropic.RateLimitError. Se arregla esperando (header retry-after); el SDK ya reintenta solo.
• 529 — API sobrecargada. Reintento con espera creciente.

1. Se hace historial.append({"role": "user", ...}) con la pregunta.
2. El request falla (p. ej. RateLimitError) → no hay respuesta → no se agrega mensaje de assistant.
3. El historial queda terminando en user.
4. El usuario pregunta de nuevo → otro append de user → el historial tiene dos user consecutivos.
5. El siguiente request viola la alternancia de roles → BadRequestError (400) — y ahora TODOS los turnos siguientes fallan, porque el historial quedó corrupto. El pop() deshace el paso 1 cuando el request muere, manteniendo el historial siempre válido.

Cada intercambio agrega ~450 tokens al historial (50 + 400). Entrada del turno k ≈ 100 (system) + 450(k−1) + 50. Sumando k=1..15: entrada total ≈ 15×150 + 450×(0+1+...+14) = 2,250 + 450×105 = 2,250 + 47,250 = 49,500 tokens de entrada. Salida: 15 × 400 = 6,000 tokens.

Costo: 0.0495M × $5 + 0.006M × $25 = $0.2475 + $0.15 = ~$0.40 la sesión. Observá que la entrada acumulada (47K de los 49.5K) domina — el historial reenviado es el costo real de un chat. Adelanto del cap. 5: con caching, gran parte de esa entrada repetida costaría ~10× menos.

import anthropic, pathlib

client = anthropic.Anthropic()
ok, fallos, costo = 0, 0, 0.0

for archivo in pathlib.Path("apuntes").glob("*.txt"):
    try:
        r = client.messages.create(                       # request básico
            model="claude-haiku-4-5",                     # modelo barato para tarea simple
            max_tokens=500,
            system="Resumí en 5 viñetas, en español.",    # system prompt
            messages=[{"role": "user",
                       "content": archivo.read_text()}],  # sin historial: tareas independientes
        )
        if r.stop_reason == "max_tokens":                 # detectar corte
            print(f"⚠️ {archivo.name}: resumen cortado")
        archivo.with_suffix(".resumen.txt").write_text(r.content[0].text)
        costo += (r.usage.input_tokens * 1 + r.usage.output_tokens * 5) / 1e6  # usage → costo
        ok += 1
    except anthropic.APIError as e:                       # excepción tipada; el bucle sigue
        print(f"❌ {archivo.name}: {e.message}")
        fallos += 1

print(f"Procesados: {ok} | Fallos: {fallos} | Costo: ${costo:.4f}")

Puntos clave: sin historial (los archivos no se relacionan — más barato y más simple), try/except POR archivo (un fallo no mata el lote), chequeo de stop_reason, y contabilidad con usage.

Esqueleto del guardado:

if pregunta.lower() == "guardar":
    with open("sesion.md", "w") as f:
        for m in historial:
            quien = "**Vos**" if m["role"] == "user" else "**Tutor**"
            f.write(f"{quien}: {m['content']}\n\n")
    print("[Guardado en sesion.md]\n")
    continue

Para la carga: leer el archivo, reconstruir la lista de diccionarios y arrancar con ese historial. La decisión de diseño: una sesión vieja cargada completa puede ser enorme — y desde el primer turno pagás TODO ese historial como entrada en cada request. Opciones: cargar solo los últimos N intercambios, o (mejor) pedirle al propio modelo un resumen de la sesión vieja y cargar solo el resumen como contexto inicial. Es el trade-off memoria/costo en su forma más pura.

Con Haiku: 0.008 × $1 + 0.001 × $5 = $0.008 + $0.005 = $0.013.

Pedir respuestas concisas. La instrucción "respondé en máximo 5 viñetas" o "máximo 150 palabras" reduce la parte cara de la factura sin tocar código ni arquitectura. En el system prompt de apps: "sé conciso; ampliá solo si te lo piden".

tiktoken es el tokenizador de OpenAI: parte el texto distinto que los modelos Claude, así que los conteos (y el presupuesto) quedan sistemáticamente mal. Lo correcto: client.messages.count_tokens(model=..., messages=...) — gratis, exacto y del modelo que vas a usar. Para servilleta: 1 palabra ≈ 1.3 tokens en español.

Escribir: ~1.25×. Leer: ~0.1×. Con 2 usos ya ganás: 1.25 + 0.1 = 1.35× contra 2× de mandarlo dos veces sin caché. De ahí en adelante, cada uso extra cuesta una décima en vez de uno entero.

• (a) No — latencia de milisegundos requerida.
• (b) Sí — lote masivo, nadie espera; 50% de descuento directo.
• (c) No — conversación interactiva.
• (d) Sí — hay 3 horas de margen; sobra para el batch. La pregunta clave siempre: ¿alguien está esperando en pantalla?

El caché matchea por prefijo exacto: la fecha/hora al INICIO cambia en cada request (¡incluye segundos!), así que el prefijo nunca coincide y cada request paga la escritura (1.25×) de los 80,000 tokens sin que nadie lea jamás. Arreglo: lo volátil va al final o en los mensajes — system = reglamentos estables (cacheados) primero; la fecha, si hace falta, en el mensaje del usuario o al final del system, después del bloque cacheado.

• (a) Sin caché: 25 × 60,000 × $3/M = $4.50.
• (b) Con caché: escritura 60,000 × $3.75/M = $0.225; lecturas 24 × 60,000 × $0.30/M = $0.432. Total: $0.657.
• (c) 1 − 0.657/4.50 = ~85% de ahorro en la porción cacheada.

Por consulta — Opus: 0.0003 × $5 + 0.00015 × $25 = $0.00525. Haiku: 0.0003 × $1 + 0.00015 × $5 = $0.00105.

• (a) Todo Opus: 10,000 × $0.00525 = $52.50/mes.
• (b) Mezcla: 9,000 × $0.00105 + 1,000 × $0.00525 = $9.45 + $5.25 = $14.70/mes — 72% menos. El patrón "lo barato hace el volumen, lo caro la excepción" es de los más rentables que existen. (En la práctica, el triaje mismo puede hacerlo Haiku por centavos.)

1. Revocar la key YA en console.anthropic.com (minutos cuentan).
2. Generar una nueva y actualizar la variable de entorno.
3. Revisar el uso reciente en la consola buscando consumo ajeno.
4. Asumir que fue copiada y revisar dónde más la usaste.

Borrar el archivo no sirve porque el historial de git conserva el commit viejo (y GitHub puede cachear/espejar contenido): la key sigue visible para quien sepa mirar — y los bots saben. La única muerte real de una key filtrada es la revocación.

Por sesión: caché: 1 escritura (40K × $6.25/M = $0.25) + 29 lecturas (29 × 40K × $0.5/M = $0.58) = $0.83. Entrada no cacheada: 30 × (4,000 + 60) ≈ 121,800 tokens × $5/M = $0.609. Salida: 30 × 350 = 10,500 × $25/M = $0.2625. Sesión ≈ $1.70.

Semana: 6 × $1.70 ≈ $10.20. Para contexto: sin caché, la porción de apuntes sola costaría 6 × 30 × 40K × $5/M = $36 — el caching te ahorró ~$31 en la semana. Si $10 sigue siendo mucho, las palancas restantes: ¿Sonnet alcanza? (÷1.67), ¿respuestas más cortas?, ¿historial más corto?

1. Key hardcodeada — directo a revocar y mover a ANTHROPIC_API_KEY.
2. Fable 5 para procesar documentos en lote — casi seguro Haiku o Sonnet alcanzan; diferencia de hasta 10×.
3. INSTRUCCIONES_10K_TOKENS repetidas en cada request sin caché — 2,000 × 10K = 20M tokens de entrada repetida; con cache_control en un bloque de system costaría ~10× menos.
4. Sin Batches API — es un lote sin urgencia aparente: 50% de descuento ignorado.
5. max_tokens=8000 sin justificar — si la salida esperada es un resumen corto, un techo alto invita salidas largas y caras (y no hay chequeo de stop_reason).
6. Sin manejo de errores — un 429 a mitad del lote mata el script y pierde lo procesado.
7. Sin freno de presupuesto ni contador — nadie sabrá cuánto costó hasta ver la consola.

Estimación del horror tal cual está: entrada 2,000 × 13K = 26M × $10 = $260, más salida. Bien hecho (Haiku + caché + batch): unos pocos dólares.

Respuesta personal. Autoevaluación del presupuesto: (1) las supuestos de uso son explícitos y realistas (preguntas/sesión, sesiones/semana, tamaños en tokens); (2) hay DOS cálculos completos — sin caché y con caché — con la fórmula visible, no solo resultados; (3) el ahorro se expresa en $ y en %; (4) el CSV de uso real de tu primera semana se compara contra la estimación, y la diferencia se explica (¿subestimaste el tamaño de las respuestas? ¿el historial creció más de lo previsto?). El hábito de presupuestar → medir → explicar la diferencia ES la ingeniería de costos.