TeeRouter

An enterprise that wants AI on sensitive data picks between a lab API such as OpenAI, a router such as OpenRouter, and buying its own GPUs. None of them is satisfactory. The first two can read the data, and the protection is a contract. Owned GPUs are a capital risk, with fixed capacity that doesn't grow with demand.

TEE providers are the way out. They run open-weight models inside hardware enclaves (CPU TEEs plus confidential GPUs) and let clients check what runs before sending data. Most buyers don't know them yet. Those who try one, as we did for our own product, find that a single provider is sometimes unstable, unavailable or too slow. Each provider also ships its own SDK and its own idea of "verified", so failing over usually means another integration and, often, a quietly weaker route.

At that point the buyer needs a load balancer that still verifies every route. That is build or buy, and TeeRouter is the buy.

A TEE route fails like any API: errors, timeouts, slow tokens, rate limits. A gateway that refuses unverified routes adds a second kind of failure: expired evidence, a release not yet endorsed, or an attestation endpoint that moved. Generic gateways such as LiteLLM or OpenRouter can't see the second kind, and today it is common.

Several products already route to TEE providers: TrustedRouter, RedPill, AnonRouter, NanoGPT and PPQ. What separates them is where your prompt becomes readable on the way to the model.

The open gap: nobody combines verification on your side, encryption all the way into the provider enclave and health-aware failover across at least two independent operators, with tools and streaming.

TeeRouter's optional hosted endpoint is the exception, and it is labeled as one. It decrypts inside TeeRouter's attested gateway, which makes it a two-place route like the middle row. The strict preset forbids it.

The key and cap columns matter only for the later one-invoice option. In the alpha you use your own keys. Watch the details: "zero" means no cap at Tinfoil but disabled at Venice, and Privatemode budgets reset every calendar month. Each provider needs its own adapter.

GLM-5.3 is the strongest model both alpha providers serve, but they run different 4-bit quantizations of it. A strict policy approves both builds explicitly as one class, and the alpha measures quality and tool-call parity before failing over between them. Names alone prove nothing: NEAR AI's catalog maps a request for DeepSeek-V4-Flash to GLM-5.3-Flash.

Verification, jurisdiction and redundancy are separate settings, so the product never promises failover where none exists. In production the gateway runs as a Kubernetes service or sidecar, or as a confidential lane inside an existing AI gateway such as LiteLLM.

A hosted, attested endpoint lets people start by changing one URL. It decrypts inside TeeRouter's attested gateway, so it is a second place your prompt is readable. Every hosted response is labeled as a lower tier, and strict forbids it. Move to the local gateway when your security review asks for it.

Closest precedent: Confident Security. It runs OpenPCC, an open-source version of Apple's Private Cloud Compute, on its own fleet. The client verifies each node against a public build log, and requests go through a third-party relay so the operator can't link them to you. It charges twice the market rate and backs that with a money-back warranty, unlimited indemnification and unlimited liability. That premium is risk transfer, which only works when you own the enclaves. TeeRouter can't underwrite other companies' enclaves, so it competes where owning a fleet falls behind: Confident Security's public model list dates from July 2025, and its open-source repo hasn't changed since January 2026.

Market size. Winning all of today's TEE inference at OpenRouter-like fees would be roughly $2.5–7.5M a year, so the fee can't fund the company; subscriptions have to. The bet is that the market grows as buyers move off lab APIs and owned GPUs.

Watch: OpenAI announced a Private Inference preview for this fall without verification details. Google open-sourced an attested-TLS Prompt Encryption SDK in June. Many buyers may reach "TEE" through OpenAI first. TeeRouter adds such endpoints as routes, with an open-weight model as a policy-approved fallback, and labels "trust us" versions honestly.

This comes after the alpha. At first you bring your own provider keys. One invoice opens per provider once it has signed a written resale agreement and enforces per-key rate limits.

TeeRouter creates one provider key per project and provider through the provider's admin API. Each key has a spend cap, and each cap works like a card pre-authorization hold on your TeeRouter balance. Caps are only raised out of money that is still available, so the open caps can never exceed what you have. Prepaid mobile data has worked this way for decades.

What it needs from a provider

• A written agreement that permits resale and covers your data classes.
• An admin API to create, update and revoke keys, usable by a machine.
• Spend caps in currency, ideally lifetime caps that never reset.
• Usage per key, fresh within about a minute.
• Per-key rate limits and model allow-lists, which turn soft caps into tight bounds (see below).

Providers check a key's cap against usage that has already been recorded when a request starts. Tinfoil documents this, and NEAR AI's source code does the same. Requests that are still running when the cap is crossed finish and are billed.