Summarize with local AI
← Playbooks

Playbook

Compute Tiering

Not every task deserves my most expensive AI. Here’s the real, written rulebook that decides — and what happened before I had one.

Not every question deserves your smartest, most expensive employee. A password reset doesn’t need the CEO. A company-wide strategy memo does. Most businesses already sort work this way without thinking about it — cheap, fast help for routine stuff; your best people for anything genuinely hard or genuinely risky to get wrong.

AI needs the same sorting, for the same reason: a more capable AI model can cost 15 to 20 times more per task than a smaller one, and takes longer to respond. Most tasks don’t need the expensive one. Some absolutely do. The problem is that almost nobody writes this down as an actual rule — it’s usually a vague habit, decided task by task, by whoever happens to be building the thing that day.

I don’t do it that way. Below is the real rulebook I use — not a summary of it, the actual document — plus the true story of what happened the one time a task ran through a tier that was too relaxed for what it needed. (The fuller argument for why this matters at all is a companion piece: Stop Using Your Biggest Model for Everything.)

The actual rulebook

I keep one written document that every part of my system checks before picking an AI for a task, instead of each part deciding on its own — which is how inconsistency creeps in. It sorts work into 8 categories, based on two questions: how much judgment does this task really need, and how bad is it if the AI gets it wrong? Each category is assigned a tier — a cheap, fast option; a mid-range option; or the most capable, most expensive option — plus a plain reason a reviewer could actually argue with, not just a gut feeling.

Below is a real, unedited excerpt — four of the eight categories, not simplified for this page. You don’t need to read code to follow it: a plain-English translation of all four sits right below the excerpt.

Real artifact · excerpted compute-weights.yaml · v2 · last updated 2026-07-06
# Gordon OS Compute Weights — model/effort tiering policy
#
# This is an engineering cost/quality policy, NOT the utility function
# (that's goal-weights.yaml — sacrosanct, never touched from here).
# compute-weights.yaml IS editable, but not by any skill or automated
# campaign directly: changes go through the same review discipline the
# rest of the system already uses for its other load-bearing documents.
# A skill may PROPOSE a change but never writes this file itself.

version: 2
last_updated: "2026-07-06"

task_classes:
  deterministic_read:
    model: none
    effort: n/a
    # Script output formatted into a table/summary — zero judgment
    # involved. No model call needed at all.

  bounded_judgment:
    model: sonnet
    effort: low-medium
    # A draft produced from context already fully in hand.
    # Templated, low ambiguity.

  fleet_synthesis:
    model: opus
    effort: high
    # Cross-item judgment that writes to a shared, load-bearing
    # document. Precedent: a raw-append bug in this class once added
    # ~4,600 junk lines to a shared workstreams document.

  topology_deviation:
    model: opus
    effort: high
    requires: "cite the evidence trail before deviating from a locked default"
    # Proposing to break from an established default is the exception,
    # not the path — a wrong call here has a directly measured cost.

In plain English, what those four actually mean:

  • Deterministic read — no AI judgment at all. A script already worked out the answer; something just needs to read it out. No AI tier needed — it's free.
  • Bounded judgment — a routine first draft, built from information already fully in hand. Goes to the fast, inexpensive AI.
  • Fleet synthesis — combining many separate pieces of work into one shared document the whole team reads and relies on. Goes to the most capable, most expensive AI, every single time — no exceptions.
  • Topology deviation — a genuine exception to the usual playbook, not routine. Also goes to the most capable AI, and it has to show its reasoning before it's allowed to break from the default.

Why this actually works: nobody can quietly change it

A rulebook is easy to write once and then ignore. What makes this one real, instead of a document nobody actually follows, is the process wrapped around it. It's dated and version-numbered, and everything that depends on it checks that version before trusting it. If the rulebook falls out of date, or a category it depends on disappears, the system is required to default to the most careful, most expensive tier — rather than guess.

Nothing in my system, no AI and no automated process, is allowed to edit this rulebook on its own. It can suggest a change, the same way an employee might flag a budget line for their manager to review — but it can't make the change itself. And every part of the system points back to this one document instead of keeping its own copy, so there's exactly one place these decisions live, not a dozen slightly different versions floating around.

Why the riskiest kind of task always gets the best AI

The reason behind one of these four categories isn't hypothetical. “Fleet synthesis” — combining many people's separate work into one shared document everyone else reads — used to run on the cheaper, faster tier. A bug in that process quietly dumped roughly 4,600 junk lines into a shared company document before anyone noticed. Nobody decided to take that risk on purpose. It just happened, because there was no written rule requiring extra care for that specific kind of task.

That's the entire reason this category is now permanently locked to the most capable, most expensive tier — not because “better AI is always safer” as a general belief, but because of one specific, dated incident with a real, measurable cost. That's the difference between a real rule and a guess: you can go find the actual reason behind it and judge for yourself whether it still holds up.

What I'd ask before trusting anyone else's AI cost policy

  • Is there an actual written rulebook — or is everyone just deciding, case by case, on gut feeling?
  • Can the AI system change its own rules without anyone reviewing it? If so, what's stopping it from quietly loosening those rules to make its own life easier?
  • When a new kind of task shows up that the rulebook never planned for, does the system play it safe with the best AI available — or default to whatever's cheapest and fastest?
  • Is there a real story behind why any rule exists — or is every rule just someone's best guess, made once and never revisited?

The policy isn't the document. The policy is that nothing can quietly change what's inside it.

The argument this enforces — Stop Using Your Biggest Model for Everything

Better business. Better work.

AI · runs on your device, not a server

Summarize this post

Generated on-device by a small open Gemma model running in your browser via WebGPU — nothing about this article is sent anywhere. The model downloads once and is cached by your browser after that, so it's free to use, every time, for every reader.

Local Gemma · always free inference

summary.local