Budgeting Quota So Parallel Agents in Antigravity 2.0 Don't Run Dry

Estimate the cost of a single agent run

Exact token counts are hard to pull from 2.0, but estimates are doable. Here is the formula I use.

# estimate_cost.py — approximate the "units" one agent run consumes
# Not a billing figure; an internal index to normalize relative weight
def estimate_units(task):
    # input scale: files read times average line count
    input_scale = task["files_read"] * task["avg_lines"]
    # each tool call re-runs the model, so weight it
    tool_overhead = task["tool_calls"] * 1.4
    # output scale: generated code and explanation
    output_scale = task["output_lines"] * 1.2
 
    units = (input_scale / 100) + tool_overhead + (output_scale / 50)
    return round(units, 1)
 
heavy = estimate_units({"files_read": 40, "avg_lines": 180,
                        "tool_calls": 25, "output_lines": 300})
light = estimate_units({"files_read": 2, "avg_lines": 60,
                       "tool_calls": 3, "output_lines": 40})
print(f"heavy={heavy}  light={light}")
# heavy=114.4  light=6.4 → a heavy run is roughly 18x a light one

This formula doesn't aim to hit the exact bill. Its purpose is to lock in the relative sense that "one heavy run equals about 18 light ones" as a number. Once you internalize that ratio, you can budget your day in a shared "unit."

The daily budget I actually run looks roughly like this.

Time-of-day budget

• Morning (deep work): up to 40% of the day's total. Put heavy runs here.
• Early afternoon (real implementation): hold 40% in reserve. The block you must never cut.
• Evening (finishing, light work): the remaining 20%, mostly light runs.

Three heavy runs in the morning blow past that 40%. The single biggest lever for me was deciding in advance: "no more than two heavy runs before noon."

Find the Pro-vs-Ultra break-even from task count

As of June 2026, your ceiling differs sharply between AI Pro ($20/mo) and AI Ultra ($100/mo, roughly 5x the Pro limit). The practical way to choose isn't by price — it's by working backwards from how many heavy tasks you run per day.

# plan_breakeven.py — recommend a plan from daily heavy-task count
PRO_DAILY_HEAVY = 4      # heavy runs Pro sustains comfortably
ULTRA_MULTIPLIER = 5     # Ultra is about 5x the ceiling
 
def recommend_plan(daily_heavy_tasks):
    ultra_daily = PRO_DAILY_HEAVY * ULTRA_MULTIPLIER
    if daily_heavy_tasks <= PRO_DAILY_HEAVY:
        return "Pro ($20) is enough; you rarely hit the ceiling"
    elif daily_heavy_tasks <= ultra_daily:
        return "Ultra ($100) recommended; Pro dries up by afternoon"
    else:
        return "Even Ultra falls short; split and lighten tasks first"
 
for n in (3, 8, 25):
    print(f"{n} heavy/day -> {recommend_plan(n)}")

The point I want to stress: upgrading to Ultra is not a fix. If you're throwing 25 heavy tasks a day, that's not a plan problem — it's a design problem of slicing tasks too fine or re-reading full context every time. Before moving to Ultra, I recommend first checking whether each heavy task can be split into two medium ones. A plan change is the last resort.

If you can't see the quota, keep counting it yourself

Since 2.0 hides the remaining balance, you have to estimate it. I wrap every agent launch in a thin layer that adds the estimated units to a local counter.

# quota_tracker.py — track cumulative daily use on a JST day key
import json, datetime, pathlib
 
LOG = pathlib.Path.home() / ".antigravity_quota.json"
DAILY_BUDGET = 400  # units; calibrated from my own ceiling-hit days
 
def today_key():
    jst = datetime.timezone(datetime.timedelta(hours=9))
    return datetime.datetime.now(jst).strftime("%Y-%m-%d")
 
def add(units):
    data = json.loads(LOG.read_text()) if LOG.exists() else {}
    key = today_key()
    data[key] = round(data.get(key, 0) + units, 1)
    LOG.write_text(json.dumps(data))
    remaining = DAILY_BUDGET - data[key]
    status = "low" if remaining < 80 else "ok"
    print(f"used={data[key]} / {DAILY_BUDGET}  remaining={remaining}  {status}")
    return remaining
 
add(114.4)  # call right after a heavy run

Your first DAILY_BUDGET value can be a guess. Record the cumulative units on days you actually hit the ceiling, then nudge the threshold just below that. Within two or three weeks you'll see the line where things get risky. What matters in production isn't precision — it's getting a warning before you run dry.

A gotcha: using date raw aggregates in UTC, so late-night work in Japan gets added to the previous day. Always build the day key in JST. I tripped on this repeatedly in my own automated aggregation, so I strongly recommend making the timezone explicit from the start.

Budgeting is fixing priorities, not going without

"Quota management" sounds like cutting back, but what I actually do is fix priorities first thing in the morning. Always reserve the afternoon's implementation block, cap heavy runs at two before noon, and when in doubt downgrade to light. Holding just those three lines, I almost never lose a day to the ceiling anymore.

Parallel agents are magically fast, but run them without a plan and you'll be out of cards during your most important hours. Calibrating the estimate, the counter, and the break-even to your own workflow is the quiet, reliable foundation for using 2.0 hard every day. If you've been losing your afternoons too, I hope this helps.