Docs / Hanamy platform / Start here

What is the Hanamy platform?

The Hanamy API, CLI and controls in one developer workflow.

Copy as Markdown

Hanamy is the model routing platform. Explore models, compare responses, or connect directly from your own tools. Use the CLI in your local workspace or send requests from your application. Client keys connect the work to your wallet; limits and routing give you control over how requests are allowed and routed.

Choose your interface

The Hanamy CLI provides a terminal client with streamed responses, local file tools and explicit approval for writes and commands. The Responses API lets your application own the interface, conversation state and tool execution.

One working path

Follow a request from its credential to its final receipt. Each stage answers a different operational question.

Authorization: Bearer $HANAMY_API_KEY

x-mw-quiver: daily_tokens=2_000_000; rpm=60

"model": "claude-opus-5"

"usage": {"in": 812, "out": 1344, "wallet": "0x47d6…47cb"}

Interactive walkthrough · no requests are sent

Controls that fit the work

Use a separate key for each integration so you can rotate or revoke it independently. A quiver limits what the key can use. Strategies describe supported routing choices; their availability depends on the deployment and the request path. A browser draft does not automatically become an API routing policy.

Begin with a small request

Follow Get connected to choose a path, then inspect the result and its usage. Keep the first request small enough that a failure is easy to understand. Expand the task after the connection and controls are working.

• Rate limits are counted against the wallet, not the key, so a second key does not buy a second allowance.
• A sustained overrun returns 429 with a retry-after you should actually honour.
• A model listed as queued rather than live returns 404 model_not_in_pool. Nothing is silently substituted.

Open the platform

Work in your terminal

The CLI reads the same client key from HANAMY_API_KEY and streams to stdout, so it composes with the tools you already have.

# the register, as JSON
mw models --json | jq '.[] | select(.status=="live") | .id'

# one prompt, two models, side by side
mw compare -a claude-opus-5 -b gemini-3-pro "explain a bonding curve"

What is not kept

There is no conversation object in this front end. Each send builds a request from the one message in the box and nothing else, so the array that reaches the endpoint has exactly one entry in it. Send again and the previous exchange is overwritten in the page, not filed away. The receipt under the panel prints the request from the same object that was posted, so you can read what left rather than take our word for it.

• No history. Nothing you type is written to localStorage, sessionStorage, IndexedDB, a cookie or a server of ours.
• No thread. The model is never told there was an earlier turn, because there is no earlier turn to tell it about.
• No account. There is nothing to log into, so there is nothing to attach a transcript to.
• Two things are kept, both on your device: your colour mode, and the endpoint and key you chose so you need not retype them. The register page lists them by reading your browser, and the button beside the list clears them.

The hosted endpoint

A deployment can carry one key of its own, set as HANAMY_KEY (and HANAMY_UPSTREAM if the provider is not OpenAI). The browser never sees it: requests go to this site's /v1, which adds the key and forwards them. Nothing that passes through is written down, and the rate limit that protects the key counts addresses in memory, so those counts die with the process. Without that variable the site still works and simply asks each visitor for an endpoint of their own.

The limit, stated plainly. This page keeps nothing. What happens to a request after it reaches the endpoint you named is that endpoint's business: most providers log requests for some period, and no front end can promise otherwise. If that matters, read the retention policy of the API you point this at. The guarantee here stops at the edge of the browser, and anyone who tells you their web page can extend it further is selling something.

Why this exists

Model choice is an operational decision, not a matter of taste, and it is made badly when the only way to compare two answers is to keep two tabs open. The comparison stays free because the choice has to be cheap to make. The pool exists so that the same choice survives into production without a second account, a second invoice and a second key per lab.