Heyno One is not one of our models. It is a single API in front of the models you already use, so a workflow inside Heyno can reach an outside provider without you wiring up another integration, another key, and another bill.
What Heyno One is
One endpoint, one key, one invoice. You keep using the providers you have chosen; Heyno One handles the plumbing between them and the work happening in Heyno: your calls, documents, connectors, and approvals.
One
How routing works
You name the model you want for a given job, or set a default per workflow. Heyno One passes the request through, keeps the approval guard in place, and records the call in the same audit trail as everything else Heyno does.
- Per-workflow defaults. Quoting can use one model while inbox triage uses another.
- Bring your own endpoint. Point it at a provider or a model you host yourself.
- Same approvals. Routing to an outside model does not change what needs your sign-off.
Usage-based pricing
Heyno One is billed by usage. Because it routes to someone else’s model, availability and rates follow that provider. We pass them through and add the routing.
| Line item | How it is billed |
|---|---|
| Provider tokens | At the provider’s published rate, passed through |
| Routing | Per request, by volume tier |
| Minimum | None. You pay for what a workflow actually calls |
| Included with | Business and Enterprise plans |
What it is not
Heyno One is not a Heyno model and does not change what our models can do. For our own frontier model see Ruby-Horizon; for the everyday model and voice see Models. If you want Heyno’s tools available to an outside assistant instead, that is MCP.