HIP-124: Bring-Your-Own Provider & AI — Unified Dashboard and Usage. Status Active. Hanzo's own standard — read this before implementing against it.
This HIP specifies the customer-facing composition of the Hanzo cloud: a customer brings their own cloud provider, brings their own AI models and keys, and sees one dashboard with one metered usage ledger at console.hanzo.ai. It defines no new machinery — each leg is an existing HIP, referenced not duplicated:
on the customer's own credentials (HIP-0123).
unified AI provider interface, the gateway (HIP-0004).
drawdown, and balance-floor gating in console.hanzo.ai (HIP-0018 billing; HIP-0038 for the SuperAdmin cross-tenant board).
Composed, this is the resell-ready OSS AI cloud: the customer supplies the two expensive inputs — compute and model access — and the platform supplies identity, scheduling, metering, and a single pane of glass.
The org connects compute through the ONE fleet surface (/v1/clusters, HIP-0121): a managed cluster, a pasted kubeconfig, a GPU box, or their own AWS/Azure/GCP/DO/Hetzner/Nebius account with credentials sealed per-org in KMS. Visor (HIP-0123) provisions and autoscales on that fleet — for BYOC, in the customer's account, so their cloud bills them for nodes and Hanzo meters only the management plane (HIP-0121's 1% / $1 / validator-free tiers). Nothing in this leg is new here; conformance means no second attach surface and no second scaler ever appears in a product UI.
The gateway (HIP-0004) is the unified AI provider interface: OpenAI, Anthropic, Google, self-hosted engines, and every other backend are providers behind one API, one model-routing table, and one credential store. BYO AI means the org registers its own provider keys (or points at its own hosted models) and every downstream product — chat, agents, ML pipelines — consumes them through the same gateway surface with the org's identity attached (HIP-0026). Platform keys and customer keys ride the same interface; whose key served a request is an attribute of the usage record, never a separate code path.
console.hanzo.ai is the single self-service pane (per-org); its admin sibling is the SuperAdmin-gated cross-tenant board (HIP-0038, HIP-0118). Verified live this cycle:
on the reference org at verification), rendered with credit drawdown against the org's balance.
(?product= / ?groupBy=product, hanzoai/cloud #159) — AI, compute, storage, and every metered product report into one ledger, one drawdown.
HTTP 402 at the platform edge (HIP-0106 realized state; HIP-0018 semantics). Usage views and enforcement read the same ledger.
The conformance rule is the DRY rule: one metering path (commerce/metering, per HIP-0121), one ledger per org, one invoice — whatever mix of BYO provider, BYO AI, and platform-native usage produced the charges. A product that meters outside that path, or a dashboard that aggregates from anywhere but that ledger, is nonconformant.
api.hanzo.ai surface), the fleet attach surface and nominal-fee metering (HIP-0121), console per-model usage with drawdown and the per-product axis, and 402 balance-floor gating.
BYOC 1% and monthly device billing loops (HIP-0121 roadmap), cross-provider per-tenant scale execution (HIP-0123), and the unified cross-tenant fleet+revenue admin board (HIP-0121 roadmap, HIP-0038 surface).
models/providers/keys)
gating)
on every usage record)
realized metering + balance-floor edge)
cross-tenant view)
sealed credentials, billing tiers, one metering path)
(elasticity on the customer's provider)
hanzoai/cloud #159 — per-product usage axis (?product= / ?groupBy=product)
Copyright and related rights waived via CC0.