Keep a small AI budget: Sonnet 5.5 for coding, Opus 5.5 for judgment

Your weekend agent is waiting, your budget is small, and the idea should not outlive the weekend. Split the work by risk. Use a two-tier rule. Most side projects stay side projects, and that is fine. A small, working slice beats a grand plan that never gets finished. Keep the budget in view.

• Scoped, testable coding: Sonnet 5.5.
• Judgment, architecture, irreversible decisions: Opus 5.5.
• Cache reads cost $0.20 on both models.

Put Sonnet 5.5 on scoped, testable work

Name the task before you start. A weekend agent works best when the job has a boundary: which file it may touch, which behavior should change, and what should stay untouched. Say what success looks like before the model starts. When the answer is vague, the task is too big. Paste only the files the task needs, and leave out the whole repo unless the task truly spans it. Done is a task you could explain in a short note. A boundary is the cheapest feature.

Choose the lower-rate model for scoped, testable coding. Claude Sonnet 5.5 became available on 28 September. Its input and output rates are half those of Claude Opus 5.5, and it kept Sonnet 5's price. Claude Sonnet 5.5 runs 30 percent faster and 30 percent cheaper than Claude Sonnet 5. The price gap is the budget rule. A tight stop condition keeps the cost predictable: a clear file, a clear test, and a clear stop.

Write the task so the result can be checked. Give it a feature, a bug, or a refactor, and ask for a test or a command that proves the change. When the model changes more than you asked, stop and narrow the prompt. The result should be a diff you can run, not a plan you have to trust. Do not treat a confident answer as proof. The check is the proof. If the test passes, the cheap model has earned the next small task. If it fails, send it back with a question, not a guess. A passing test gives you a green check, a clean command, or a short note that says what still needs you.

Save Opus 5.5 for calls you cannot undo

Escalate only when the next step is hard to reverse. Save the higher-rate model for architecture, permissions, migrations, and other irreversible calls. Ask it for a decision, not a long answer. Give it the constraints, the risk, and the options you already considered. A useful escalation gives you a short recommendation you can act on, not a long essay.

Sonnet 5.5 can propose, but you decide whether to delete a table, change permissions, or ship a migration. On Terminal-Bench, a coding benchmark, Sonnet 5.5 scored 43.0 percent at High effort, below 70.6 percent. Use the gap to keep the hard, messy, terminal-heavy work in your hands or in the stronger model. Your judgment is the final check.

Stretch long runs with cache reads and a clean stop

Refill context with cache reads instead of restarting. Long sessions get cheaper when the model can reuse what it already read. Keep a short project note with the stack, the test command, and the rules you care about, and reuse it across sessions. The file can be short. Spend the saved headroom on retries, not on a bigger scope. If a scoped task fails, rerun it with a tighter prompt before you touch the expensive model. For an overnight run, pair that scoped task with a longer context refill, without raising spend, and say continue from the last passing test rather than pasting every file again.

Write down the next step. A side project does not need a roadmap, but it does need a next step. A clear next step makes the pause feel useful, not lost. Protect the hours. A weekend builder has a hard limit, and the model should respect it. Stop when the task is clear enough to resume, even if it is not finished. The stop can be a saved state, not a confusing state.