Gemini 4 Carbon Doubles in Price on December 1: Estimating One Antigravity Session from Cache Ratio and Thinking Level

The evening I installed v2.31.2, I opened the model picker and found Gemini 4 Carbon sitting there in three flavors: low, medium, and high. It only shows up when you sign in with Google Cloud credentials. I wanted to try it right away, and at the same moment I could already picture the Pay-As-You-Go invoice.

The reason is simple. Carbon's API price is currently introductory, and from December 1 both input and output rates double. I use Antigravity to review multilingual store descriptions for my wallpaper apps and to chase down bugs on my own website, so picking "high" every time without knowing what a session costs felt like a quiet way to get a stomachache.

So I split my typical work into two kinds of sessions and wrote a small script that turns token counts into dollars. Here is the short version up front: the cache ratio and the thinking level move the bill more than the price increase itself.

The facts first — what changes and what doesn't

This is what I could confirm from official sources as of November 13, 2026.

The primary sources are the Antigravity changelog and the Gemini 4 Carbon availability announcement. The Google Cloud pricing page also lists slightly different rates for non-global endpoints, and reads as if the introductory discount is applied as a credit back on spend. If your billing report first shows the pre-credit amount, that may be why — worth knowing before you panic.

Subscription plans (Pro, Ultra) are a separate question with their own quotas. I wrote up how I think about those in Antigravity pricing and usage.

The script — describing one session with four numbers

The problem this solves: "If I run this task on Carbon, what does it cost in November, and what will it cost in December?" — without punching a calculator. It takes four inputs: input tokens, output tokens, thinking tokens, and the share of input that hits the cache.

#!/usr/bin/env python3
"""Estimate a Gemini 4 Carbon session at introductory and standard prices."""
import argparse
 
# USD per 1M tokens (public figures as of 2026-11-13; re-check before relying on them)
PRICES = {
    "intro":    {"input": 2.00, "output": 10.00},   # through 2026-11-30
    "standard": {"input": 4.00, "output": 20.00},   # from 2026-12-01
}
CACHE_DISCOUNT = 0.95  # cached input is 95% off the input rate
 
def session_cost(p, input_tok, output_tok, thinking_tok, cache_ratio):
    cached = input_tok * cache_ratio
    fresh = input_tok - cached
    cost_in = (fresh + cached * (1 - CACHE_DISCOUNT)) * p["input"] / 1e6
    # thinking tokens count as output
    cost_out = (output_tok + thinking_tok) * p["output"] / 1e6
    return cost_in + cost_out
 
def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--input", type=int, required=True, help="total input tokens per session")
    ap.add_argument("--output", type=int, required=True, help="total output tokens per session")
    ap.add_argument("--thinking", type=int, default=0, help="total thinking tokens")
    ap.add_argument("--cache", type=float, default=0.0, help="share of input served from cache, 0-1")
    ap.add_argument("--per-month", type=int, default=20, help="sessions per month")
    a = ap.parse_args()
    for name, p in PRICES.items():
        one = session_cost(p, a.input, a.output, a.thinking, a.cache)
        print(f"{name:9s} 1回 ${one:6.3f}  月{a.per_month}回 ${one * a.per_month:7.2f}")
 
if __name__ == "__main__":
    main()

Why write it this way? An agent session isn't one round trip. It's many round trips that re-read the same files. Input tokens pile up with every turn, and most of that pile is identical to the previous turn — exactly the part that can be cached. Staring at a price table hides that "read the same thing again" structure.

Thinking tokens get their own argument for the same reason. The difference between low, medium, and high shows up on the invoice almost entirely as this one number. (The output labels are in Japanese because I run it as-is; "1回" is per session and "月N回" is per month.)

Two sessions, estimated — a short fix and a long investigation

The token counts below are placeholders I picked by picturing how long my sessions usually run. They are not measurements, so please swap in numbers from your own billing report.

• Session A: a short fix for one layout glitch on my site. 60k input, 4k output, 6k thinking tokens, 40 times a month
• Session B: a long sweep across multilingual store descriptions to find inconsistencies. 900k input, 30k output, 60k thinking tokens, 8 times a month

Every number in the table is the script's own output. Session B at 70% cache, for example:

python3 carbon_cost.py --input 900000 --output 30000 --thinking 60000 --cache 0.7 --per-month 8
# intro     1回 $ 1.503  月8回 $  12.02
# standard  1回 $ 3.006  月8回 $  24.05

At first I only looked at the $2 input rate and thought, "Even long investigations will be cheap." But in Session B, caching shrinks the input charge to roughly a third, and tripling the thinking budget wipes out almost all of that savings. At December's standard price with 70% cache, Session B lands close to what it costs today at the introductory price with no cache at all. The increase turned out to be something usage habits can absorb — or throw away.

Where the increase can be absorbed, and where it can't

Here is where I drew my lines after running the numbers.

Long sessions that keep re-reading the same context absorb it well. Work like Session B, where a large set of files stays open across many turns, benefits most from caching. Even with doubled rates, the monthly increase stays modest. Restarting the conversation over and over throws that benefit away.

Many short fixes absorb it poorly. Session A is small, and less of it lands in the cache, so the doubled rate shows up almost one-to-one. This is where routing to a lighter model has the most room.

Choose "high" by the kind of task. For an investigation where you don't yet know the cause, high earns its keep. For a fix with a known procedure, high mostly adds thinking tokens and dollars. I've written more about picking effort levels in When a Fast Model Feels Slow, Look at Reasoning Effort Before Switching Models.

Google sets the rate; I set the cache ratio and the thinking level. So on the day prices change, I look at the two numbers I can actually move first.

Replacing the placeholders with your own numbers

Placeholders aren't enough to decide anything, so I'd suggest grabbing real values before November ends.

1. Run one ordinary task on Carbon.
2. In the Google Cloud console billing report, group the project's usage by SKU.
3. Read off that day's input, cached input, and output usage.
4. Plug them into --input, --output, and --cache, and set --thinking to 0, assuming thinking is already included in output.
5. Multiply by your monthly session count to see December and beyond.

Step 4 sets thinking to 0 because the billing report most likely counts thinking tokens together with output. That's the one place it's easy to double-count.

Billing data lags a bit, so checking the day after the session has worked well for me. Once you have real figures, you can decide — on the table, not by feel — whether Carbon stays on your short tasks, your long ones, or both.

If you want to pin down the threshold for sending short tasks to a lighter model, I measured that in detail in Half My Tasks Went to Pro — and So Did Only 61% of the Tokens. For today, though, one real session's numbers are the best place to start.