Asalebeta

Price and authenticity

Why the price is below vendor list, how far below it goes, and what makes a lane's claim to be selling a given model worth anything.

Two questions — why the price is below the vendor's list price, and why you should believe you are getting the model on the label. Both start from the same fact: whose tokens these are.

Whose tokens these are

Not ours. Asale runs no models and holds no quota.

Every request is served from a real user's own upstream account — their Claude Pro / Max, ChatGPT / Codex, Gemini, Kimi or Grok subscription, or their own API key. It goes out from their machine, and the tokens that come back were really spent on that account. The platform matches, meters and settles.

That shapes both halves of this page:

  • The price can be below list because whoever holds that quota has already paid for it, and the part they will not reach costs them nothing more.
  • Authenticity has to be checked because nothing in the protocol proves the request reached the model on the label — the machine in the middle is not ours.

Price

A subscription is paid for by the period whether or not it is used. Claude Max resets every five hours, and nothing carries into the next window. Quota the holder will not reach has zero marginal cost, so selling it below list is still net revenue. That is the entire source of the discount — nothing subsidised, nobody selling at a loss.

The discount is not fixed. Each model carries a ratio — what fraction of list it sells at right now — recomputed every minute from how hard buyers are pressing on the lanes that are online:

market price = list price × ratio      ratio ∈ [0.10, 1.00]

More sellers than buyers pushes the ratio toward 10%. The reverse pushes it back, up to list price if that is what it takes to bring a higher-priced seller in. So "from 10% of list" is the bottom of the range, not the usual price — check the market page before planning around it.

The platform takes 8% of each settlement and the rest goes to the device that served the request. Algorithm and worked example: How models are priced.

Why cheap tokens often are not the model they claim

Anyone can declare they are selling claude-opus-5. The connection works, the usage field parses, the lane appears on the market. Nothing in the protocol proves those tokens came from the model on the label.

Rerouting to a model that costs a hundredth as much triggers none of the usual checks. That price gap is the arbitrage. Three common forms:

  • a mid-tier model or a quantised mirror answering under a flagship's name;
  • the parameters that make the expensive model expensive stripped off — thinking budget, tool schemas, cache breakpoints;
  • token counts inflated on the way back, so the same answer bills for more.

None of the three leaves an obvious trace. A short reply looks like a short reply.

Before a lane can sell: it sells to the platform first

Attestation cannot prove which binary runs on a stranger's machine. Behaviour can be compared: ask questions whose answers depend on the model that generated them, and see whether the answers look like the model being claimed.

A lane is a (device, provider, model) triple, each verified on its own; a verdict earned on a cheap model never vouches for an expensive one.

  1. The platform buys a dozen times, through the front door

    Same gateway, same dispatch frame, the same path a buyer's request takes, pinned to that one device. The run settles at zero on both sides: no charge, no payout. It does spend the seller's own subscription quota.

  2. Score, and record a verdict

    A score of 75 or above with no hard gate hit is a pass. An inconclusive run, or a low score with no hard evidence, is a watch — still allowed to sell, at ten times the sampling rate and ranked lower. Only a hard gate hit with estimator confidence of at least 0.6 is a reject, which takes the lane off the market.

  3. Buyers cannot see it until it passes

    An unverified lane is matched to no one. This is not "slow to come online": the only way out is for the platform to buy from it first.

An inconclusive run is not evidence of fraud. A statistic that can move a whole grade between two runs is a bad instrument for removing sellers from a market.

After it passes: sampling

An announced test is a test that can be prepared for. So verified lanes are re-probed at moments they cannot predict, through the same front door, indistinguishable from any other purchase:

Share of a verified lane's traffic that is sampled1%
While on watch, or when its account has had a reject10%
Longest gap between samples on a selling lane, however quiet72 hours
How long a passing verdict stands7 days

The time bound matters as much as the percentage. Without it, a lane with no buyers would never be checked — and arranging to have no buyers between samples is something a seller can do.

Samples are paid at market rate. Not out of generosity: an unpaid sample leaves a gap in the earnings record, and a gap is a marker a cheat can watch for. A sample is also spread over close to an hour rather than fired in one burst — twenty-one requests in a fixed order back to back is a shape, and shapes can be recognised.

Compared against peers

With many lanes selling the same model at once, the question does not have to be "is this Opus" in the abstract. It can be "does this lane behave like the other Opus lanes" — easier, and considerably more stable.

Only figures that survive the relay are tracked: how long it writes, how fast it is once generating, accuracy by difficulty band. No prompt content, nothing identifying a seller. A model needs at least eight lanes before its population profile counts. A lane more than three standard deviations out gets a deeper forensic recheck, not a rejection — the first seller of a model, or the only seller in a region, is an outlier and not a cheat.

Why the questions are not published

llm-verify, the engine, is open, and anyone can audit what it asks. That is also its ceiling: a seller being probed can read the same questions, answer those honestly, and route everything else somewhere cheaper.

So the items that actually decide a verdict are generated per run from a server-side seed: multi-step derivations with a single checkable answer, computed locally rather than looked up. The seed goes into the report, so a disputed verdict can be reproduced item by item.

They are deliberately not trivia. Trivia measures the training corpus, and a cheap model with a large one passes it. The fraud worth catching is not noise sold as Opus — that fails the first identity probe — but a mid-tier model or a quantised mirror sold as a flagship, and both answer "who made you" correctly. What separates them is accuracy in the hardest band.

Billing

Pricing follows the usage the upstream vendor reports. Around that:

  • The gateway counts the same request independently and compares the two numbers. A lane whose self-reported figures drift is handled as a metering problem, tracked separately from authenticity.
  • The four token classes are priced separately: input, output, cache read, cache write. A cache read is roughly a tenth of fresh input, and a long agent session is mostly cache reads.
  • A session is pinned to the same seller for ten minutes, because a cache hit only counts against the upstream account that wrote it.
  • Errors, zero-usage responses, disconnects, and a seller dropping before the first byte are not billed. The pre-authorisation hold is computed from max_tokens; it is not a charge, and the unused part comes back.

What this does not solve

  • There is no proof of which binary runs on the other end. All of the above is inference from behaviour, not a cryptographic guarantee.
  • Verification is sampling. 1% of a verified lane's traffic, not every request. A lane that cheats between samples is caught at the next one, not at the time.
  • A watch verdict keeps selling. An inconclusive lane is checked more often and ranked lower, not removed.
  • When supply is thin, this is not cheap. The ratio goes back up to list price. It is a live number, not a promise.
  • It is not end-to-end encrypted. Your request is relayed through another user's client, which can see it. See Security.

The verification engine and the token meter are two separate Apache-2.0 crates on crates.io — the same code that runs here. You can run them against any endpoint, including ours.