The Brilliant Employee
The Brilliant Employee · 03

My gate recommends the cheap model 89% of the time. It ran 0.2% of the time.

My triage step sizes nine tasks in ten to the cheapest model. I quoted that for five weeks as what my system did. It is not.

AuthorSagnik Mitra
Published2026-08-04
Reading timeabout 5 min
Deck11 slides
Download PDF

What is inside

  1. The answer first
  2. What is a complexity gate, and what does it decide?
  3. Three chutes out of the Gate
  4. The number I actually watch, and the denominator I got wrong
  5. The target I retired
  6. Then I checked what actually ran
  7. What this buys
  8. How every number here was derived

My triage step sizes every task before a model is chosen, and it sizes about nine in ten to the cheapest tier. I quoted that ratio for five weeks as a description of what my system did. It is not one. The log records the sizing and has no field for what ran. Joined against the execution ledger, on the tasks it sized cheap, the cheap model ran twice.

Key facts. 3,717 gate decisions at the pinned cutoff. 89% sized cheap. Cheap model ran 2 of 816.

Last updated:

01The answer first

Across 3,717 real gate decisions, pinned to 4 August at 22:48Z because the log appends while I write, my system recommended the cheapest model on the roster 89% of the time and the flagship 11%. That is the design and I am happy with it. This piece is not about that number. It is about the fact that I quoted it as a description of what my machine did, and it is not one.

The Gate writes one line per decision: which tier the task deserves, whether one shot is enough, and whether the job needs a verifier or a human approval before it counts as done. There is no field for which model ran. There never was. The log records what was advised, and I had been reading it as a record of what happened.

02What is a complexity gate, and what does it decide?

The Gate is a pre-flight triage step that runs before every model call. It sizes the incoming task across five dimensions, consults a deterministic rule registry, and emits a recommendation: a worker tier, whether the work should be a single shot or a coordinated workflow, and whether it needs verification or falls under an approval rail. Trivial tasks skip the orchestration stack entirely. An earlier version of this component emitted a single scalar label, trivial through ambiguous; that scheme was retired when the five-dimension verdict replaced it.

You can rent the model. You cannot rent the part that tells you it was wrong.

The standing rule behind it is blunt: the best model call is the one you never make. Every task the Gate keeps off the heavy path is tokens, latency, and review surface that never existed.

One thing worth being precise about, because the word gate oversells it: this component enforces nothing. Its own source says so in a comment, and its last line is exit zero. It appends a sentence to the worker's instructions and gets out of the way. Enforcement lives elsewhere.

03Three chutes out of the Gate

A task exits the Gate down one of three chutes. Cheap and single-shot: 89% of decisions, and 95% of everything is recommended as one shot. Strong model: 11%, reserved for architecture, multi-file surgery, and deep investigation. Full workflow with multiple coordinated agents: 5%, only for scope you cannot enumerate up front.

The split looks aggressive until you accept the shape of real work. Most tasks are small. Routing a rename to the flagship model does not make the rename safer. It makes it more expensive and teaches you nothing.

Plain words: THE GATE. a pre-flight triage step that runs before any model call. It sizes the task, recommends a worker tier, and flags whether the job needs verification or human approval. It records all of that. It enforces none of it.
Triage before assignment. Always.

04The number I actually watch, and the denominator I got wrong

The split is not the health metric. The guarded fraction is: the share of decisions that carry a mandatory verification step or an approval rail. A cheap worker with a checker beats an expensive worker with a reputation, because the checker leaves a record and the reputation leaves an invoice.

I had this number labelled wrong. In the first 2,064 decisions, which run to 28 July, 602 carried a guard, which is 29%. That 602 is guarded at any tier. Restricted to the cheap tier, which is how I had been describing it, the count is 481, which is 23%. Both numbers are real and they measure different things, and I published the wrong pairing of figure and label.

The correction matters more than the six-point gap it closes, because the whole argument of this piece is that a number you do not re-derive will drift away from its own meaning while you keep quoting it confidently.

1Cheap and single-shot: the floor model does the job alone. 89% of recommendations land here, and 95% of everything is recommended as a single shot.
2Strong model: reserved for architecture, multi-file surgery, and deep investigation. 11% of recommendations.
3Full workflow: multiple coordinated agents, only for scope you cannot enumerate up front. 5%.
Cheap by default. Expensive by exception.

05The target I retired

