Mastering Agent Optimization & Subagents

In our previous posts, we covered the shift to agent-based development and the architectural hurdles we faced along the way. Today, we are diving into the “meta-game” of AI coding: Agent Optimization.

The goal of this post is purely educational. If you are considering adopting agent-based development, I want to share the best practices and hard-learned lessons we discovered so you can avoid the same costly pitfalls.

The $10 Shock: The Drive for Optimization

When you rely heavily on LLMs to write your codebase, your most valuable resource isn’t CPU time or memory - it’s the context window. I learned this the hard way.

Initially, I hit the free tier limits quickly, so I decided to add a credit card to Google AI Studio for a pay-as-you-go API key. During my first major run, I was shocked to see my usage skyrocket to 15 million input tokens and 600k output tokens incredibly fast. I burnt through $10 in a flash.

To figure out what was going wrong, I used the /context command in the Antigravity CLI. It revealed that our initial requests were starting at around 50,000 tokens. From there, it just kept ballooning exponentially because of how subagents were spawned - each subagent was inheriting this massive, unoptimized global context state.

This financial shock was the main driver that forced me to get serious about optimizing my flow.

The Claude Code Evaluation

Before tearing down my setup, I wanted a baseline. I decided to pay the $20/month fee for Claude Code just to evaluate if a dedicated, paid tool would magically use less context.

To run a fair test, I created harness-agnostic directive files (AGENTS.md and CLAUDE.md) so I could evaluate the exact same tasks across both harnesses.

The results were eye-opening: after my initial rounds of optimization, both Claude Code and the Antigravity CLI harness settled into a highly optimized baseline of about 25,000 to 30,000 tokens for establishing the workspace. This proved that Antigravity CLI was perfectly capable of zero-cost efficiency; I just needed to aggressively restructure how I fed it data.

How We Trimmed the Fat

Getting our token usage from an exploding 50k+ down to a stable 25k per request required a ruthless, multi-pronged approach across the entire monorepo. Here is exactly what we changed (and what you should do from day one):

1. Strategic .contextignore Policies: Just like a .gitignore, we had to heavily clean up what data gets loaded into the context window by default. If the AI doesn’t strictly need it to reason about the architecture, it gets ignored. This isn’t just about cost savings—it acts as a critical security layer, guaranteeing that no stray sensitive data ever accidentally enters an LLM prompt, reinforcing our privacy-first philosophy.
2. Trimming Logs and Output Footprints: When an agent runs tests or scripts, the terminal output feeds back into its context window. We changed our test log levels to WARN and minimized the footprint of JSON payloads. Verbose logging is a silent context killer.
3. Subagent Model Compaction: Instead of using the heaviest reasoning model for everything, we optimized the subagent spawning process to explicitly use “fast” models for simpler, isolated tasks.
4. Skill Pruning and Conflict Resolution: We did a massive cleanup of our custom AI “skills.” We purged stale instructions and stopped the skills from contradicting the global rules. We clarified skill descriptions so the agent only triggers them exactly when needed, preventing wasteful tool calls.
5. M2M (Machine-to-Machine) Protocols: Instead of the main chat doing everything, we delegate isolated tasks to subagents via M2M protocols. They pass structured JSON or diff payloads rather than conversational text, ensuring the massive global context doesn’t bleed into the subagent, and the subagent replies without conversational fluff.
6. Removing Heavy Dependencies: We even went as far as removing dependencies like Playwright purely for token efficiency, as the boilerplate and configuration required for the AI to reason about it was too high.

Model Specialization: The UI Edge

Finally, optimization isn’t just about tokens; it’s about choosing the right tool for the sub-task. While Gemini is fantastic for our backend logic and general architecture, we discovered a distinct edge for frontend design.

When generating complex UI layouts, we found that Claude Opus consistently produced better, more accurate results than Gemini. Even with multiple corrections, Opus seemed to grasp the spatial and visual layout constraints much faster. By leveraging our optimized subagent architecture, we can theoretically dispatch backend reasoning to one model while routing the UI generation to another, utilizing the strengths of each.

Mastering these optimizations is what takes agent-based development from a neat party trick to a production-ready, highly efficient workflow.