How serving works

You never touch a GPU. Training produces a small steering artifact, and our runtime applies it inside the open model on every generated token.

Training produces a steering artifact

We create same-prompt examples of responses that fit and violate your policy, measure their internal activations, and average the difference into a policy direction. The artifact records that vector, its model fingerprint, layer, and strength. It is cheap to retrain and deploy.

Steering runs inside the model

The GPU runtime loads the open model once and can serve many customer vectors. During generation it adds your direction at the selected residual layer. The policy is not sent as a system prompt and the response is not rewritten after generation.

The gateway in front

your app ──▶ OpenSteering gateway ──▶ managed GPU runtime
                │                                   │
         checks API key                  base model + your vector
         meters tokens                              │
                └──────────── response ◀────────────┘

Every request passes through the OpenSteering gateway.

Authenticates. Your os_ key is checked at the gateway. Provider credentials never reach you, and your key never reaches the provider.
Routes. The model field in the request selects your steering artifact on the shared fleet.
Meters. Input and output tokens are counted per request and feed straight into usage and billing.

The endpoint is the contract

api.opensteering.com is the stable surface. As volume grows, serving can move between managed and dedicated GPU capacity while your endpoint, key, and code stay unchanged.