Product

The gateway platform

An OpenAI-compatible multi-model gateway. Requests are decided, executed, billed and recorded in this layer; this page states what each of the four parts is responsible for.

The endpoint

The protocol is OpenAI-compatible: change base_url and existing clients keep working. The service model name enthalpy-1 means the gateway chooses; a real pool model id skips routing and pins that model.

Integration docs →

Decision records

Each call's candidate table, every attempt and every refusal reason go to route_decisions; the enthalpy_route object in the response carries the same information. Any decision can be retrieved in the console by request_id.

How decisions are made: the engine →

The ledger

Billing is itemised on actual upstream usage, to 1e-8 of a dollar; every entry expands to token counts, and reconciliation differences are listed separately.

The billing basis →

The console

Key issuance and revocation, quotas and rates, usage rollups, decision and audit records, provided with the account.

Open the console →

4ROUTER / SYSTEMS RESEARCH

Connect configuration choices to system behavior.

Understand how operators, KV state and scheduling shape an inference path.

Read the systems notes in Resources
GEMM / KERNELS

From operators to serving: cuBLAS & cuDNN

Identify the limiting resource before selecting the implementation.

STATE / CAPACITY

KV cache: from tensor shapes to capacity budgets

Context length is a state budget that grows with concurrency.

SCHEDULING / SLO

From prefill to decode: designing the scheduling experiment

When throughput rises, know which requests are waiting.

Let’s talk infrastructure.

Connect to the platform, or discuss models, performance and deployment.