The Gate used to carry a different target: block 30 to 50% of tasks from the heavy path. On 2026-07-28 I retired it, explicitly and in writing, because the gate had stopped emitting the scalar tier that target was measuring. The old number was no longer comparable to anything the live system produces.

The replacement target is qualitative where it should be and quantitative where it must be: floor by default, strong reserved for architecture and deep investigation, workflow for genuinely unenumerable scope. And the one number that must stay honest is the guarded fraction, because a cost split can look perfect while the guards quietly fall off.

the Gate's advice, pinned to 4 August 22:48Z
recommended floor (cheap)
3,311 = 89%
recommended strong
406 = 11%
recommended single shot
3,547 = 95%
recommended workflow
170 = 5%
floor AND guarded
861 = 23%
A recommendation is not an outcome.

06Then I checked what actually ran

Pinned to 4 August at 22:48Z, the log holds 3,717 decisions. Floor tier 89%, workflow 5%, guarded fraction 861 of 3,717, or 23.2%, against 481 of the first 2,064, or 23.3%, in the window that ends on 28 July. Stable, which is the answer I wanted. An earlier draft of this piece claimed a slide in that fraction and set it as homework. That drift did not exist: I had compared guarded-at-any-tier in one window against cheap-and-guarded in the other, which is two metrics wearing one name.

The real finding came from the other file. To confirm the 89% held in practice I went looking for the model field, found none, and read the execution ledger instead, which stamps every row with the gate verdict that was live for that turn. Of the 816 ledger rows carrying a floor-tier verdict, the flagship ran 796 and the cheap model ran twice. Ten of those rows name no model at all. The recommendation was followed 0.2% of the time. The design was right, the measurement was pointed at the wrong file, and a component that only ever logs its own intentions will agree with you forever.

602/2,064
of the first 2,064 decisions, the ones the Gate flagged as needing verification or explicit approval, counted across every tier. Those rows end on 28 July
Name what your guard actually does, not what you hoped it would.

07What this buys

The alternative design, sending everything to the best model, feels safe and measures nothing. You pay for reputation, collect no verification record, and never learn which tasks were trivial all along.

Reliability lives in the workplace rather than the hire. So does self-deception, if the workplace is allowed to grade its own homework. Two logs, one for what was decided and one for what was executed, and the only interesting question is what happens when you join them.

Log the outcome, or you are logging your own opinion.

08How every number here was derived

Both source files are append-only, so re-running these will give larger denominators than the ones quoted.

# Both files append while you read them, so every count
# below is pinned to one instant.
CUT=2026-08-04T22:48:00Z

# What the Gate recommended (3,717 decisions):
jq -r --arg c $CUT 'select(.ts<=$c).tier' \
  ~/.sgnk/state/complexity-gate-log.jsonl | sort | uniq -c
#   3311 floor
#    406 strong
jq -r --arg c $CUT 'select(.ts<=$c).orchestrate' \
  ~/.sgnk/state/complexity-gate-log.jsonl | sort | uniq -c
#   3547 single
#    170 workflow

# Guarded fraction, both denominators. These are DIFFERENT numbers.
# The original measurement window is the first 2,064 rows, which
# end at 2026-07-28T19:53:54Z:
head -2064 ~/.sgnk/state/complexity-gate-log.jsonl \
  | jq -c 'select(.rule2_gated or .needs_verify)' | wc -l   # 602 = 29.2%
head -2064 ~/.sgnk/state/complexity-gate-log.jsonl \
  | jq -c 'select(.tier=="floor" and (.rule2_gated or .needs_verify))' \
  | wc -l                                                   # 481 = 23.3%
# The same two filters with the ts cutoff instead of head:
#   guarded any tier  1104 of 3717 = 29.7%
#   cheap AND guarded  861 of 3717 = 23.2%

# The gate log has NO model field:
jq -r 'keys[]' ~/.sgnk/state/complexity-gate-log.jsonl | sort -u
#   correlation_id needs_clarification needs_verify orchestrate
#   rule2_gated schema session_id source tier ts

# What actually ran comes from the ledger, which stamps every row
# with the gate verdict that was live for that turn:
jq -r --arg c $CUT 'select(.gate_tier=="floor" and .timestamp<=$c).model' \
  ~/.sgnk/traces/*.jsonl | sort | uniq -c
#      8 claude-fable-5
#     98 claude-opus-4-8
#    698 claude-opus-5
#      2 claude-sonnet-5
#     10 unknown
All episodes