Misceo gates a cheap model on the answer it produced, and ships no source

The repository is a documentation site, and the metadata license contradicts the tree

The repository-level notice is explicit about what you are looking at. It calls itself the official public documentation, issue tracker, and release home for Misceo, states that the product is distributed as prebuilt binaries through npm, and says that source code is not included in this repository.

The top-level listing matches that claim rather than contradicting it. There is no package.json, no src directory, no build configuration and no test suite. What is there: .github/, CHANGELOG.md, CHANGELOG.zh-CN.md, CONTRIBUTING.md, LICENSE, NOTICE, README.md, README.zh-CN.md, SECURITY.md, SUPPORT.md and docs/. That is a documentation repository with a changelog and community policy files, which is also why the primary language field comes back empty. There is no code in the repository to classify.

Which matters for two separate decisions. Nobody auditing this gateway can read the code that decides whether a candidate is acceptable, so the routing policy is documented rather than inspectable. And the install path is the only path: npm resolves a platform package, not a build from source.

One inconsistency is worth flagging without resolving. The repository's license metadata reads NOASSERTION, while both LICENSE and NOTICE are present at the root. Which terms govern the distributed binary is not stated in the README, so do not assume the metadata field reflects the file.

npm's own omit flag is documented as a way to break the install

The install is one command:

npm install --global @misceo/cli

Straight after it comes the warning that matters most in this whole page: do not install with `--omit=optional`, because the platform executable is delivered as an optional package.

That design choice has a sharp edge. Optional dependencies are exactly what CI images, corporate proxy configurations and reproducible-build tooling strip out by default, and a global install in a hardened environment may already carry that flag. In those cases the install appears to succeed, the CLI package is on your path, and the binary that actually does the work is absent. The failure would surface at runtime as a missing or unusable executable rather than as a clear install error.

The platform matrix explains why the binary is a per-OS package at all:

| Operating system | Architectures | |---|---| | macOS | arm64, x64 | | Linux | glibc arm64, glibc x64 | | Windows | x64 |

Two gaps are visible in that table. Windows is x64 only, with no arm64 entry, so a Windows machine on ARM has no listed binary. Linux is specified as glibc, which excludes musl-based distributions without anything in the page saying so.

The rest of the requirements are modest: Node.js 18 or newer and npm, plus credentials for whichever backends you enable, and explicitly no separate Bun, Docker, or UI installation.

misceo doctor checks syntax and never touches your credentials

The setup sequence is init, then credentials, then start:

misceo init --mode balanced

Credentials go into a `.env` file in the directory you created, and then you validate and start:

misceo doctor
misceo start

The scope of doctor is stated in one sentence and it is a narrow one: it performs static checks, and it does not contact providers, validate live credentials, or prove model availability.

So a clean doctor run tells you the configuration parses and the gateway is internally consistent. It does not tell you the Anthropic key is valid, that the ZAI key is valid, that the model names you configured exist upstream, or that your account can reach them. Every one of those failures appears later, on a live request, as an upstream error that the structural gate is then designed to catch and escalate.

That ordering is defensible for a static check that runs offline, but it makes doctor easy to over-trust in a setup script. The page's own verification procedure is the fuller test: send a normal prompt in Claude Code, follow it with a second small request, open the dashboard and inspect Live traffic for the serving backend, the route or cascade note, status, latency and judge score. From another terminal:

curl http://127.0.0.1:4141/healthz
misceo status

A healthy response, a traffic row and a visible session together confirm the client is talking to Misceo rather than to a provider directly.

Tool-loop ownership lets one cheap decision pin the rest of the conversation

This is the part that distinguishes the gateway from a request-level router, and it has a cost consequence.

When a model opens a tool loop, that backend keeps ownership until the loop is complete. The gateway does not move an active tool call and result exchange to another model family halfway through. The reasoning is sound, because a tool loop split across two model families means the second model inherits reasoning it did not produce, and provider-specific thinking signatures and cache markers are handled at model-family boundaries rather than carried across.

The consequence is that the savings are not per conversation. If the lower-cost backend opens a tool loop on, say, the third request, that backend keeps serving for the rest of that loop, and the escalation path that would otherwise have saved money does not trigger mid-loop. Sessions with tool use are therefore the case where cheap-first routing pays least.

Two other protections narrow the blast radius in the same spirit. Conversation continuity groups requests by structured session identity when the client provides it, so bootstrap, title-generation and visible requests from one launch stay in the same conversation rather than being routed as unrelated traffic. And first-visible-reply protection separates known launch bootstrap traffic from the user's first visible request, giving that first reply to the strong backend before later requests enter normal routing.

