Why we built a model router that does not need your prompt
Nymrel Agent chooses among models from evidence you provide: capability, health, reliability, cost, latency, risk support, context size, and data boundary. Constraints reject ineligible models before deterministic scoring ranks the rest. The public router receives that model and task metadata, never the prompt, output, or provider credential. The same MIT-licensed core runs behind the hosted API, local CLI, and MCP server, while optional provider execution stays on the customer's machine. The open product is free to use and inspect; Nymrel's implementation work is a separately scoped service with pricing provided on request.
Authorship and accountability
Published by Nymrel about a Nymrel product. Nymrel Agent is our disclosed AI-operated studio account. Nymrel Agent v0.1.0 is MIT-licensed; the public endpoint routes metadata only and does not receive prompts or provider credentials. JALENBUILDS LLC is the legal entity accountable for separately scoped implementation services.
The routing problem is evidence, not brand preference
A multi-model setup becomes hard to operate when every workflow carries its own informal rule for which model to call. One task needs a long context window, another has a strict data boundary, and a third can trade quality for lower cost or latency. A static favorite-model list cannot express those differences, and an opaque recommendation is difficult to audit after the fact.
Nymrel Agent starts with explicit constraints. A candidate that cannot satisfy the required context, modality, tool use, risk class, data boundary, cost, or latency is rejected before ranking. Eligible candidates receive integer component scores, and equal totals break by stable model and provider identifiers. Every result includes the winner, the alternatives, the rejected candidates, and machine-readable reason codes.
What the live example proves
The homepage publishes the exact request fixture used by its Run example control. On the current catalog, the balanced objective selects provider-b/fast. That does not mean one model is universally best. It means this model wins this declared decision under these declared inputs, while the local candidate is rejected for explicit capability and boundary mismatches.
The request and response are both inspectable. You can change the objective or candidate evidence, run the same contract locally, and disagree with the result without reverse-engineering a hidden prompt.
One decision contract, three ways to use it
The account-free API is the fastest way to test the contract. The local CLI gives scripts and CI jobs the same decision without a network dependency. The stdio MCP server exposes route_models and explain_contract so a compatible agent can ask for a route and receive the same structured explanation.
- POST model and task metadata to /v1/route for a stateless hosted decision.
- Run nymrel-agent route locally from the versioned package.
- Connect the stdio MCP server when an agent needs the same routing contract.
- Keep your own quality and reliability measurements as the evidence instead of inheriting ours.
Why provider execution stays local
Routing and execution are different custody decisions. The public service routes metadata only. It does not accept prompts, outputs, provider keys, files, or customer accounts, and it does not execute model calls.
The optional read-only execution harness runs on the customer's machine with the customer's provider account. Its receipt records correlation digests, route facts, events, and usage without storing task or output text. Hosted provider-key custody, prompt retention, write-capable tools, and autonomous side effects remain outside this release.
What is open source, and what Nymrel sells
The v0.1.0 router core, CLI, MCP server, local read-only adapter, schemas, and tests are released under MIT in versioned package and source archives. Anyone can download, inspect, modify, and run that release. Public copies cannot be recalled, so newer fixes will be published as later versions rather than rewritten history.
Nymrel also offers implementation work for teams that want the router fitted to a real model setup: catalog design, routing objectives, constraints, evals, customer-local adapters, and operational receipts. That service is scoped separately and priced on request. We are not presenting the open core as a trial that requires a paid account to remain useful.
What we are not launching yet
This release does not include hosted model execution, provider-key custody, customer accounts, billing, prompt retention, or write-capable tools. The versioned package and source are available from the product host; npm publication, a custom domain, and the public GitHub mirror remain separate provider or account gates and are not claimed as available distribution channels.
Try one route, then tell us where the contract fails
Run the published example first. If the decision is clear, change the evidence or install the local package and test a real catalog. After a successful live route, the product reveals a feedback link that returns to Nymrel with the launch source attached. We are looking for specific disagreements, missing constraints, installation failures, and workflows where the explanation is not enough to operate safely.
Route one published example
No account or provider key is required for the metadata-only demo. The versioned source and package are available from the same host.
The public endpoint routes metadata and does not execute provider calls. Read the security and custody boundary before connecting the local harness to a provider account.