Cutting Antigravity Agent Costs in Half Without Sacrificing Quality — A Practical Optimization Playbook
Running Antigravity agents full-time can drive your API bill up fast in the first month. Across four sub-agents in my own production setup, I cut monthly token consumption almost in half while keeping quality identical. Here is the before/after breakdown, the model-routing break-even, and the mistakes I made along the way.
When you run Antigravity agents every day, the end of the first month can be unpleasant. As an indie developer I keep four sub-agents running for my own side projects, and early on my monthly API bill came in at roughly 3x what I had projected. I still remember my fingertips going a little cold when I saw the number.
Over the following months I cut token consumption almost in half while keeping output quality identical. Below is the sequence of optimizations, ordered by how much each one actually moved the needle, together with the failures and the measured numbers. The specifics lean on Antigravity, but the ideas port to any agent framework.
Measure First — Optimization Starts With Observation
The instinct is to shorten prompts. But shortening without measurement usually just degrades quality without saving much. In my experience, the correct move is to change no code for the first two weeks and spend that time building an observation layer.
At minimum, instrument:
input_tokens and output_tokens per agent/tool call
Cache hit rate (if you use prompt caching)
Tool execution time and success rate
How many times an agent re-invokes itself for a single user input
The fourth one matters most. In Antigravity's multi-step execution, an agent re-reads its own prior output as it proceeds, so one extra loop can double consumption. In my setup that loop count averaged over four for a while, and that was the real cost sink.
Beyond Antigravity's built-in logs, I run a daily report from CloudWatch Logs Insights:
fields @timestamp, agent_id, step_count, input_tokens, output_tokens| stats sum(input_tokens) as total_in, sum(output_tokens) as total_out, avg(step_count) as avg_steps by agent_id| sort total_in desc
This makes it obvious at a glance which agent is eating most of the budget. Only once this is in place do I start optimizing.
The Before/After Breakdown — Where the Savings Came From
A breakdown is easier to reproduce than the word "halved," so here is the monthly split for my environment (four sub-agents combined, approximate). Absolute amounts shift with model pricing, so read the ratios.
Cost line
Before (share)
After (share)
What fixed it
Re-sending the fixed system prompt
38%
7%
prompt caching
Excess context history
27%
11%
context pruning
Blanket reliance on the top model
24%
13%
model routing
Wasted self-loops
11%
4%
step cap + summarization
If the total was 100 before, it landed around 35 after — roughly a 55% reduction in dollar terms. The point worth noticing: the single biggest line was the fixed text I was re-sending every call. So the first thing to attack was not smarter model selection, but the duplicated strings I kept shipping.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦The optimization steps ordered by actual impact: prompt structure, caching, context pruning, and model routing — each with measured numbers
✦The before/after cost breakdown that halved my monthly bill, plus a model-routing break-even matrix for when to reach for the top-tier model
✦The changes that felt obviously right but made things worse, and the measurement data that revealed why
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
Just moving the instructions and tool list to the front and caching them makes the cached portion cost about one-tenth on the second and later calls for the same user input. In workflows where the same Antigravity agent fires repeatedly, this alone cut my monthly bill by about 30%.
A common mistake is inserting a timestamp or dynamic date inside the fixed block. That shifts the cache key every time and kills the effect. I added a small CI check that verifies the fixed block is byte-for-byte identical to last time:
import hashlib, json, sysdef block_hash(text: str) -> str: return hashlib.sha256(text.encode("utf-8")).hexdigest()with open("prompt_fixed_block.txt", encoding="utf-8") as f: current = block_hash(f.read())with open("prompt_fixed_block.lock", encoding="utf-8") as f: expected = json.load(f)["hash"]if current != expected: print("Fixed block changed. Caching will be invalidated.") print("If intentional, update prompt_fixed_block.lock.") sys.exit(1)print("Fixed block matches. Cache continues.")
Since adding this, I no longer get the quiet cost creep of "a dynamic value slipped into the fixed block and caching silently stopped." The worst failures are the ones where a working optimization gets disabled next month without anyone noticing.
Impact #2 — Context Pruning
Next was pruning the context each agent reads. Many people over-stuff context on the "bigger is safer" theory. I did too — I initially passed the full conversation history.
But the observation data showed the agent actually referenced only the last three turns plus two or three items directly tied to the current task. The rest was just inflating input tokens.
My pruning rules:
Always include the last three turns
Before that, include only turns matching the nouns of this task
When inclusion is hard to judge, have a summarization agent compress it to one sentence
That summarization agent runs on a cheap, lower-tier model. You might worry that inserting it adds latency, but Antigravity's step execution is asynchronous to begin with, so a serial insertion barely registers. Pruning lightened input tokens by about 40% on average, and as a bonus it reduced wrong answers caused by irrelevant history dragging the model off course. Trimming context can help accuracy, not just cost.
Impact #3 — Model Routing and Break-Even
Third is routing tasks to different models. In my experience, running every task on one top-tier model is overkill for a solo developer.
My current routing policy:
Task type
Model tier
Decision basis (cost of being wrong)
Design calls, code review, incident response
Top
Weeks of rework. Do not cut corners here
Extraction, summarization, formatting
Mid
Minor errors you catch by eye
Log classification, tagging, keyword extraction
Low
Fixable later in a batch
Antigravity lets you set the model per sub-agent, so this routing is straightforward. The deciding factor is the blast radius of a mistake. Get a design call wrong and you lose weeks; get a tag wrong and you fix it later.
Here is the break-even I keep in mind. If the top and bottom tiers differ roughly 10x in price, then only tasks where correcting a low-tier error costs more than ten top-tier runs are worth sending to the top model. I hold this "rule of ten," start uncertain tasks on the low tier, and bump them up one step only if accuracy falls short. Start at the top and you rarely find the discipline to move down.
What Didn't Work, and What I Regretted
Conversely, these were weak or actively harmful:
Switching prompts from Japanese to English: token counts drop, but my domain terms were Japanese, so translation drift degraded quality. It might help for bilingual, formulaic work
Setting max_tokens too low: forcing short output made agents cut off mid-task and re-invoke, raising cost in the end
Merging multiple tools into one: I figured fewer tools meant fewer schema tokens, but the merged tool's call prompt got complex and input tokens actually rose
Every one of these "felt right" intuitively, and I only caught the reversal by measuring. It drove home how much measurement has to come first.
Ongoing Improvement and Alerting
Cost optimization is not one-and-done. Weekly I check:
Last week's top three agents by token consumption (vs. prior week)
Change in cache hit rate
The trend in average cost per user request
To make unattended operation viable, you need not just a human eye each week but an automated way to notice when a threshold is crossed. Here are the alert thresholds I use:
Metric
Alert threshold
Likely cause
Cache hit rate
Drop of 20%+ vs. prior week
Dynamic value in the fixed block
Average step count
Over 4 for one agent
Wasted self-loops
Avg cost per request
Rising two weeks straight
Accumulated prompt additions
The third metric is the most important signal of service health. Total cost rising as users grow is healthy; cost per request rising means either design decay or a pile-up of prompt additions. I prevent the latter with review culture. Reviewing with "every line added to the prompt adds n input tokens" in mind cuts unnecessary additions dramatically.
The Real Asset You Keep
After a month of cost work, what remains is worth more than the money saved: an understanding of exactly where, on what, and how much each of your agents spends.
With that understanding, you can estimate up front that "adding a feature here raises cost by n." Cost optimization looks like accounting on the surface, but it is really a process for gaining a deep understanding of your agent design.
If you run Antigravity agents and your bill feels off, start with two weeks of observation. Rewriting code can wait. I am still tuning mine, but once the numbers become visible, operating the system itself becomes a little more enjoyable. Thank you for reading.
Share
Thank You for Reading
Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.