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 Classify this ticket as billing, bug or feature request: my invoice was charged twice tenant acme, endpoint /chat, 20 tokens in WHAT WAS MEASURED, BEFORE ANY MODEL SAW IT feature value adds to score ------------------------------------------------------------- kind of task classification +0.050 length of request 20 tokens +0.001 answer length needed 8 tokens +0.001 maths in it no +0.000 code in it no +0.000 needs live lookup no +0.000 vagueness 0.29 out of 1 +0.057 ------------------------------------------------------------- complexity score 0.109 WHERE THAT SCORE LANDS under 0.30 small model <- this request under 0.60 medium model under 1.00 large model chosen: small (cheapest of the three) why: score 0.11 falls in the small band rules applied: band:small THE CALL, PRICED AGAINST THE OTHER TWO TIERS model tokens in tokens out cost usd --------------------------------------------- small 37 20 0.000018 <- used medium 37 20 0.000070 large 37 20 0.000411 this request cost $0.000018 $0.000393 less than always using the most expensive model (96% cheaper) this is already the cheapest model, so there is nothing to save 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 small score 0.11 falls in the small band enterprise, normal chat medium score 0.11 put this in small, raised to medium by the enterprise tier floo batch, overnight backfill small score 0.11 falls in the small band 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.000063, 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 small served 2 0.000018 28% allow small served 3 0.000035 56% allow small served 4 0.000053 83% allow small served 5 0.000070 111% refuse - refused stopped at $0.000070 of $0.000063: acme has spent $0.0001 of a $0.0001 daily budget this request already routes to the cheapest model, so there was nothing to downgrade to and the guard went straight from allowing to refusing 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 small model is returning HTTP 503 for every call order it will try: small then medium then large (nearest capability first, so an outage does not quietly become a quality cut) request 1: small failed then medium ok -> served by medium request 2: small failed then medium ok -> served by medium request 3: small circuit open then medium ok -> served by medium circuit breakers now: small open, medium closed, large closed once the breaker opens, later requests skip the dead model without paying for a call that was going to fail