When a Fast Model Feels Slow, Look at Reasoning Effort Before Switching Models

I once asked an agent to reword a single line on a settings screen in one of my wallpaper apps.

It was a handful of words. Yet there was an odd pause before the reply started, and I could see the agent re-reading the structure of files that had nothing to do with the change.

My first instinct was that I had the wrong model, so I switched to a faster one. It felt almost identical.

What actually helped was leaving the model alone and dropping the reasoning effort by one step.

Reasoning effort changes how much thinking happens, not how good the answer is

Antigravity lets you set reasoning effort per model, choosing between Low, Medium, and High. Sitting there in the settings panel, it reads like a quality dial — turn it up and the answers get smarter.

What it actually controls is how much deliberation happens before you get an answer.

On work that genuinely needs deliberation, that time is an investment. On work that does not, it is waiting time and credits quietly draining away.

My one-line rewording was firmly in the second category. The agent was dutifully re-verifying its surroundings for a change that had exactly one correct outcome. Nothing was broken except the setting.

Assign the three levels by the shape of the task

I do not sort tasks by difficulty. Difficulty collapses into "did this feel hard to me," which moves around depending on the day. I sort by whether the answer is uniquely determined.

One more thing this table quietly encodes: the first row is where most day-to-day requests actually land. Renaming a variable across a file, tidying an import block, replacing a string in three places — that is the bulk of what I hand off in a normal afternoon. If your default sits at High, every one of those small errands carries deliberation it will never use.

The row people hesitate over is always the middle one. The test is whether you can honestly say you already understand the bug. If you cannot, it belongs in the third row.

Start at Medium and look for a reason to move

Pinning everything to High means giving up your own headroom before you start. I keep Medium as the default and move only when I find a reason.

The clearest reason to go down is that the waiting is breaking the rhythm of the work. If the request fits in a single sentence, Low is usually enough.

The reason to go up is two rejected attempts in a row. The first miss might be my writing. Two in a row suggests the deliberation, not my phrasing, is what ran short.

Even then, I try rewriting the instruction first. Raising the effort does not make an ambiguous request unambiguous.

When changing the level makes no difference

If you lower the level and nothing changes, the cause is somewhere else. These are the three things I check, in order.

First, the setting lives per model. Switch models mid-session and a different value takes over. Almost every time I have thought "but I just turned that down," this was why.

Second, the editor and the CLI keep separate settings. Work you launch from a terminal never sees the editor's value. For the CLI side, I logged how routing by task class actually played out in six weeks of /effort routing.

Third, the slowness may have nothing to do with reasoning. While a workspace is being indexed, or right after opening a conversation with a huge command output in it, everything is heavy regardless of the level. The triage order in what to check when Antigravity feels slow separates those cases.

If none of the three explains it, stop guessing and make the comparison deliberate. Pick one small, repeatable errand — replacing a fixed string, say — and run it twice in a row, changing only the level between the two runs. Two back-to-back runs of the same request tell you more than a week of impressions gathered across different tasks, because everything else is held still.

Correct your judgment with records, not memory

The feeling that "Medium was enough for this one" is completely gone a week later. So I wrap the command in a small function and keep the evidence.

# drop this in ~/.bashrc
agy_run() {
  local effort="$1"; local label="$2"; shift 2
  local start end status
  start=$(date +%s)
  "$@"; status=$?
  end=$(date +%s)
  printf '%s\t%s\t%s\t%s\t%s\n' \
    "$(date +%FT%T)" "$effort" "$label" "$((end - start))" "$status" \
    >> "${HOME}/effort-log.tsv"
  return $status
}

To use it, wrap the call and add the level plus a label for the task.

agy_run medium "typo-fix" agy run "reword the settings screen copy"

After a week or so, look at it grouped by level.

awk -F'\t' '{n[$2]++; s[$2]+=$4; if ($5 != 0) f[$2]++}
  END {for (k in n) printf "%-8s %3d runs  avg %5.1fs  failed %d\n", k, n[k], s[k]/n[k], f[k]+0}' \
  ~/effort-log.tsv | sort

The output looks like this.

high       1 runs  avg   2.0s  failed 0
low        1 runs  avg   0.0s  failed 1
medium     2 runs  avg   1.0s  failed 0

The number to care about is not the average duration. It is the rows that failed while set to High. Those are the tasks reasoning effort did not solve, which means the next thing to fix is the instruction or the context you handed over.

Once I started keeping this log, I noticed I had been quietly translating "this looks hard" into High. In practice, the ambiguity of my request mattered far more than the level did.

If you are calling models from the SDK rather than the editor, you can go one layer deeper and watch thinking-token consumption directly. I wrote up that measurement, and how I split levels by task without losing accuracy, in switching thinking_level per task, including the traps I walked into along the way.

What I run today

Medium is my default. I keep exactly three cases reserved for Low: copy replacement, formatting, and reordering dependencies. High comes out a few times a week, for migrations or bugs I cannot yet reproduce.

I am not claiming this split is correct. It should depend on the kind of code you work with, and I keep nudging mine as the log tells me things.

If you try one thing, recall the last task you handed to an agent and find its row in the table above. If a first-row task was running at High, that is the easiest waiting time you will ever get back.

Thank you for reading.