How it works
Connect your workflow
Use a plugin, harness adapter, SDK, or direct API call from the environment that already runs your coding tasks.
Ask for a route
Pass the candidate models your system can actually run. Model Match scores that pool and returns the recommended model for the task.
Earn a stake
Report coarse outcomes after execution. When those outcomes measurably improve Model Match, they can mint HROUT to you.
What an integrator could earn
Route first. Then decide how to handle the token flow your harness creates.
Tasks / week
10,000
(projected)
Model Match lift
+3 DeltaOne
3 percentage points of cost-adjusted task success on the shared coding benchmark
Token Reward
750,000
Current Reward Value
~$19,986
(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 Model Match fees less infrastructure costs.
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 Model Match does vs. what gateways do
Gateways move calls. Model Match advises which call to make, from beside your harness, never in the request path. They solve different problems and compose cleanly.
Model Match
your harness
Gateway
failover, retry, rate limits
model
| AI Gateways | Model Match | |
|---|---|---|
| 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. Your harness asks Model Match which model to use, then sends the call through your gateway as usual.
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 Model Match |
| Portability across harnesses | Locked in | Take your position with you |
| Auditability | Opaque | On-chain attribution |
Integration
Build on Model Match now, then go deeper into the protocol mechanics when you need the full economic and attribution model.