Mantén un presupuesto pequeño de IA: Sonnet 5.5 para código, Opus 5.5 para decisiones

Tu agente de fin de semana te espera, tu presupuesto es pequeño y la idea no debería sobrevivir al fin de semana. Divide el trabajo por nivel de riesgo. Usa una regla de dos niveles. La mayoría de los proyectos secundarios se quedan como proyectos secundarios, y está bien. Un trozo pequeño que funciona vale más que un gran plan que nunca se termina. Mantén el presupuesto a la vista.

• Código acotado y testeable: Sonnet 5.5.
• Juicio, arquitectura, decisiones irreversibles: Opus 5.5.
• Las lecturas de caché cuestan $0.20 en ambos modelos.

Usa Sonnet 5.5 para trabajo acotado y testeable

Define la tarea antes de empezar. Un agente de fin de semana rinde mejor cuando el trabajo tiene un límite: qué archivo puede tocar, qué comportamiento debe cambiar y qué debe quedar intacto. Di qué se ve el éxito antes de que el modelo empiece. Si la respuesta es vaga, la tarea es demasiado grande. Pega solo los archivos que la tarea necesita y deja fuera el repo completo a menos que la tarea realmente lo abarque. Hecho es una tarea que podrías explicar en una nota corta. Un límite es la función más barata.

Elige el modelo de menor tarifa para código acotado y testeable. Claude Sonnet 5.5 estuvo disponible a partir del 28 de septiembre. Sus tarifas de entrada y salida son la mitad de las de Claude Opus 5.5, y mantuvo el precio de Sonnet 5. Claude Sonnet 5.5 es 30 por ciento más rápido y 30 por ciento más barato que Claude Sonnet 5. La diferencia de precio es la regla de presupuesto. Una condición de parada estricta mantiene el costo predecible: un archivo claro, una prueba clara y una parada clara.

Redacta la tarea de modo que el resultado pueda verificarse. Dale una funcionalidad, un bug o un refactor, y pide una prueba o un comando que demuestre el cambio. Cuando el modelo cambie más de lo que pediste, detente y acota el prompt. El resultado debe ser un diff que puedas ejecutar, no un plan en el que tengas que confiar. No trates una respuesta segura como prueba. La verificación es la prueba. Si la prueba pasa, el modelo barato ha ganado la siguiente tarea pequeña. Si falla, devuélvela con una pregunta, no con una suposición. Una prueba superada te da una marca verde, un comando limpio o una nota corta que dice qué aún te necesita.

Reserva Opus 5.5 para decisiones que no puedes deshacer

Escala solo cuando el siguiente paso sea difícil de revertir. Reserva el modelo de mayor tarifa para arquitectura, permisos, migraciones y otras decisiones irreversibles. Pídele una decisión, no una respuesta larga. Dale las restricciones, el riesgo y las opciones que ya consideraste. Una escalada útil te da una recomendación corta sobre la que puedes actuar, no un ensayo largo.

Sonnet 5.5 puede proponer, pero tú decides si borrar una tabla, cambiar permisos o desplegar una migración. En Terminal-Bench, un benchmark de código, Sonnet 5.5 obtuvo 43.0 por ciento con esfuerzo High, por debajo del 70.6 por ciento. Usa esa brecha para mantener el trabajo difícil, desordenado y pesado en terminal en tus manos o en el modelo más potente. Tu juicio es la verificación final.

Alarga sesiones largas con lecturas de caché y una parada limpia

Recarga el contexto con lecturas de caché en lugar de reiniciar. Las sesiones largas se abaratan cuando el modelo puede reutilizar lo que ya leyó. Mantén una nota corta del proyecto con el stack, el comando de prueba y las reglas que te importan, y reutilízala entre sesiones. El archivo puede ser corto. Gasta el margen ahorrado en reintentos, no en un alcance mayor. Si una tarea acotada falla, vuelve a ejecutarla con un prompt más estricto antes de tocar el modelo caro. Para una ejecución nocturna, combina esa tarea acotada con una recarga de contexto más larga, sin aumentar el gasto, y di que continúe desde la última prueba superada en lugar de pegar todos los archivos de nuevo.

Anota el siguiente paso. Un proyecto secundario no necesita un roadmap, pero sí necesita un siguiente paso. Un siguiente paso claro hace que la pausa se sienta útil, no perdida. Protege las horas. Un desarrollador de fin de semana tiene un límite duro, y el modelo debería respetarlo. Detente cuando la tarea esté lo suficientemente clara para retomar, aunque no esté terminada. La parada puede ser un estado guardado, no un estado confuso.