Budget Your Weekend AI Agent Before the January Price Step

You are building a small agent on weekends, and the model invoice is the one cost you can actually control. The tempting move is to build on the launch price and hope it stays low. The safer move is to treat the intro rate as a dated experiment, then re-baseline before the price step changes your architecture.

Gemini 3.7 Flash launched on August 13, 2026, about three weeks after the 3.6 Flash release. Its introductory price is $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026. The scheduled rate is $1.50 per million input tokens and $7.50 per million output tokens on January 1, 2027. The budget problem is the date: the model you can afford this month may cost more next month.

Plan the window, not the sticker

Do not plan the project around a temporary rate. Plan around the window. The launch price is useful for testing, not for planning a permanent cost. If your agent is a weekend tool, the budget should survive the step without a rewrite.

Start with the numbers you already have. Your token volume is the variable, the model price is the multiplier, and the expiry date is the deadline. When those are on the page, the architecture starts to make sense.

Put the price step into the budget first

• Compute the intro-window cost. Multiply your expected monthly input tokens by the intro input rate, and your expected monthly output tokens by the intro output rate. Add them. The result is a short note with the monthly cost at the launch rate.
• Recompute at the post-expiry rate. Use the same token volumes, but swap in the higher input and output rates. You end with a post-expiry monthly figure that shows what the same workload will cost after the step.
• Set a re-baseline date. Pick a date before the price step where you will look at real usage, not guesses. The calendar entry says: compare the actual invoice to the budget lines.
• Run a workload eval before the design becomes fixed. Test the model on your actual prompts, tools, and mistakes. You get a small set of examples where you can say the agent works, the agent is too slow, or the agent is too expensive for the job.

The warning sits in the recompute step. People go wrong when they let the lower sticker price decide the design. A cheaper rate can still produce a larger invoice if the agent needs more retries, more context, or more output. The sticker is the starting price, not the total cost.

Let your workload choose the model

Benchmarks can point you in a direction, but they do not know your agent. The DeepSWE v1.1 score for the model is 65.3%. The AutomationBench score for the model is 30.4%, compared with 17.0% for 3.6 Flash. Those numbers are useful, but your eval is the one that matters.

Gregor Zunic, CTO of Browser Use, put the 3.7 Flash invoice 35% below the 3.6 Flash invoice under the same sticker price. That detail should make you pause. The same label can hide a different invoice. If your workload leans on tools or fails often, the model's behavior may matter more than the headline rate.

Context limits shape the design too. The model supports a 1 million-token context window and can return up to 64,000 output tokens per request. If your agent needs long transcripts, large documents, or multi-step tool traces, that capacity can reduce the need for extra summarization. If it does not, do not pay for capacity you will not use.

Re-baseline before the price step changes the math

When the re-baseline date arrives, make the decision with your own data. If the post-expiry cost is still small, keep the model and move on. If the step pushes the invoice past your weekend budget, change the architecture before you change the model. Smaller prompts, tighter tools, fewer retries, and a cheaper fallback can all beat a bigger model.

Keep the scope small enough that the budget stays honest. A weekend agent needs a note, a test, and a date, not a long review. When the price step comes, you will have the invoice, the test results, and the decision in front of you.