There are many models in Antigravity. I had a simple thought one day: I was wasting tokens and money on expensive models and thinking models that spent way too long on simple requests.

So I asked AI to explain and briefly tell me the use case of each model. I didn’t want to waste tokens anymore. I didn’t want expensive models or thinking models taking forever on trivial tasks.

Instead of relying on a single one-leg-kick model to answer every request, I wanted to be more aware of what model Antigravity switches to. I wanted to make this a daily practice.

⚠️ The One-Leg-Kick Problem

Imagine you’re a martial artist with only one move: a powerful roundhouse kick. Sure, it’s impressive. It can break boards, knock out opponents, and look cool in movies. But what happens when you need to:

• Dodge a quick jab?
• Grapple on the ground?
• Block a series of rapid punches?

You’d be inefficient. You’d waste energy. You’d get hit.

That’s exactly what happens when you use the same AI model for every coding task. You’re throwing a heavyweight punch when all you need is a quick dodge. You’re burning tokens, waiting unnecessarily, and not getting the best results.

The solution? Build a diverse arsenal. Know when to use speed, when to use power, and when to use precision.

My Discovery: Not All Models Are Created Equal

When I started using Antigravity daily, I noticed something frustrating:

• I’d ask a simple question like “What does this function do?” and wait 30 seconds for a thinking model to process it.
• I’d request a complex architectural refactor and get a surface-level response from a lightweight model.
• I’d burn through expensive tokens on tasks that didn’t need that level of reasoning.

So I did what any developer would do: I asked the AI itself.

“Explain each model available in Antigravity and tell me the best use case for each.”

What I got back was eye-opening. Each model had a specialty – a specific scenario where it excelled. Using the wrong model wasn’t just inefficient; it was like using a sledgehammer to hang a picture frame.

From that moment, I made it a daily practice to be aware of which model I was using and why.

My Personal Journey: From Claude to Gemini and Back

I’ve been using Claude since version 3.5, and it’s been fantastic for most of my work. When Gemini 2.5 Pro came out, I tried it once or twice, but honestly, it wasn’t convincing enough to make me switch. I quickly jumped back to Claude.

Recently, I’ve been exploring Gemini 3 Pro, and I have to say it works great, especially for coding. The way it handles implementation tasks is impressive. But when it comes to explanation and learning? I’m still leaning toward Claude most of the time.

Why? Because Claude feels more natural for breaking down complex concepts, code reviews, documentation, and UI work. Gemini 3 Pro shines when I need to build features and write code, but Claude is my go-to for understanding and learning.

That said, this experience taught me something important: no single model is perfect for everything. That’s exactly why I started paying attention to which model I use and when.

The Antigravity Model Arsenal

Here’s what I learned. Think of these models as different fighters in your corner, each with their own specialty:

🏃 Gemini 3 Flash – The Speedster

Best for: Quick explanations, code walkthroughs, searching logs

Flash is your scout. It’s fast, handles massive context windows, and gives you answers in seconds. When you just need to understand what a function does or navigate a large codebase, Flash is your go-to.

Don’t use it for: Complex refactoring or building new features. It’s built for speed, not deep reasoning.

🥊 Gemini 3 Pro (Low) – The Daily Driver

Best for: Feature implementation, writing tests, standard coding tasks

This is your workhorse. It’s smart enough for 90% of your daily coding tasks but doesn’t burn through tokens like the heavyweight models. If you’re adding a new function, writing a test, or implementing a straightforward feature, Pro Low is perfect.

Don’t use it for: Massive architectural changes or complex debugging. For that, you need more firepower.

💪 Gemini 3 Pro (High) – The Heavyweight

Best for: Building entire modules, complex architectural changes, deep logic debugging

When you need maximum reasoning power, Pro High is your champion. It thinks about the entire architecture, ensures scalability, and handles intricate logic. This is the model you use when you’re building something from scratch or refactoring a critical system.

Don’t use it for: Simple questions or quick explanations. You’re wasting its potential (and your tokens).

🎨 Claude Sonnet 4.5 – The Artist

Best for: Code reviews, documentation, UI/UX work, CSS styling

Claude is your craftsman. It excels at aesthetic judgment, writing beautiful documentation, and creating polished UI components. If you need premium CSS with glassmorphism and smooth animations, Claude is your model.

Don’t use it for: Pure algorithmic logic or performance-critical code. That’s Gemini’s domain.

🧠 Claude Sonnet 4.5 (Thinking) – The Detective

Best for: Complex debugging, tracing execution flows, “weird” bugs

When you’ve been staring at a bug for hours and can’t figure it out, call in the detective. Thinking mode traces through logic step-by-step, often catching subtle issues other models miss. It’s slower, but when accuracy matters more than speed, it’s worth it.

Don’t use it for: Simple tasks or exploratory questions. The extended reasoning is overkill.

🚀 Claude Opus 4.5 (Thinking) – The Final Boss

Best for: Massive migrations, extremely difficult logic puzzles, when other models fail

This is your nuclear option. Opus is the most powerful reasoning model available. Use it for framework migrations, refactoring across dozens of files, or solving problems that have stumped every other model.

