Keep your side project's model bill near zero after GPT-6 Astra

You have a small app, a short evening, and a model bill you want to keep near zero. GPT-6 Astra's standard API price is $10 per million input tokens and $50 per million output tokens. Cached input tokens cost $1 per million. OpenAI began rolling out GPT-6 Astra to the first wave of users on September 3, 2026. Most side projects stay side projects, and that is fine. Keep it small by routing most traffic to cheap tiers and using the new model only for the hard problem cheaper models cannot finish.

The price gap is the routing problem

The new standard price is about 2.5 times GPT-5.6 Sol's $4 per million input and $20 per million output. That gap is the reason to route. A stable prefix can turn repeated context into a much cheaper path. Batch paths are for work that can wait, such as reports, summaries, or nightly jobs that do not need an instant answer. When ordinary traffic moves off the premium model, the bill stops being driven by the most expensive tier, and the cheap model stops being overworked.

Build the three-tier ladder before the weekend

Write the routing rule before you ship. Put the decision in code, not in a note. A working version has a function that takes the request type and returns the model tier before the call is made. The rule should be easy to change when a new price point lands.

• Default to the cheapest capable model.
• Send repeated or non-urgent volume to cached or batch paths.
• Reserve the frontier model for one hard-problem Friday task.

Start every request on the lowest tier that passes your test set. For a small app, that may be a model that handles classification, extraction, or short answers well enough. If the cheap model fails on a small set of examples, fix the prompt or the task before reaching for the premium model. A working version has ordinary traffic running on the cheap model with a clear failure list you can review.

Put repeated context in a stable prefix so the cache can reuse it. If the prefix changes often, split it into a stable part and a variable part. Send non-urgent work through batch when your product can wait for results. Aim for a dashboard where most tokens are cached or batched, and only fresh, user-facing requests pay regular input rates. That dashboard is the first check before the weekend.

Choose the task that cheaper models keep missing, such as a long reasoning chain, a tricky edge case, or a user-facing answer that needs more judgment. Run that task on GPT-6 Astra and compare the output to the cheaper model. Keep the feature narrow, so the expensive model appears only when the hard problem is chosen.

GPT-6 Astra's fast mode can run at up to twice the standard speed at twice the standard price. The trap is treating speed as a default for every request. Turn it on only for the user-facing path where latency hurts, and leave the rest on the usual path. Set a flag that is off by default and a spend alarm that fires before the bill surprises you.

Make the week's spend visible

Log which model answered each request. Record the model tier, the request type, and whether the response was cached, batched, or fresh. Add a note for the hard problem when the frontier model is used. The log should show a simple line that tells you which path handled the work and why.

Review the bill at the end of the week. Look for the path that spent the most and ask whether it should have been there. If the frontier model handled ordinary traffic, tighten the routing rule. If the cheap model failed too often, improve the prompt or move the task to a different tier. Finish with a short list of changes for the next weekend and a bill you can explain.