The project states the limit of its own claim plainly: it does not make a cheaper model equivalent to a stronger model. It makes the cost-versus-quality policy explicit, observable, and configurable. Three postures are named for that policy, quality-first, balanced and savings-first, selected at init with --mode.

A rejected candidate has already reached two providers, and the judge sees the prompt

Local does not mean offline, and the page says so directly. The proxy, embedded dashboard, configuration and traffic logs run locally, but inference requests go to the providers selected by your routing policy.

For an eligible cascade the request fans out. The first provider receives the request. If the candidate is rejected, the escalation provider also receives the request. So the cost you were trying to avoid still happens on the failed path, and a rejected answer is not a suppressed answer, since the prompt has been sent twice.

A third party can see it too. A configured judge receives the capped latest user turn, the visible candidate, and the tool names. That is a narrow slice rather than the full transcript, and capping is stated as a property rather than configured with a number, so how much of your most recent prompt leaves your machine depends on the judge configuration.

The flow chart shows where the branches land. Protected routes, open tool loops, active pins and explicit rules run before the cascade and go straight to the strong backend. Everything else reaches the lower-cost attempt, then a structural gate that rejects upstream failures, empty output and malformed tool calls. A failure at the gate escalates. A pass goes to the judge policy, which can accept, skip, reject, or fail closed, and only accept or skip returns the candidate.

The decision precedence, session identity, tool-loop protection and mode-specific failure behavior are delegated to docs/routing-and-handoff.md rather than spelled out here.

Two plain HTTP listeners on loopback, one of them holding your history

Two local addresses are given, both HTTP and both on the loopback interface: the proxy on `http://127.0.0.1:4141` and the dashboard on `http://127.0.0.1:5141`.

The proxy port is the one your client is pointed at, and the documented wiring shows how minimal the trust boundary is:

ANTHROPIC_BASE_URL=http://127.0.0.1:4141 \
ANTHROPIC_AUTH_TOKEN=misceo \
claude

The auth token is the literal string misceo. There is no credential in that command, which is consistent with a loopback listener that nothing else can reach, and equally a reason the page tells you to read docs/privacy-and-data.md before exposing either listener beyond loopback. Moving either port off 127.0.0.1 moves that fixed token with it.

The dashboard is the more sensitive of the two. It carries live traffic, history, cost, and deletion controls, and it also shows the serving backend, the judge result, latency, usage, and the route reason for each request. That is the observability the project is selling, and it is the same view that reveals the content of your prompts to anyone who can open port 5141.

The cross-model handoff keeps an original local audit record available for inspection, so the history is retained by design rather than as a side effect. Windows PowerShell setup and the full verification procedure are deferred to docs/getting-started.md, with client and platform boundaries in docs/compatibility.md.

Two releases two days apart, then sixty days of silence

The release history is short and recent. v0.1.0 is named Misceo 0.1.0 with the subtitle public binary release, published 2026-08-02. v0.1.2, named Misceo v0.1.2, followed on 2026-08-03. The last push to main was 2026-08-03, roughly the same moment.

Nothing has landed since. As of 2026-10-02 the repository has been without a commit for about sixty days, and the highest published version is 0.1.2.

Read those two facts together. This is a pre-1.0 project whose entire public history is one day wide, whose current version is a patch number past an initial release, and which is distributed as an opaque binary. The version number is the honest signal here rather than a deficiency: 0.1.x is what a maintainer uses for something whose interface is still settling, and the routing modes table in the README is itself cut off mid-row at the judge column.

Two separate changelogs are maintained, CHANGELOG.md and CHANGELOG.zh-CN.md, alongside a Simplified Chinese README. So release notes and policy are being kept in both languages even at this stage.

For an evaluation, that means pinning to an exact version and expecting the interface to change. For a dependency, it means the routing behaviour you evaluate is a snapshot of a project whose source you cannot read and whose recent history is a single day.

Editorial conclusion

Adopt Misceo if you run agent loops on Claude, GLM or a custom backend and want per-request routing decisions you can see in a dashboard, and if you accept a prebuilt binary as the only artifact. Do not expect to audit or patch the routing code, because none of it is in the repository, and do not point sensitive prompts at it before reading docs/privacy-and-data.md. Verify first that `misceo doctor` passing means nothing about your keys, since it performs static checks only and never contacts a provider.

Frequently asked questions

Official sources

1. Issues
2. MaySudo/Misceo on GitHub
3. Project website
4. README
5. Releases