Don’t use it for: Anything else. It’s slow, expensive, and overkill for 99% of tasks.

My Daily Practice: Choosing the Right Fighter

Now, every time I open Antigravity, I ask myself:

“What am I trying to do, and which model is best for this?”

Here’s how I think about it:

🔍 Just trying to understand code?

→ Gemini 3 Flash. Fast, efficient, perfect for exploration.

🏗️ Building a new feature?

→ Gemini 3 Pro (Low). My daily driver for standard work.

🧐 Reviewing code for quality?

→ Claude Sonnet 4.5. It gives human-like feedback and catches style issues.

🐛 Debugging a complex issue?

→ Claude Sonnet 4.5 (Thinking). Let it trace through the logic step-by-step.

🚀 Refactoring an entire module?

→ Gemini 3 Pro (High). Maximum reasoning for architectural changes.

🔄 Migrating a framework?

→ Claude Opus 4.5 (Thinking). The God-Mode for the hardest tasks.

The One-Leg-Kick Metaphor in Action

Let’s say I’m working on a new feature for my blog. Here’s how I’d approach it:

1. Understanding the existing code > Use Flash to quickly scan through the codebase and understand the current structure.
2. Implementing the feature > Switch to Pro (Low) to write the new functionality.
3. Reviewing the code > Ask Claude Sonnet 4.5 to check for readability and style issues.
4. Debugging a weird bug > If something breaks, I escalate to Claude Sonnet (Thinking) to trace the issue.
5. Feeling skeptical > If I miss any edge cases, I’d engage the 🚀 Final Boss for review.

Each model is a different move in my martial arts arsenal. I’m not throwing the same kick every time, I’m adapting to the situation.

Why This Matters

Before I started this practice, I was:

• ❌ Wasting tokens on expensive models for simple tasks
• ❌ Waiting unnecessarily for thinking models to process trivial questions
• ❌ Getting subpar results because I was using the wrong tool for the job

Now, I’m:

• ✅ Using the right model for the right task
• ✅ Saving tokens and money
• ✅ Getting better, faster results

The best model is the one that gets your job done efficiently.

Don’t be a one-leg-kick developer. Build your arsenal. Know your models. Make it a daily practice.

🤷 When in Doubt: The Safe Default

Can’t decide which model to use? Start with Claude Sonnet 4.5.

It’s the jack of all trades – not the absolute best at anything, but competent at almost everything:

Works well for:

• ✅ Feature implementation
• ✅ Code review
• ✅ Documentation
• ✅ UI/UX work
• ✅ General questions about code

Escalate when:

• ❌ Massive architectural changes → Go to Gemini 3 Pro (High)
• ❌ Weird, stubborn bugs → Go to Claude Sonnet (Thinking)
• ❌ Just exploring/reading code → Downgrade to Gemini 3 Flash (save tokens)

“When in doubt, start with Claude Sonnet 4.5. If it struggles, escalate to Thinking mode or Pro High. If the task is simple exploration, downgrade to Flash.”

📋 Quick Reference: The Model Cheat Sheet

Final Thought

The one-leg-kick approach might work in movies, but in real development, you need versatility. You need speed when exploring, power when building, and precision when polishing.

Start paying attention to which model you’re using. Make it a daily practice. Your tokens and your productivity will thank you.

Now go build something amazing. 🚀

I thought I was being smart.

I had dozens of user guides, and system documentation GDocs scattered across my drive. So I did what seemed obvious in 2026 I imported everything into NotebookLM. Every single guide. All at once and thought magic will happen.

“Now the AI has access to everything,” I thought. “It’ll be amazing.”

Then I asked a simple question about a specific feature.

The AI gave me an answer. But it was wrong. Not completely wrong but worse than that. It was a mix of information from three different guides. The AI is unable to understand the question identify which guide to go.

I had given the AI more context, and somehow got worse results.

That’s when it hit me: Having context isn’t enough. You need to manage it.

What I Learned the Hard Way

In 2025, I wrote about meta-prompts and how to craft better prompts. Meta-prompts worked great for refining my questions and getting better responses.

But then I started using NotebookLM, and something unexpected happened.

I thought giving AI access to all my documentation would make everything even better. Instead, it opened my eyes to something I’d completely overlooked: context management matters just as much as prompt engineering.

The problem wasn’t how I was asking it was how I was organizing what I gave the AI to work with.

What Changed in 2026

The AI models got smarter. Not just incrementally better fundamentally different in how they understand us.

The old way (2024-2025):

• Models were literal. “Write code” != “Write clean, production-ready code”
• You had to specify every constraint
• Ambiguous phrasing > Model gets confused or refuses
• English fluency mattered

The new reality (2026):

• Models infer “best practice” defaults automatically
• If you ask for code, it assumes you want it runnable
• Models use reasoning to bridge gaps in your phrasing
• “Bad English” still yields “Good Logic”

The result: Prompt engineering is still important, but relatively less critical than it used to be. The bar for “good enough” prompts got much lower.

The Shift: From “How” to “What”

