One app carried the Hanzo shell and twenty did not, so a reader crossing from
base.hanzo.ai to zen.hanzo.ai left the ecosystem and landed somewhere that only
resembled it. Five of those twenty had hand-rolled a footer of their own —
sixteen lines of copyright and a repo link, written five separate times.
Each app now loads the brand tokens before its own sheet, reports through
docs-analytics under its own product name, and renders HanzoFooter from
@hanzogui/shell — the same 6-column ecosystem footer, defined once, that
apps/docs already used.
A footer written inside a layout was chrome pretending to be content, and it is
gone. A footer written inside a page is content pretending to be chrome: those
keep their words and become sections, so each page has one contentinfo landmark
instead of two.
Three manifests listed @hanzo/font twice in the same object.
Builds verified across the four shapes this repo has: a static export, a
next.config.mjs app, a single-page app with no route groups, and one that
already reported analytics. Every one renders exactly one footer.
Co-authored-by: Hanzo Dev <[email protected]>
Thirteen shipped apps and every scaffold in packages/create-app pulled their
face from Google at request time — Inter through next/font/google in the
examples and the four Next templates, Geist and Geist_Mono in the apps, and in
the seven react-router roots a bare <link> to fonts.googleapis.com. That last
one never even applied what it fetched: nothing in those trees set a family, so
the browser downloaded Inter, spent two preconnects on it, and rendered
system-ui. So `create-app` handed a customer a new docs site whose first act was
a third-party font request for a face that is not ours.
The apps read the family back through --font-sans and --font-mono, which are
next/font's handles rather than names of anything, so those follow the binding
over to --font-zen-sans and --font-zen-mono. Eight of them had only ever bound
the mono and were leaning on Tailwind's default for the text face; they now name
both, or swapping the binding would have dropped the body copy to system-ui
without a word.
Zen and ZenMono are built faces, not constructors — subsetting, display: swap
and fallback metrics are already in them — so the call and its options go away.
Across the cloud, insights, bot, engine, ml and router sites the copy read
"SOC 2 compliance", "SOC 2 ready" and "HIPAA / SOC2 ready"; the vault skill
page and its card led with "PCI DSS Level 1" and "PCI DSS-compliant". Hanzo
holds none of these — no report, no auditor, no attestation letter — and
hanzo.ai/trust already says so, so the docs were contradicting our own trust
page. Vault's architecture is the part that was true and it stays: card
tokenization inside an isolated cardholder data environment, which is what
keeps a customer's PCI scope small. The 99.9% uptime SLA on the cloud stat
row goes too; it was a guarantee with no contract under it.
Co-authored-by: Hanzo Dev <[email protected]>
Datastore, SQL, KV and DocumentDB — the four Kinds HIP-0401 through HIP-0404
define. 112 files.
Left as written: DSN schemes, the env an image reads, package and extension
names, version requirements a reader must match, the wire protocols DocumentDB
and KV implement, and the fork provenance and licence on the pages that are
about the fork.
Box art keeps its width.
Our own prose called the analytics store by the upstream's name — "ClickHouse-
powered analytics", boxes labelled ClickHouse in every architecture diagram,
"Hanzo Datastore (ClickHouse)". That now says Datastore.
The line held: a name a reader must type or resolve EXACTLY is a value, not
branding, and renaming it makes the docs wrong. So these stay — the Go module
path, the pip package and the Rust crate, the OTEL exporter component names,
the DSN scheme, /var/lib/clickhouse, the server image's own CLICKHOUSE_USER and
CLICKHOUSE_PASSWORD, and every "Apache-2.0 ClickHouse fork", which is
attribution the licence requires.
Substituting blind produced nonsense the first time — "a Datastore-compatible
engine", "Hanzo Datastore (Datastore)" — so where the vendor carried the fact,
the sentence states the fact instead: Datastore speaks SQL over HTTP on 8123 and
a native binary protocol on 9000, and standard OLAP drivers for either wire
connect without a shim. Box art keeps its width; the borders still line up.
Three things the debrand turned up, each fixed:
commerce reads DATASTORE_URL and nothing else (commerce.go:165), yet the docs
told readers to set CLICKHOUSE_URL, CLICKHOUSE_DATABASE, CLICKHOUSE_USER and
CLICKHOUSE_PASSWORD — and gave http://…:8123 where the code wants the native
DSN on 9000. One DSN now, carrying host, credentials and database.
`kubectl port-forward svc/clickhouse` names a service that does not exist. The
cluster has datastore, hanzo-datastore and insights-datastore.
projects/ mirrored repos that 404 — clickhouse-go, clickhouse-go-mock and
datastore-orm all moved to hanzo-ds, so those pages mirrored nothing and could
not regenerate. Gone, with the nav entries that pointed at them, and the dead
hanzoai/infi.clickhouse_orm entry out of projects.json.
apps/spec is generated from hanzoai/hips and is not fixable here.
Zen and enso are Hanzo's own families. Several surfaces described them by
whose API they imitate, or filed them under a competitor's namespace.
- zen-docs embeddings: drop the "Upstream: text-embedding-3-large by OpenAI"
row that presented zen-embedding as a rebadge; correct dimensions to the
1024 the gateway actually returns.
- zen-docs pricing: Zen was priced as "3x the upstream Fireworks inference
cost", with a claim that every model page discloses its upstream model and
provider. Rates are per model; state that instead. Same framing removed
from platform pricing.
- bot-docs gateway config: "anthropic/zen5" -> "hanzo/zen5"; hanzo is the
provider id Bot actually uses (src/commerce/tier-model.ts).
- zen-docs: curl and the Hanzo SDKs lead; upstream-SDK samples move below a
labelled wire-compatibility section. Anthropic Messages page keeps its
substance, loses the drop-in framing.
- Marketing sites: replace provider/model resell counts used as positioning
with what the product is. Our families lead the model grid; third-party
rows stay, since those integrations are real.
- Neutral placeholder for a proxy key in our own samples.
Provider lists Bot genuinely connects to (LM Studio, vLLM, LiteLLM) are left
alone, as is the zen5 expert-pool table, which is real architecture lineage.
Co-authored-by: Hanzo Dev <[email protected]>
Two independent defects made every documented 'first API call' fail:
1. FICTIONAL MODEL IDS. `zen-omni` and `zen-coder` appear ZERO times in the
live catalog (api.hanzo.ai/v1/models, 440 models). Every SDK sample -
python, typescript, go, cpp, swift, kotlin - told the customer to call a
model that does not exist, so even a correct request 400s. Corrected to the
real ids: zen5 and zen5-coder.
2. DEAD HOST + STALE PINNED MODEL. llm.hanzo.ai is retired and 301s (a POST
returns the literal string 'Permanent Redirect', not a completion), and
`claude-sonnet-4-5-20250929` is long superseded. Both removed: the host is
gone from customer-facing docs entirely rather than documented as retired,
and pinned upstream ids give way to our own current zen5.
50 files. Verified against the live catalog, not assumed.
Our own docs branded a Hanzo product as an 'AI Gateway' (/docs/llm title+H1,
skills index, and ~90 files across docs/bot-docs/cloud). Renamed to 'AI API'
to match hanzo.ai/app/bot. Third-party product names are facts about someone
else's product and are NOT rewritten: 'Vercel AI Gateway' restored verbatim
(same carve-out as LiteLLM); HanzoBot's own 'Gateway' transport untouched.
Pins ghcr.io/hanzoai/static 0.4.1 -> v0.5.1: only v0.5.1 carries 79ac4f9
(serve directory index in place), so docs was the last host 301ing /docs/x/
-> /docs/x/index.html, which poisons Next's router into prefetching
.../index.html/__next._tree.txt — 8 failed requests per page load.
Purge "LLM gateway" / "unified proxy" / vs-LiteLLM framing across all
Hanzo-authored docs, marketing, and skill copy per SDK-ARCHITECTURE brand
rules. Hanzo is a full AI SDK / AI cloud, not a proxy.
- "LLM Gateway" → "AI Gateway"; hero/positioning copy → "one API for every
model". "unified proxy"/"unified gateway" removed from Hanzo copy.
- Drop "Fork of LiteLLM" / LiteLLM-as-backbone positioning. Keep genuine
third-party LiteLLM integration docs, the bot's own WebSocket Gateway
protocol, and functional config keys (litellm_params, LITELLM_MASTER_KEY)
intact.
- SDK links → canonical homes: zen-docs API table (go get
github.com/hanzo-go/sdk, pip install hanzo, npm i @hanzo/ai, cargo add
hanzo); org preset SDK entries point js-sdk→hanzo-js/sdk,
python-sdk→hanzoai/python-sdk (flagship).
Generated/synced trees (apps/spec/content/docs HIP corpus and
projects/hanzoai/bot, both gitignored) are out of this repo's committable
scope — their brand fix belongs in the source repos.
Co-authored-by: Hanzo Dev <[email protected]>
The cloud API now sits behind one front door (ingress -> gateway -> cloud).
api.cloud.hanzo.ai / cloud-api.hanzo.ai / functions.hanzo.ai are redundant
aliases routing to the same backend, so migrate clients to api.hanzo.ai.
- docs + bot-docs lib/hanzo/client.ts, scripts/update-hanzo-index.ts:
search/index/chat-docs default base cloud-api|api.cloud.hanzo.ai ->
api.hanzo.ai (RAG paths stay /api/* — served there per cloud AUTH_PUBLIC_PATHS)
- cloud landing page.tsx: curl base + request-flow label api.cloud.hanzo.ai ->
api.hanzo.ai
- functions.mdx (x2): collapse Endpoint+Gateway to one canonical
api.hanzo.ai/v1/functions/*
- hanzo-openapi.mdx: Cloud endpoint label api.cloud.hanzo.ai -> api.hanzo.ai
Non-breaking: the aliases still resolve to the same backend.
zeekayandHanzo Dev