Neverest by Acific Labs

Neverest for model routers

Last verified against the code: 2026-11-15 (0.10.1)

This page is for companies that route requests between models: OpenRouter, a LiteLLM gateway, the gateway a company runs for its own teams. It says what problem Neverest solves for a router, what works today, and what an integration would be.

The problem a router has

A router makes changing the model one word in a request. It cannot make changing the model cheap for the project.

A request carries the messages the caller chose to send. It does not carry what another app did on the same project yesterday, what the person corrected, what was already deployed, or what was already paid for. The model that started the project knows these things because it was there. The next one starts over, and the person explains it all again.

So people who could switch do not. They stay on the model they started with, and a router's fallbacks, price routing and automatic choice go unused in the middle of real work. The freedom to switch is what a router sells. The cost of switching is what stops people using it.

What Neverest adds

Neverest is the relay between models. It keeps one log per project and gives the next model a handoff.

What How it helps a router
One log per project, appended by every model that touches it The project stops belonging to one model
The handoff: the recent work, the person's corrections in their own words, what was deployed, what was paid for The next model continues instead of starting over, so a switch costs one request, not an afternoon
It names the model that answered Asked for an alias, a fallback list or the router's own choice, the log records the model the router used, so the person can see who did what
It knows when nothing changed A caller that keeps asking for the same name and sends its own history is not handed the work again, whichever model the router picked. No tokens are spent repeating it
Observations, never instructions Nothing in a handoff tells a model what to do. It is a record, so it is safe to put in front of any model

This is an argument for why switching gets cheaper. We have not measured its effect on how often people switch.

Three ways to work together

1. Today, with nothing to integrate

A person runs Neverest in front of the router, on their own machine:

NEVEREST_UPSTREAM=https://openrouter.ai/api/v1 neverest proxy

They point their apps at http://127.0.0.1:11435/v1 with their router key, and send the header x-neverest-project with the project's path or name. The key is passed through and the header is not. The router sees an ordinary request. When the model changes, the request arrives with the handoff as its first message.

This was run against OpenRouter's live API on 2026-11-15, three requests on one project. A first model was asked to do some work. A second model, sent no history, was asked what had been done and answered with the work and the name of the model that did it. A third request asked for openrouter/auto, streamed, and the log recorded the model OpenRouter chose, with openrouter/auto kept as the name asked for. The tests run the same exchange against a stand-in router.

2. A router reads the header itself

A router that wants this for every customer, with nothing to install, needs three things, and all three are written down in the protocol:

  1. The header. x-neverest-project names the project. Requests with the same value share one log.
  2. The log. One JSON object per line: when, which model, the role, the kind (user, assistant, correction, deploy, payment, note), the text.
  3. The rule. A request for a model that did not write the last reply, or that does not already contain that reply, is given the recent work. Corrections, deploys and payments are given every time.

The rule and the log are about 200 lines of Python with no dependencies (neverest/relay.py). There is no library for a router's own stack yet. We would write one with the first router that wants it.

3. The log stays with the person

A router that does not want to hold project logs does not have to. With the proxy on the person's machine the log never leaves it, and between a person's machines it travels sealed, so no server can read it, ours included (user guide). The router carries requests that are a little longer and nothing else changes.

What we do not claim