Stop Defaulting to “Medium”: Optimizing Gemini 4 Argon and 3.8 Flash Effort Budgets in Antigravity
Imagine you are out for a fancy dinner and picking a wine. Do you choose the most expensive bottle, pick the cheapest, or settle somewhere in the middle? Your gut feeling, along with social convention, likely nudges you toward that middle tier. The Goldilocks principle is deeply embedded in everyday decisions: we naturally view the center as the safe bet and shy away from extremes.
When developers configure Antigravity, many follow that exact same intuition and leave their effort level on Medium. Not too low, not too high. But what does that setting actually do under the hood? How does it change between different Gemini models? How does it impact execution time, token spend, and solution accuracy? How does your agent’s reasoning strategy change when you toggle between Low, Medium, and High effort?
That’s exactly what we want to explore in this blog. We will walk through an experimental benchmark to evaluate how these effort levels perform, and use that information to distill clear guidelines to pick the ideal setting for your own workflows. All so that next time picking the right effort level for your model doesn’t feel like rolling the dice.
Experiment Setup
In order to explore the effects of different effort levels on different tasks (the two variables that we want to explore), we first need to define the scenario and variables that we want to fix for this experiment. Obviously you could run different experiments and change these variables as well, for example to explore the performance of one scenario across different effort levels and coding harnesses or any other combination you are interested in.
Here is a list of parameters that are fixed in this experiment:
- Harness: Antigravity in the form of Antigravity CLI. The CLI allows us to easily script benchmarks by setting the model and effort via the
--model gemini-4-argon-mediumparameter and passing in a scenario via the--promptparameter. To let the agent perform the operations autonomously we’re also setting the--dangerously-skip-permissionsand--sandboxparameters to sandbox the execution. - Model: Here we’re using Google’s latest Gemini 4 Argon and Gemini 3.8 Flash models as examples because they cover a nice range of low-latency, low-reasoning tasks, but can also nicely extend their reasoning to operate in high-ambiguity scenarios.
- Code Base: This is a purely arbitrary choice, but here we’re using ZX, an open-source Node.js library developed by Google to make scripting in JavaScript easier and safer. ZX also powers our benchmarking harness, just because the idea of double dogfooding sounded like a fun thing to do.
For the scenarios, we want to make sure that we cover a range of different tasks that are representative of typical development activities on top of an existing code base. These scenarios are obviously specific to the code base that we’ve selected above and can be modified if you want to run your evaluation on a different code base.
- Scenario 1: Understand the Code Base (Simple, Read-Only) This is the simplest case where we only want to understand an existing code base with explicit instructions to not modify it.
- Scenario 2: Simple Refactoring of Boolean Parsing Behavior (Well-Defined Scope) In this case, we now want to start modifying our existing code base. The task is well-defined and includes a verification example.
- Scenario 3: Feature Implementation Linear Backoff (Low Complexity, Well-Defined Scope) In this scenario, we expand the prompt with some more ambiguity but still provide guidance on the implementation logic.
- Scenario 4: Feature Implementation Dry Run (Medium Complexity, Medium Ambiguity) In this last scenario we want Antigravity to operate on a task with more ambiguity such as what happens if the dry run command’s output is used later in the ZX script is not specified in the prompt and should probably be clarified first.
Benchmarking Harness
To test the different permutations of models, efforts, and scenarios, I’ve created a simple little benchmarking harness. The harness is essentially a wrapper around the Antigravity CLI to provide the scenario’s prompt and effort level together with the success validation and the necessary extraction logic to capture the agent’s behavior. In this case, the models are actually a combination of model version and effort level (e.g., gemini-3.8-flash-high), which allows the same evaluation harness to also compare the behavior of different model families without changing the loop logic.
To understand what the agent did during the execution, we parse the session transcript that is automatically generated in the local Antigravity “brain” folder. Wrap that in a loop to cycle through the configured number of repetitions, efforts, and scenarios, and we have our complete experiment setup.
If you’re interested in the complete implementation of the benchmarking harness check out this repository on GitHub.
Observations and Interpretations
Colloquially, effort is the primary lever for telling the model how much it is allowed to spend on tasks like exploring the space it operates in, thinking and hypothesizing about ambiguities in the task, and validating its strategies before they are applied. As we’ll see in this section, the effort levels therefore have a significant impact on all observed dimensions across all four scenarios.
As the scenarios are still relatively trivial, all model, effort, and task configurations pass the validation tests. An academic evaluation of the capability limits of each configuration is beyond the scope of the analysis we want to perform. Here we are mainly concerned with the basic token and cost metrics as well as the overall behavior of the agent.
How many tokens were used to complete each task?
As your agents spend more effort on your tasks they significantly increase their thinking tokens and load additional resources into their context. All of these contribute to higher token consumption at the inference layer. The following chart shows the token consumption across input, cached input and output for each of the four tasks across Gemini 3.8 Flash and Gemini 4 Argon for Low, Medium, and High effort levels:
How much did each run cost?
We can use the token spend to calculate an approximate task cost for each of the effort levels according to the current list pricing for Gemini models as of the writing of this article. Note that both Gemini models currently have promotional pricing applied and that the list price might differ from what you see in the charts below.
Get Daniel Strebel’s stories in your inbox
Join Medium for free to get updates from this writer.
The most interesting and surprising outcome for these four scenarios is that even though the price per token of Gemini 4 Argon is much higher than for Gemini 3.8 Flash, the cost per task is comparable. For the more ambiguous Scenario 4, Gemini 4 Argon even costs roughly half as much as Gemini 3.8 Flash across all three effort levels.
How long did the runs take?
Gemini 3.8 Flash is commonly cited for having a very high token throughput rate. One could therefore assume that tasks running on 3.8 Flash should also complete quite quickly. On the other hand, as we saw before, Gemini 4 Argon was far more efficient in its token consumption and quickly converged on a solution. How does that influence the overall execution duration per task?
Looking at the chart below, we can see that with the exception of Task 2, Gemini 4 Argon was able to complete the tasks much more quickly than Gemini 3.8 Flash did.
Overthinking Trap
Of course, without a robust quantitative quality measure, it’s impossible to judge whether or not the token spend is justified or whether our agents were vastly overthinking the task at hand. However, especially when looking at Gemini 3.8 Flash for Medium and High effort, we notice a tendency to consume a lot of additional tokens compared to the same tasks handled by Gemini 4 Argon. With the exception of the High effort Gemini 4 Argon for Task 2, the Argon runs significantly undercut the number of tokens used by Gemini 3.8 Flash. Even though Gemini 3.8 Flash has a very high output token throughput, the time it takes to converge on these thinking excursions can be significant.
What did the Agent Actually do?
We’ve looked at the tokens, the cost, and the duration to complete each task per model and effort. The question that is left to explore is: what did the agent actually do? Which tools did it use, and for what purpose? The session transcripts are a very interesting source of information for this, providing deep insight into which tools are used and why. As you can see in the charts below, the number of tools used generally increases with the thinking level because we allow the agent to spend more effort exploring the environment (view_file) and increasing its confidence in code snippets and how tools actually work (run_command). What we can also see from the transcript is that the view_file commands in Gemini 3.8 Flash seem to slice files into relatively small chunks, leading to multiple view_file commands for different sections of the same file. Gemini 4 Argon, on the other hand, tends to prefer reading the full file and therefore runs fewer view_file tool calls.
The effort levels across both Gemini 3.8 Flash and Gemini 4 Argon mainly seem to control how many additional files and commands are executed i.e., how much additional information is gathered. The number of final file edits via write_to_file or replace_file_content tools, on the other hand, is almost identical across the different effort levels.
How does this compare to realistic tasks?
As described in the evaluation harness section above, the setup we used is quite bare-bones. The ZX repo was written before the advent of AI agents and therefore contains neither indices nor skills that would help agents be more efficient. In a more practical setup, having skills and context available would most likely help the agent traverse the code base more efficiently, better understand the available tools, and reduce the number of command-line executions used to explore tools with --help or check tool existence with which.
Another lever that could apply, especially in feature implementation scenarios with higher ambiguity, would be to adopt a stricter spec-driven development approach and provide more guidance on what to do and how to do it. Along the same lines, you could also use the powerful /grill-me feature in Antigravity to help provide additional guidance for the agent, reducing the risk of going down unnecessary rabbit holes.
Another way to avoid rabbit holes in real-world operations stems from manual tool approval. In our evaluation harness, we use --dangerously-skip-permissions, which essentially enables unrestricted mode (formerly known as YOLO mode in Gemini CLI) and auto-approves any requested tool. In a scenario where a developer manually approves tool calls, they could intervene much earlier if they see the agent heading in a direction that doesn’t yield valuable information and wastes tokens. For instance, in Task 2 using Gemini 4 Argon with High effort, the developer could have rejected the deep inspection of the Git history early on when it wasn’t yielding meaningful results.
Hybrid Multi-Effort Lifecycle
In a real-world scenario, you don’t have to keep the effort level constant for the entire lifecycle of a feature implementation. In fact, many teams agree that the most promising strategy is a hybrid approach involving switching efforts and models multiple times. A fast and cheap model like Gemini 3.8 Flash can be helpful for ingesting a lot of code to build a knowledge base for later activities. Then, following an Elephant-Goldfish approach for spec-driven development, they might use the full power of a large model at High effort to build an “Elephant” to explore the problem space and related code base to craft a robust specification and implementation plan. Once the plan is in place, they pivot to a lower-effort “Goldfish” to execute the well-defined implementation tasks at speed. At the end, they might again use a higher-effort approach to validate and iterate on the implementation until completion. Combining different levels of effort allows you to deploy higher intelligence when needed while benefiting from efficient processing when the task is well-defined and understood.
Takeaway Message and General Advice
At the beginning of this post, we talked about the Goldilocks principle and the instinctive human tendency to pick the middle option on the wine list and leave our agent’s effort dial permanently set to Medium.
If there is one takeaway from running these benchmarks and reading the underlying session transcripts, we find this:
Effort is not a “quality slider” it is an exploration and verification budget for your agent.
Intuitively the effort levels could be thought of like project scope in classical software engineering. If you give too little time the engineer would just rush to a solution and potentially overlook optimizations and how their fix is embedded into the larger code base. If you provide too much time they start poking around unnecessary places, stumble over artifacts that are only partially related, start investigating about those too .. and before you know it they are investigating what it would take to rewrite the whole application in Rust.
Dangerously Oversimplified Rules of Thumb
So what can we take away from these experiments? Instead of defaulting to the middle option and leaving your agent constantly at Medium effort, consider the following guidance:
🟢 LOW effort should be used as the default option for narrow, well-scoped tasks. For renaming, targeted refactoring, read-only audits, small bug fixes, or well-defined feature implementations, the low setting promises to be significantly faster and more cost-effective. Across the benchmarks here, the low setting was running 3–5x faster and 3–8x cheaper than the high effort setting. Interestingly, the tasks well-suited for low effort also generally tend to be the ones where you benefit most from the higher throughput and lower token cost of an efficiency-tuned model like gemini-3.8-flash.
🟠 MEDIUM effort provides a pragmatic balance for when the blast radius is unknown. It allows the agent to explore the problem space enough to understand the immediate code context, test files, existing conventions, and to inspect the available tools but avoids going down unnecessary rabbit holes and embarking on costly side quests.
🔴 HIGH effort should be reserved for the most demanding tasks. Tasks that operate in a complex architectural environment, have high ambiguity, or ones that previously failed to converge on a lower effort setting. Even with the high effort scenario enabled, consider providing rich contextual information, skills, and potentially guidance through approved tool usage to help the agent navigate the problem space as efficiently as possible.
Finally, do not shy away from changing the effort level or model along the way. For example, if ambiguity is reduced as you start to meticulously specify and plan your implementation with a high effort, maybe reducing the effort levels can help you during implementation to speed things up again and reduce overall task costs.
If we learned anything at all from these small experiments, then it is that when it comes to model and effort, there is no one size fits all and that tweaking and experimentation is needed to gain a better understanding. At least until the next model comes around and the optimization game starts from scratch again.
