hyper: the first-party provider

The house provider that seeds liquidity and serves as the audit reference. No routing favoritism, by design.

Plainly, before anything else: hyper is a design, not a deployment. It exists today as a spec (designs/hyper.md) for a first-party provider running its own GPUs, and it is not yet serving traffic. This page exists because a market operator planning to compete in its own market owes everyone an explanation before it happens, not after.

Why a first-party provider at all

Three reasons, and each is a hard requirement somewhere else in the system. First, cold-start liquidity: a two-sided market with no providers clears nothing, and one provider the operator controls makes the book liquid from day one. Second, the verification layer needs a reference: sampled audits compare providers' outputs against a known-good deployment of the same open-weight model, and hyper is that deployment. The audit reference and a revenue-earning provider are the same GPUs. Third, proof of the thesis: the whole pitch is that a well-utilized self-hoster clears below posted-price routers, and hyper is where that gets measured on the operator's own P&L before third-party providers are asked to believe it.

Same code, same rules, zero favoritism

hyper is a provider, full stop. It runs the same self-hosted branch of provider-quoter.ts every third party runs, with manual floors set to its measured marginal cost and the quoter reading its own serving metrics. It signs quotes, gets scored, gets metered, gets audited, and reconciles to zero like everyone else. There are zero router changes for it and zero routing favoritism toward it: no scoring preference, no audit exemption, no capacity carve-out. The design states the discipline as a falsifiable rule: if hyper needs a router change to compete, the market design is wrong, and the fix belongs in the mechanism, not in a carve-out.

The neutrality claims are deliberate and checkable. Not favored: the canaries that catch model substitution point at hyper first, publicly, because a first-party provider quietly quantizing to cut cost is exactly the abuse they exist to catch. Not closed-model: open weights only, which the audit reference requires anyway. Not markup-priced: marginal-cost floor plus the utilization curve, never a list price, so if a rival clears below hyper's marginal cost, hyper loses that request, as it should.

Success is being out-cleared

If hyper ended up the only liquid provider, Omnious would be a reseller with extra steps. The design names that failure mode directly: hyper is a bootstrap, not a destination, and its success criterion is third-party providers out-clearing it on real traffic. Its one durable edge is meant to be earned in the serving stack, not the market: a high prefix-cache hit rate lowers its real cost and wins sessions under the same rules available to every provider that invests in caching.