Documentation
¶
Overview ¶
Package zen wires the hanzoai/zen serving layer into a cloud binary.
It cannot live in package cloud — it reaches hanzoai/ai/controllers for the warehouse row, and hanzoai/ai imports hanzoai/cloud, so that direction is an import cycle. It lived in package apps for that reason, and the cost was that the composition root's zen entry named an apps-local helper, which plugin/gen-app-cmds cannot express: zen got the fat stub (every subsystem linked) and no manifest row. A sibling package that imports both is legal.
`zen` inside this file is the MODULE (github.com/hanzoai/zen); a package's own name is not in scope within it, so the import owns the identifier.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Mount ¶
Mount mounts zen co-resident in the unified cloud binary. zen is the ONE serving layer for the zen model family; it owns identity, routing, the 1M context ladder, vision, tools, and the Anthropic↔OpenAI codec. ai stays the auth+billing+discovery seam and the /v1/models authority; it no longer carries a parallel zen table or identity prompts. (See hip-00NN.)
zen mounts as a MIDDLEWARE, not a route owner: Claim is scoped to /v1/* and routes every request whose model is a zen SKU to zen's pipeline in-process, calling c.Next() for everything else so ai's /v1/* catch-all serves non-zen models. ONE mount mechanism; the host owns the routes, zen owns the family.
Billing. cloud's edge middleware (serve.go) runs IdentityMiddleware, AuditTrail, ScopeRateLimit, and BillingGate app-wide BEFORE MountAll, so a zen-claimed request is already authenticated, audited, and rate-limited at the edge. But the edge BillingGate prices bare /v1/messages, /v1/chat/completions, and /v1/embeddings at 0 (zen's surface declares cloud.Metered), and ai's OWN in-handler metering — which used to bill zen* — is SKIPPED because zen's Claim runs before ai's beego catch-all. zen therefore bills zen* itself, through the same commerce metering client the edge gate uses, so there is ONE billing source for zen* (never double-billed, never free): zen's Gate authorizes the estimate before the upstream call, zen's Meter records the exact served cost after. zen's Meter/Gate are wired here; ai's edge gate stays 0 for these paths.
Billing granularity is wallet / project / user, mirroring the edge gate's identityFromCtx exactly:
- the WALLET (principal.WalletOf) is the balance key — who PAYS. Its Ledger is the home org, so an admin acting in another org bills the admin's own books, never the org acted on; its Account is the wallet within them, resolved by the ONE rule (account.Payer). A request with no resolvable wallet is refused.
- the project (principal.ValidatedProject) scopes spend caps; a project may carry its own billing account, resolved server-side by commerce from the org's project binding (the X-Billing-Account-Id header only attributes, never redirects spend). Empty is the org-wide default.
- the user (c.User) is the actor for the audit trail.
It is wired BEFORE ai in Wire() so Claim's c.Next() falls through to ai's catch-all. zen's catalog reads its upstream keys from KMS via the Key resolver.
Types ¶
This section is empty.