How it works
Install @hokusai/router
Use the façade package for app code, or drop to @hokusai/core when you are building a full harness adapter.
Route real tasks
Each task is ranked against the candidate models you explicitly provide; outcomes feed back only when you report them.
Earn a stake
Reported outcomes that measurably improve the router can mint tokens to you. Hold or convert to USDC.
What an integrator could earn
Route first. Then decide how to handle the token flow your harness creates.
Tasks / week
10,000
(projected)
Router lift
+3 DeltaOne
3 percentage points of cost-adjusted task success on the shared coding benchmark
Token Reward
750,000
Current Reward Value
~$75,000
(when fully vested)
Vested tokens can be held or redeemed for USDC at any time. Tokens vest 10% immediately and the remainder over a year. The bonding-curve valuation tracks paid router fees less infrastructure costs; if the router is adopted, fee volume grows, and the token's redemption value grows with it.
Pass through to users. OSS harness maintainers can pass 100% of token flow to the engineers whose tasks generate the data. Turns ownership into a user-acquisition feature.
Keep as revenue. Commercial harnesses can retain some or all of the token flow as a new revenue line that doesn't require a paywall.
Split. Mix the two. Configurable at integration; changeable later.
What the choice layer does vs. what gateways do
Gateways move calls. The choice layer picks which call to make. They solve different problems at different points in the stack — and they compose cleanly.
your harness
Choice Layer
← picks which call to make
Gateway
← delivers it: failover, retry, rate limits
model
| AI Gateways | Hokusai Choice Layer | |
|---|---|---|
| Job | Move the call to a model | Pick which call to make |
| Optimizes for | Latency, cost-per-call, failover, uptime | Task outcome and cost-adjusted success |
| How decisions are made | Rules and fallback chains | Learned from real task outcomes |
| Scope of the decision | Provider, region, retry path | Model per task from your explicit candidate pool |
| How it improves | You update the rules | Automatically, as outcomes accrue |
| What you get | Observability and a unified API | A stake in the model that learns from your data |
Already using a gateway? Keep it. The choice layer sits above your gateway and tells it which model to call.
What we see, what we don't, how you can verify.
What we see
Routing decisions (which model was chosen), outcome signals (test pass/fail, cost, latency), task category embedding, anonymized error class.
What we don't see
Raw source code, proprietary content, customer data, secrets.
How to verify
Open-source SDK; on-chain attribution of contributions and token mint events; auditable outcome log scoped to your account.
Routing request
What the SDK sends to ask for a route: buckets, consent flags, and local redaction metadata.
{
"request_id": "route_req_01JY7P3C0K8X5M2F9A4D",
"sdk_version": "0.9.0",
"consent": {
"routing_enabled": true,
"outcome_reporting_enabled": true
},
"task_summary": {
"language": "typescript",
"repo_size_bucket": "100k-250k",
"diff_size_bucket": "25-75",
"token_bucket": "2k-4k",
"risk_level": "medium",
"capabilities": [
"tool-use",
"refactor",
"tests"
]
},
"privacy": {
"prompt_redaction": "local",
"local_denylist_version": "2026-07-01",
"redaction_markers_emitted": 3
},
"context_buckets": {
"latency_sensitivity": "interactive",
"cost_bucket": "low",
"error_class": "none"
}
}Redacted prompt
Task context after the local denylist strips sensitive spans and replaces them with markers.
{
"request_id": "route_req_01JY7P3C0K8X5M2F9A4D",
"prompt_segments": [
{
"kind": "task_instruction",
"content": "[REDACTED_BY_LOCAL_DENYLIST]",
"reason": "matched_secret_or_identifier"
},
{
"kind": "repository_context",
"file_count_bucket": "10-25",
"token_bucket": "1k-2k",
"semantic_tags": [
"auth",
"middleware",
"policy-engine"
]
},
{
"kind": "acceptance_criteria",
"content": "[REDACTED_BY_LOCAL_DENYLIST]",
"reason": "matched_customer_text"
}
],
"local_denylist_actions": [
"strip_high_entropy_tokens",
"strip_customer_identifiers",
"bucket_numeric_ranges"
]
}Routing response
The router returns the chosen route plus coarse-grained reasons and alternative score buckets.
{
"request_id": "route_req_01JY7P3C0K8X5M2F9A4D",
"selected_route": {
"model": "gpt-5-codex",
"prompt_profile": "patch-focused",
"harness": "wavemill"
},
"alternatives": [
{
"model": "claude-sonnet-4.5",
"score_bucket": "0.70-0.79",
"tradeoff": "higher_latency"
},
{
"model": "gpt-5-mini",
"score_bucket": "0.50-0.59",
"tradeoff": "lower_expected_success"
}
],
"decision_summary": {
"score_bucket": "0.80-0.89",
"reasons": [
"similar_tasks_passed",
"cost_within_target",
"tool-use_match"
]
}
}Outcome report
If you opt in, the SDK reports aggregate task results back as bounded outcome signals.
{
"request_id": "route_req_01JY7P3C0K8X5M2F9A4D",
"selected_route": "gpt-5-codex",
"outcome": {
"task_success": true,
"test_status": "passed",
"latency_bucket_ms": "30000-45000",
"cost_bucket": "low"
},
"attribution": {
"outcome_signal_type": "aggregate",
"contributed_to_policy_update": true,
"outcome_log_scope": "account"
},
"failure_summary": {
"error_class": "none",
"retry_count_bucket": "0"
}
}Where does your routing data go today?
| Lab-owned auto-routing | Hokusai | |
|---|---|---|
| Who pays for routing decisions | The lab keeps it as gross margin | Integrators pay; fees back the contributor token. |
| Who captures the optimization signal | The lab | You and the contributors |
| Who keeps the inference cost savings | The lab keeps margin | You |
| What you build over time | Nothing transferable | A token position in the router |
| Portability across harnesses | Locked in | Take your position with you |
| Auditability | Opaque | On-chain attribution |
Integration
Build on the router now, then go deeper into the protocol mechanics when you need the full economic and attribution model.