Bottom line: Stop obsessing over how you ask. Start obsessing over what you provide.

The “Garbage In” Problem (GIGO)

Here’s the brutal truth: No amount of prompt engineering can fix missing information.

Scenario: Q4 Sales Report

Perfect Prompt (No Data):

Act as a CFO with 20 years of experience. Write a comprehensive Q4 
sales analysis with insights on trends, recommendations for Q1, and 
executive summary. Use professional business language and include 
data-driven insights.

Act as a CFO with 20 years of experience. Write a comprehensive Q4 
sales analysis with insights on trends, recommendations for Q1, and 
executive summary. Use professional business language and include 
data-driven insights.

Outcome: ❌ Beautifully written fiction. The AI will hallucinate numbers, trends, and insights because it has nothing real to work with.

Basic Prompt (With Data):

Analyze this Q4 sales data and summarize key trends

[Attach Q4_Data.csv]

Analyze this Q4 sales data and summarize key trends

[Attach Q4_Data.csv]

Outcome: ✅ Accurate, factual summary based on real data. Not as polished as the perfect prompt would produce, but grounded in reality instead of hallucination.

The lesson: The bottleneck is no longer the instruction (the prompt). It’s the source material (the context).

The Chef Analogy

Think of it this way:

• Model = Master Chef 👨‍🍳
• Prompt = The Order Ticket 🎫 (“Make a steak”)
• Context = The Ingredients in the Fridge 🥩

Old Era (2024-2025):
You had to write the ticket precisely: “Cook steak, medium-rare, sear 2 mins each side, rest 5 mins.”

New Era (2026):
The Chef is a master. You just say “Steak.” He knows how to cook it.

The Problem:
If the fridge is empty (No Context), even the best Chef in the world cannot make you a steak. He can only serve you a picture of a steak (Hallucination).

Verdict: Stop trying to write better tickets. Start stocking the fridge.

But here’s the catch: You can’t just throw everything in the fridge and call it done.

The NotebookLM Problem: Context Dumping != Context Management

Remember my NotebookLM disaster? That’s what happens when you confuse having context with managing context.

What Went Wrong:

I imported multiple guides for the same system, each covering a different area:

• User Guide (complete, accurate, up-to-date)
• Configuration Guide (complete, accurate, up-to-date)
• Quick Start (complete, accurate, up-to-date)
• Ops Guide (complete, accurate, up-to-date)
• Troubleshooting FAQ (mixed topics across all areas)

Each document alone worked perfectly. The content was relevant, correct, and helpful.

But together? Chaos.

When I asked: “How do I configure user permissions?”

The AI couldn’t figure out which area of the system I was asking about. It would:

• Pull configuration steps from the Configuration Guide
• Mix in troubleshooting tips from the FAQ
• Add best practices from the Ops Guide that didn’t apply to my question

The result: A Frankenstein answer that was technically correct for each source, but completely useless for my actual question.

The AI had access to everything, but it couldn’t locate which document was most relevant to my specific question.

The Real Problem:

It’s not “Garbage In, Garbage Out” (GIGO).
It’s “Too Much In, Can’t Figure Out Which” (TMICFOW? Okay, that acronym doesn’t work 😅).

The AI had access to everything, but it couldn’t tell:

• Which area of the system I was asking about
• Which document was most relevant to my specific question
• How to disambiguate between similar topics across different guides

This is the context management problem: Not bad data, but unorganized data that the AI can’t navigate effectively.

What I’m Learning

I haven’t solved this yet. I’m still figuring out the best way to organize context so AI can actually use it.

But I know the direction: Context Management.

The questions I’m exploring:

• How do I structure documentation so AI knows which doc to use?
• Should I use separate NotebookLM projects by topic?
• How do I name files to make them more AI-friendly?
• What’s the right level of granularity for splitting docs?
• Can folder structure alone provide enough context clues?

Some ideas I’m testing:

• Organizing by topic/area instead of dumping everything together
• Using clear, descriptive file names that include the topic
• Being more explicit in my questions (“…for end users” vs just “how to…”)
• Selective importing – only bringing in docs relevant to the current task

I’ll share what I learn as I experiment.

The Two Skills Compared

2025: I focused on prompt engineering – how to ask better questions
2026: I’ll be put more effort on context management – how to organize knowledge so AI can use it

Both skills matter. But meta-prompts solved one problem. Context management is the next frontier and potentially the higher-leverage skill.

The Realization

I thought giving AI more context would automatically help.

Turns out, organized context is what matters.

It’s not enough to have all the information. The AI needs to be able to:

• Locate the relevant document
• Disambiguate between similar topics
• Navigate your knowledge structure

This is a different skill than prompt engineering. And I’m just starting to learn it.

What This Means 💡

If you’re using tools like NotebookLM, Notion AI, or any AI with document access:

The problem isn’t just what you ask.
It’s how you’ve organized what the AI has access to.

A perfect prompt with zero context = 🎭 Hallucination
A basic prompt with perfect context = ✅ Usable output

I don’t have all the answers yet. But I’m convinced this is the right direction. 😉