Open decision language. Managed execution layer.
The language is yours. The upkeep is ours. The way a model decision is expressed, encoded, and replayed is open and MIT-licensed — the work of keeping it routing in production is what you pay for.
One layer is a specification. The other is an operation.
The decision language is a small, hashable thing: any backend can generate a policy_ir, send it with the call, validate it against the grammar, and run it through a conformant interpreter. Keeping it routing to the cheapest model that passes — over live provider catalogs, real keys, and current pricing — is a service. We open the first and operate the second.
The decision language
Everything you need to express and run a model decision deterministically. A policy_ir is validated against the grammar, fingerprinted to pol_8f41c2 (version sigma-pol/v1), and evaluated filter → rank → select → fallback by any conformant interpreter.
- The policy_ir and flow_ir language and grammar
- Canonical encoding and content fingerprints
- Reference interpreter and conformance tests
- Presets you can copy and adapt
- A self-host path with your own catalog
The execution layer
The host you'd otherwise build and operate yourself — already running. Bring your own provider keys; we keep the catalog current, route every call to the cheapest model that passes, fail over when one degrades, and write the trace. Priced per run, not per token.
- Provider modules and live catalog & pricing data
- Key management and OAuth
- Replayable traces, history, failover, and uptime
- Priced per run, not per token
The grammar holds still. The world it routes over never does.
An open spec can be frozen and trusted. The execution layer can't — and that's exactly why the host is the product, not a lock-in tax.
A policy_ir like ["cmp","bench_intelligence","ge",0.5] means the same thing today and next year — that's what a spec, a canonical encoding, and a fingerprint are for. But the things it routes over change constantly: provider modules drift as APIs version, catalogs gain and drop models, prices move, bench_intelligence scores get re-measured, health checks flip, fallback paths re-order, trace storage fills, and uptime is a continuous obligation.
Self-hosting the open layer is real and supported. The managed host just absorbs that moving surface so you don't run it: maintenance is the product, not lock-in. The language you depend on stays open and replayable either way.
Self-host vs managed comes down to who runs the upkeep — compare the line items on pricing, or start with the grammar, presets, and dry-run endpoints (GET /x/fields, POST /x/rank) in the docs.
Take the language. Let us run the host.
The decision language is open and MIT-licensed — fork it, self-host it, replay it. When you'd rather not operate provider modules, catalogs, failover, and uptime yourself, the managed host does it per run.