Writing my first Gemini cost estimate in two columns, one for now and one for January

Give the price table a start and an end

Start by moving prices out of the code and into a file. The important part is not the amounts. It is that every row carries from and to.

{
  "currency": "USD",
  "per_tokens": 1000000,
  "rows": [
    {
      "model": "gemini-3.8-flash",
      "from": "2026-09-02", "to": "2026-12-31",
      "input": 0.75, "output": 3.75,
      "note": "introductory price"
    },
    {
      "model": "gemini-3.8-flash",
      "from": "2027-01-01", "to": null,
      "input": 1.50, "output": 7.50,
      "note": "standard price from 2027-01-01"
    },
    {
      "model": "gemini-3.7-flash",
      "from": "2026-08-13", "to": "2026-12-31",
      "input": 0.75, "output": 3.75,
      "note": "introductory price, same expiry as 3.8"
    },
    {
      "model": "gemini-3.7-flash",
      "from": "2027-01-01", "to": null,
      "input": 1.50, "output": 7.50,
      "note": "standard price from 2027-01-01"
    }
  ]
}

A to of null means "no end has been announced yet." When one is announced, you write the date in and you are done.

Look at the two rows for 3.7 Flash and you can see my misreading laid out as data. Older generation, identical expiry. Once it is a table, there is no room left for the assumption to hide in.

Keeping per_tokens outside the formula is worth the extra line, too. I once mistook a per-1M rate for a per-1K rate and estimated a month at a thousand times its real size. Units belong in the data, not in the arithmetic.

Pass the date in, rather than assuming today

Next, the script that reads the table and adds things up. The point here is that the date you are pricing against comes in from outside. Stop treating today as an implicit default and next year's shape falls out of the same code.

import json, sys
from datetime import date
 
 
def load_prices(path):
    raw = json.load(open(path, encoding="utf-8"))
    unit = raw["per_tokens"]          # per-1M rate -> per-token rate
    rows = []
    for r in raw["rows"]:
        rows.append({
            "model": r["model"],
            "start": date.fromisoformat(r["from"]),
            "end": date.fromisoformat(r["to"]) if r["to"] else date.max,
            "input": r["input"] / unit,
            "output": r["output"] / unit,
        })
    return rows
 
 
class PriceMissing(Exception):
    """No price row covers this date. Keeps us from quietly charging zero."""
 
 
def price_on(rows, model, on):
    for r in rows:
        if r["model"] == model and r["start"] <= on <= r["end"]:
            return r
    raise PriceMissing(f"{model} has no price row covering {on}")
 
 
def total(ledger, rows, on):
    per_model = {}
    for line in open(ledger, encoding="utf-8"):
        rec = json.loads(line)
        p = price_on(rows, rec["model"], on)
        cost = rec["input_tokens"] * p["input"] + rec["output_tokens"] * p["output"]
        per_model[rec["model"]] = per_model.get(rec["model"], 0.0) + cost
    return per_model
 
 
def main():
    rows = load_prices("prices.json")
    days = [date.fromisoformat(d) for d in sys.argv[1:]] or [date.today()]
    tables = {d: total("usage.jsonl", rows, d) for d in days}
    models = sorted({m for t in tables.values() for m in t})
 
    head = "model".ljust(20) + "".join(str(d).rjust(14) for d in days)
    print(head)
    print("-" * len(head))
    for m in models:
        print(m.ljust(20) + "".join(f"${tables[d].get(m, 0):.4f}".rjust(14) for d in days))
    print("-" * len(head))
    print("TOTAL".ljust(20) + "".join(f"${sum(tables[d].values()):.4f}".rjust(14) for d in days))
 
 
main()

The input, usage.jsonl, is a plain ledger with one line per day. For this article I am running it against five sample days I put together by hand.

{"day": "2026-09-01", "model": "gemini-3.8-flash", "input_tokens": 412000, "output_tokens": 38000}
{"day": "2026-09-02", "model": "gemini-3.8-flash", "input_tokens": 455000, "output_tokens": 41000}
{"day": "2026-09-03", "model": "gemini-3.7-flash", "input_tokens": 690000, "output_tokens": 12000}
{"day": "2026-09-04", "model": "gemini-3.8-flash", "input_tokens": 398000, "output_tokens": 36000}
{"day": "2026-09-05", "model": "gemini-3.7-flash", "input_tokens": 705000, "output_tokens": 11000}

