Type a request and see which size of model it gets sent to, why, and what that choice costs against the alternatives.
Type anything you would ask an AI assistant. The page measures the request before any model sees it: what kind of task it is, how long the answer needs to be, whether it involves maths or code, and how vague the wording is. Each of those adds to a single score, and you can see exactly how much each one contributed.
That score picks one of three model sizes. The page then really calls that model and prices the call, alongside what the cheapest and the most expensive model would have charged for the same request, so the saving or the overspend is a number rather than a claim.
It also shows the rules that can overrule the score: a customer who pays for the big model regardless, an overnight batch account capped at the cheap one, and endpoints pinned to a fixed size. Then it replays your request twice more, once against a deliberately tiny spending cap so you can watch it get downgraded and then refused, and once with the chosen model returning an error so you can watch it fall back to another one.
THE REQUEST translate hi to French tenant acme, endpoint /chat, 5 tokens in WHAT WAS MEASURED, BEFORE ANY MODEL SAW IT feature value adds to score ------------------------------------------------------------- kind of task summarisation +0.250 length of request 5 tokens +0.000 answer length needed 200 tokens +0.025 maths in it no +0.000 code in it no +0.000 needs live lookup no +0.000 vagueness 0.30 out of 1 +0.060 ------------------------------------------------------------- complexity score 0.335 nothing in the wording said what kind of task this is, so it was treated as middling difficulty and routed on length and vagueness alone. Knowing how often that happens matters more than the classifier looking clever. WHERE THAT SCORE LANDS under 0.30 small model under 0.60 medium model <- this request under 1.00 large model chosen: medium (middle of the three) why: score 0.34 falls in the medium band rules applied: band:medium THE CALL, PRICED AGAINST THE OTHER TWO TIERS model tokens in tokens out cost usd --------------------------------------------- small 22 5 0.000006 medium 22 5 0.000025 <- used large 22 5 0.000141 this request cost $0.000025 $0.000116 less than always using the most expensive model (82% cheaper) 4.0x the cost of always using the cheapest model, which is the quality insurance being paid for the three models behind these tiers are the same offline model with different names and different price tags, so the money is real arithmetic and the quality difference is not simulated THE SAME REQUEST UNDER THE RULES THAT OVERRULE THE SCORE account and endpoint model why -------------------------------------------------------------------------- acme, normal chat medium score 0.34 falls in the medium band enterprise, normal chat medium score 0.34 falls in the medium band batch, overnight backfill small score 0.34 put this in medium, capped at small by the batch tier ceiling acme, labelling endpoint small endpoint /classify is forced to small acme, code endpoint large endpoint /codegen is forced to large a request pinned by hand on the way in beats all of these, for the engineer who needs one call on a known good model right now WHAT HAPPENS WHEN THE ACCOUNT RUNS OUT OF MONEY daily cap set to $0.000091, under four of these requests, so the whole arc is visible in a few lines request spent so far of cap decision model result -------------------------------------------------------------- 1 0.000000 0% allow medium served 2 0.000025 28% allow medium served 3 0.000050 56% allow medium served 4 0.000076 83% downgrade small served 5 0.000082 90% downgrade small served 6 0.000088 97% downgrade small served 7 0.000095 104% refuse - refused stopped at $0.000095 of $0.000091: acme has spent $0.0001 of a $0.0001 daily budget the guard drops to the cheap model at 80 percent of the cap and only refuses at 100, so an account gets a worse service before it gets an error instead of working perfectly right up to the cut off WHAT HAPPENS WHEN THAT MODEL IS DOWN the medium model is returning HTTP 503 for every call order it will try: medium then large then small (nearest capability first, so an outage does not quietly become a quality cut) request 1: medium failed then large ok -> served by large request 2: medium failed then large ok -> served by large request 3: medium circuit open then large ok -> served by large circuit breakers now: small closed, medium open, large closed once the breaker opens, later requests skip the dead model without paying for a call that was going to fail