Screen cheap, spend expensive: agent triage
A worker that reads 400 items to act on 9 bills you for reading 400. Three ways to put a cheap screening pass in front of the expensive work.
A worker reads 400 threads every morning to find the 9 that need a reply. It reads all 400 on the same model that writes the replies, and the bill says so: you paid a drafting model to look at 391 things it was never going to touch.
That is a sequencing problem, not a model problem, and the fix is old advice in a new setting: put a cheap screen in front of the expensive work. Most people running agents against a queue have not, because when you are sitting there the reading feels free. Unattended, at 400 items a day, it is most of the bill. None of the three fixes below needs new engineering: the cheapest takes minutes, the most involved takes a day.
The shape of the fix
Every queue-shaped job has two halves that get treated as one:
- The pass. Decide whether an item deserves anything. Cheap per item, done hundreds of times.
- The work. Pull the context, make the call, write the thing, touch the real account. Expensive per item, done a handful of times.
Paying the second half's price for the first half is the whole problem. Three ways to stop, in increasing order of effort, and in that order: each one makes the next smaller.
| Way | Effort | What it saves | Where it stops helping |
|---|---|---|---|
| Narrow the fetch | Minutes | Every token of every item never fetched | A source filters on facts, not on judgment |
| Stop early in the instruction | An afternoon | The context pulls, the writes, the output tokens | You still pay to read each item once |
| Split into two workers | A day | Moves the reading pass onto a model 25x cheaper | Two workers now have to agree with each other |
Narrow the fetch so the model never sees the junk
The cheapest token is the one never read. Most connected apps filter hard before anything reaches a model, and most workers ask for none of it: unread and in one label since the last run rather than the whole inbox, issues touched in the last 24 hours rather than every open issue, CRM records whose stage changed yesterday rather than the pipeline.
This changes the pass's tool calls as well as its tokens. One list operation returning 400 items with their subject, sender and snippet is one tool call. Opening each to read its body is 400. A screen that decides from what the list already returned is the cheapest one involving a model at all.
Write the instruction so the run stops early on a clear no
Most instructions describe the work and leave the decision implied. Put the decision first, and name what ends the run for that item:
For each thread: if it is an automated notification, a newsletter, or already has a reply from us after the customer's last message, record "no action" and move on. Do not open the CRM. Do not draft anything.
The saving is not the read. It is everything the read would have led to: the context pulls, the tool calls and the output tokens, which are the expensive half on every model in the catalog. Getting that to hold on the four hundredth item is covered in writing an instruction that holds.
Split one worker into two
The version with real leverage. A screening worker on a cheap model reads the queue and produces a shortlist. A working worker on a capable model takes that shortlist and does the job.
Per token, GPT-5.6 Luna is 25x cheaper than GPT-5.6 Sol on input ($0.20 against $5.00 a million) and exactly 25x cheaper on output ($1.20 against $30.00). The pass does not need the expensive model. The work usually does. Which model belongs where is how to pick a model per job; every kit page carries a grade per model.
The catch is that two workers can disagree. They need one definition of "needs action", written once and used in both instructions, or the screen drops work the second worker would have done well.
Costed, with the real catalog
Assumed figures, stated so you can argue with them and rerun the sums against your own receipts:
| Quantity | Assumed |
|---|---|
| Items in the queue a day | 500 |
| Items left after a source-side filter | 120 |
| Items that deserve the expensive work | 25, so 5% |
| Input tokens to read one item | 800 |
| Output tokens for one screening verdict | 40 |
| Extra input tokens to work one item | 2,000 |
| Output tokens for one finished draft | 600 |
The filter row is the generous assumption and the one to argue with first: it takes 500 down to 120 and drops none of the 25 that mattered. A filter that drops real work is not a saving, and what that costs is priced under false negatives below.
Tokens bill at provider list price with no markup, so the rates below are the real ones on /pricing.
| Setup | Items read | Model | Tokens in | Tokens out | A day | 30 days |
|---|---|---|---|---|---|---|
| Everything on the capable model | 500 | Sol | 450,000 | 35,000 | $3.30 | $99.00 |
| Narrow the fetch first | 120 | Sol | 146,000 | 19,800 | $1.32 | $39.72 |
| Everything on the cheap model | 500 | Luna | 450,000 | 35,000 | $0.13 | $3.96 |
| Screen cheap, spend expensive | 500, then 25 | Luna, then Sol | 470,000 | 35,000 | $0.90 | $27.12 |
| Narrowed and split | 120, then 25 | Luna, then Sol | 166,000 | 19,800 | $0.82 | $24.75 |
The split row spelled out, since a mixed row hides its arithmetic. The screen reads 500 items on Luna: 400,000 input at $0.20 a million is $0.08, and 20,000 output at $1.20 is $0.02. The work re-reads 25 items with their context on Sol: 70,000 input at $5.00 is $0.35, and 15,000 output at $30.00 is $0.45. Ten cents of screening, eighty cents of work.
The cheap model alone is the cheapest row and the wrong answer. At $0.13 a day it beats everything, because it also put the weak model on the 25 items that mattered. The split is not the cheapest arrangement; it is the cheapest one that still puts your best model on the work.
Narrowing the fetch is worth most before you split. It takes the top row from $3.30 to $1.32 for ten minutes of configuration. After the split it saves eight cents.
After the split, nine tenths of the bill is the work itself, $0.80 of the $0.90. Nothing is left to screen, and the next saving comes out of the work, a quality decision rather than a free win.
The trigger is the cheapest screen of all
The screen you never run costs nothing. A worker on an hourly schedule checking a queue spends its whole day discovering that nothing happened. A webhook trigger fires on the 9 events and sleeps through the rest. The source performs that screen for free, before any model is involved, and it beats anything a model could infer. The trade-offs are in schedule or webhook trigger.
A trigger does not replace a schedule. It fails by not happening, which is invisible, so keep a slow schedule underneath as a sweeper, and point that sweeper at the cheap model.
What the caps and receipts are for
A screen is a guess about your volume, so three things make being wrong survivable.
Hard tool-call caps. Free allows 500 a day, Pro 5,000, Team 50,000 pooled. At the cap a worker pauses until the counter resets. A runaway pass on a soft cap is an invoice; on a hard cap it is a paused worker and a line explaining why.
The wallet reserves before it runs. A run claims its token budget up front from the runtime wallet, so a balance that will not cover it skips the run and records the skip rather than stopping half way through your inbox.
A receipt per run. Every run receipt carries what that run read, did, skipped and spent, which is how you learn whether the screen works: count how many items survived the pass. If 40% of the queue gets through, it is not a screen.
Decision models, built for the pass alone
A category of model is now sold specifically for the pass: a typed answer to a closed question, nothing else, no prose. TypeSafe announced one called Jev on 2026-09-15, which its launch post describes as public early access, and calls it a System One model. Their docs put the limit plainly: "System One models do not write replies, produce code, or generate explanations of their reasoning." The launch post prices it at $0.042 per million input tokens, with output tokens reported on the response but not billed, a little under 5x cheaper on input than a general-purpose model such as GPT-5.6 Luna. That is a vendor figure on a new product, TypeSafe say it may be subsidised, and we have not measured it.
That limit is why a decision model is not a fourth row above. A model that cannot write a reply cannot drive an agent loop, so screening on one is a different shape of worker, not a cheaper model in the same one: a **decision worker** fetches items, judges each against typed questions, routes on the answer in code, and acts. WorkerKit runs that shape, through the same firewall door an agent worker uses, so the model only sees what the worker was already allowed to see, already redacted. Below its confidence floor it escalates rather than acts. Its meter is the item judged, not the token, so the sums above are the split's arithmetic, not its own.
Two things worth carrying either way: a typed answer guarantees the shape of an answer, not whether it is right, and TypeSafe's data handling terms were unpublished as of 2026-09-16, a question to ask before sending them anyone's messages. The neutral explainer is Jev and decision models; which half of a job each kind of machinery fits is decision models vs agents; the term is system one model.
When not to bother
A screen is machinery, and machinery has to earn its place.
- Volume is low. Under about 50 items a day the saving is cents, against a day of setup and a second worker to keep in step forever.
- The items are cheap. If working one is a single short call with no context pulls, the screen adds a model call to a job that was already one.
- The screen costs what it screens. It pays only on a materially cheaper model, or by skipping materially more work.
- A miss is expensive. This one gets skipped, so it gets its own section.
False negatives are the cost nobody counts
A screen is a classifier with two ways to be wrong, and they are not symmetrical:
| The screen says | The truth | What it costs | Where you see it |
|---|---|---|---|
| Pass it through | Nothing was needed | One wasted expensive run, a few cents | On the receipt, immediately |
| Drop it | It needed action | The item itself | Nowhere |
A false positive is visible and priced. A false negative leaves no trace: no run, no receipt line, no output. The item dropped is disproportionately likely to be the unusual one, which is disproportionately likely to be the one that mattered. That is the exact shape of the customer who churns quietly.
So tune the screen to over-include, and sample the drops: have the screening worker record what it dropped and why, then read that list for two weeks. If it is boring, the screen is good. If not, widen the pass.
Support Inbox Triager and Inbox Triage Assistant are screening-shaped kits whose instruction, app permissions and schedule are already written, so you can read what gets dropped before agreeing to it.
FAQ
How do I reduce the cost of an AI agent that reads a queue?
Stop paying the expensive model to read items it will never act on. In order of effort: filter at the source so most items are never fetched, write the instruction so a clear no ends that item early, then put the reading pass on a cheap model and hand the survivors to the capable one. On an illustrative 500-item queue with a 5% action rate, that last step took a $3.30 daily bill to $0.90.
Should I use a cheap model to filter before an expensive one?
Usually yes, when the volume justifies it and the screening decision is easier than the work. The saving is the price gap: GPT-5.6 Luna is 25x cheaper than GPT-5.6 Sol per token, in both directions. It is not worth it on a small queue, or when deciding needs the same depth of reading as doing.
Does a two-model split lose accuracy?
It can, in one direction. Items the cheap screen wrongly drops never reach the capable model, and nothing records that they existed. Tune it to pass anything it is unsure about, since a wasted run costs cents and a missed item costs the item, and have the screening worker log its drops so you can read them.
Which model should run the screening pass?
The cheapest one that reliably makes the yes or no call for your queue, found by testing rather than reputation. Every kit page carries a grade per model, and you can send a single run to a different model and compare the two receipts on the same items. Start at the bottom of the price list and move up when the drops look wrong.
Can a decision model run the screening pass instead of a cheap general model?
Yes, though as a different arrangement rather than a cheaper model. A decision model cannot write a reply, so it cannot drive an agent loop; screening on one means a decision worker, which judges each item against typed questions and routes on the answer in code, on the same app grants and redaction an agent worker gets. WorkerKit runs that shape, and meters the item judged rather than the token, so the table above prices the two-model split, not this.