Cheap Claude API: how to vet a discounted provider or relay

A service that sells Claude at a tenth of the list price may not say where its tokens come from, and the response gives you little to check, because the service writing it also writes the model field and the token counts.

Researchers at CISPA measured how often that matters in Real Money, Fake Models, accepted at ACM CCS 2026. They found 17 "shadow APIs" cited in 187 academic papers and audited three of them against the official APIs. On those three they report performance divergence of up to 47.21% and identity verification failures in 45.83% of the fingerprint tests, evidence they describe as consistent with deceptive model claims in some of the audited endpoints. Four of the 17 services had already shut down when the paper was written.

Compare the relay with the official route on your own prompts

The response metadata cannot settle which model answered, so the test has to run on outputs. Take a few dozen prompts from your real workload, include some with an unambiguous answer, and send each one to the official API and to the candidate with identical settings. Score both with the same checker and compare pass rates. Wording differs even between two official calls, so compare scores and not exact strings.

A sample that small separates a substitute that fails often from the official model. It cannot resolve a gap of a couple of points: that takes many hundreds of prompts, and at that size the testing may eat the savings.

I add two probes. A long prompt near the context window the relay advertises, with a question about its first lines, catches a silently truncated context. And the same text with no system prompt, sent to the relay and to Anthropic's token-counting endpoint, shows how the prompt token counts compare: a small constant difference can come from instructions the relay adds, while a gap that widens with the length of the text points to a different tokenizer. I read the second result as a strong warning and confirm it with the pass-rate comparison, because a different tokenizer does not by itself prove a different model.

I rerun the suite on a schedule with a small sample. A relay can change what it forwards without telling its customers, and a single pass only covers the day it ran.

Read the data policy before the price list

I ask for the retention period, whether prompts train a model, and where they are stored, and I compare the answers with what a cloud provider publishes for the same model. If the answer comes only in a chat message, I treat the policy as undeclared, because it is not something I could show an auditor. A provider that declares its policy in a public, machine-readable place is easier to audit than one that answers per request.

For uptime I want a measured figure over a stated period. I keep a fallback route in the client so an outage or a shutdown does not take the feature down, and I keep prepaid balances to a few weeks of use. I also check that each charge can be reconciled against the token counts of the request.

Where I would use a discount, and where I would not

My test is whether anything breaks if the prompt and its answer are published tomorrow, and if the answer turns out to come from a weaker model than advertised. Tagging public GitHub issues passes: the input is already public and a wrong label costs a maintainer a click. Generating synthetic test inputs passes when a validator rejects the malformed ones before they reach a test suite. That validator only catches malformed output, so subtle quality loss in valid output still needs a sample you review by hand.

A discount also has to survive its own retries. Take illustrative numbers: if a validator rejects 4% of the outputs on the regular route and 30% on a half-price route, an accepted output costs about 1.04 units on the first and 0.71 on the second. The bill falls by roughly 31% instead of 50%, and the figure moves with your validator. Divide spend by accepted outputs, the same measure the complexity routing post uses for model choice.

I would keep customer data, personal data and anything under a data processing agreement on regular routes, or on zero data retention routes. I would also keep agents with access to valuable systems there: a coding agent can send any file it reads, .env included, and a tool-calling agent turns model output into actions that were tested against one specific model. Model evaluations belong on named regular providers too: comparing candidates for production through an endpoint that may not serve the model it names is the risk the CISPA paper raises for the 187 papers that used such endpoints.

Opt-in discounted routes on AIVAX

AIVAX groups the routes that serve a model at a discount as special providers, and the catalog marks each route with its group, so a discounted route is always identifiable as one. Routing applies four rules to that group:

1. Balanced, the default preference, never selects a special provider.
2. Cheapest, Fastest and Quality consider them only when the account enables Allow special providers in its privacy settings. The setting is off by default.
3. The Special preference always considers them and picks the lowest combined input and output price, breaking ties by reported uptime and then by recent failures.
4. Naming a special route's tag in allowed_providers, or as a #tag suffix on the model name, routes to it under any preference.

I would leave the account setting off, because it applies to every gateway that uses Cheapest, Fastest or Quality, and give the workloads that passed the test above a gateway of their own:

{
    "name": "Public-data batch",
    "parameters": {
        "baseAddress": "@integrated",
        "modelName": "@anthropic/claude-5.5-sonnet",
        "routingOption": "Special"
    }
}

On a single request to POST https://inference.aivax.net/v1/chat/completions, the same choice goes in routing_options.preset, a field OpenAI-compatible SDKs send as extra body. To run the comparison from the first section against one discounted route, name its tag in the model, as in @anthropic/claude-5.5-sonnet#grand-anak-jade, and compare the result with the same model on #anthropic. For a gateway that should stay on routes you have vetted, list their tags in allowed_providers and leave out the "*" wildcard. The request then fails when none of them is available, and a retry after a provider fails before answering stays inside the same rules.

"routing_options": {
    "preset": "Balanced",
    "allowed_providers": [ "anthropic", "amazon-bedrock", "google-vertex-global" ]
}

Every response for an integrated model carries a provider field with the tag of the route that answered, in each chunk when streaming, and the call is billed at that provider's price, as covered in how to get the cost of each LLM API call. The public catalog at https://inference.aivax.net/api/v1/information/models.json needs no key and declares each route's group, price, uptime and data policy, in technicalInfo.dataCollection. Tags change, and the grand-anak-* special routes were renamed on 6 November, so the audit below reads the special tags from the catalog instead of hard-coding them:

const catalog = await fetch("https://inference.aivax.net/api/v1/information/models.json")
    .then(response => response.json());

const specialTags = new Set(
    catalog.data
        .flatMap(family => family.models)
        .flatMap(model => model.providers ?? [])
        .filter(provider => provider.group?.includes("Special"))
        .map(provider => provider.routingTag)
);

function checkRoute(completion, gatewayName) {
    if (specialTags.has(completion.provider)) {
        console.warn(`${gatewayName} was served by special route ${completion.provider}`);
    }
}

For sensitive data, use regular routes or turn on Zero data retention providers only, which removes every route not declared zero data retention before the other rules apply. A few models have no regular route, and a request for one fails until you allow special providers, with an error that names the two ways to do it.

Checked against the AIVAX docs and implementation on November 10, 2026.