Two columns end the argument on the spot

Pass two dates: today, and any day after the change.

python3 estimate.py 2026-09-08 2027-01-15

Running it here gave me this.

model                   2026-09-08    2027-01-15
------------------------------------------------
gemini-3.7-flash           $1.1325       $2.2650
gemini-3.8-flash           $1.3800       $2.7600
------------------------------------------------
TOTAL                      $2.5125       $5.0250

The ledger is a sample, so the amounts themselves mean nothing. What means something is the shape. The 3.7 Flash row grows by the same factor as the 3.8 Flash row. Staying put is not shelter — and you see that as a table rather than as an argument.

Since I started laying it out this way, I spend far less time agonizing over which generation to run. The gap between the two columns is the same either way, so the comparison moves to where it belongs: tokens per job, and how often a job has to be redone.

Output tokens cost five times what input tokens cost. Carrying that ratio around in your head changes how you feel about designs that produce long answers. In my own work, keeping outputs short paid better than dropping down a model tier.

When the table has a hole, don't quietly bill zero

The real danger in a first estimator is not that the calculation fails. It is that it succeeds with the wrong number.

Suppose you forget the 2027 row for 3.7 Flash. A typical implementation finds no matching rate, contributes zero, and prints a total that looks perfectly plausible. An estimate that came out cheap rarely gets questioned, and you find out when the invoice arrives.

The code above raises instead. Delete one row and run it:

__main__.PriceMissing: gemini-3.7-flash has no price row covering 2027-01-15

It exits with status 1, so anything you have on a schedule stops right there.

I have written the swallow-it-quietly version more than once, because stopping felt inconvenient. I have reversed that rule since. Anything missing that touches money gets to make noise.

Feed it the tokens you actually spent

Everything so far ran on a sample ledger. The last piece is an opening for the real numbers: take the usage metadata off the response and append it.

import json
from datetime import date
from google import genai
 
client = genai.Client()          # reads GEMINI_API_KEY from the environment
MODEL = "gemini-3.8-flash"       # keep the model ID in exactly one place
 
 
def ask(prompt: str, ledger: str = "usage.jsonl") -> str:
    interaction = client.interactions.create(model=MODEL, input=prompt)
 
    usage = getattr(interaction, "usage", None)
    if usage is None:
        # If it isn't there, record that fact rather than guessing a value
        record = {"day": str(date.today()), "model": MODEL, "usage": "missing"}
    else:
        record = {
            "day": str(date.today()),
            "model": MODEL,
            "input_tokens": getattr(usage, "input_tokens", 0),
            "output_tokens": getattr(usage, "output_tokens", 0),
        }
 
    with open(ledger, "a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")
 
    return interaction.output_text

Not writing a zero when the counts are unavailable is a small thing that earns its keep. A zero reads as "spent nothing," and later you cannot tell the two apart. Record the absence instead, and when you reconcile at month end you can see exactly where the counting stopped.

If you want the longer story of why a pre-flight estimate and the eventual bill diverge, I wrote that up in Why count_tokens Lies: 5 Reasons Your Gemini API Bill Is Higher Than You Estimated. Logging the reported usage from each response, as above, keeps most of that gap from appearing at all.

What is left to do before the date arrives

With the deadline sitting on the calendar, the lever you hold is not the rate. It is the volume.

The docs give you two things to work with. Gemini 3.8 Flash is designed to spend more tokens on long, difficult, multi-step work, and you can lower the reasoning effort for everyday tasks. And Gemini 3.7 Flash remains fully supported.

Neither "newer is always better" nor "older is always cheaper" survives contact with that. For short-answer work such as classification I lean on lower effort settings, and I reserve careful attention for the jobs where the output itself runs long — summaries, first-pass translations.

If you assume the migration is a one-line model string swap, this is where you trip. For the same reason I moved prices into a file, I keep the model ID in one place — so the blast radius of a swap is visible at a glance.

There is one thing worth doing today. Open whichever sheet or script holds your estimate, and add from and to next to the rate. The moment your numbers know when they are valid, January stops being a day you get surprised and becomes a day you simply check.

Thank you for following along with a fairly plain little script. I am still re-reading my own ledger at the end of every month.