EmbodiedJev

How we reviewed this: we built it in Docker with Python 3.11 and Node 22 on four CPU cores with no GPU, ran the test suite, started the server in its memory-only mode, drove the HTTP API directly, and ran the transfer task twice — once on the rule baseline with no key, once against the real API. We don’t publish our own measurements of Jev’s accuracy or latency.

What it is

EmbodiedJev (行知) is a MuJoCo workbench you drive from a browser. Three tasks — put the red block in the blue tray, stack it on the blue block, carry it over a barrier — and four ways to decide each step: a deterministic rule baseline, Jev, any chat model you point it at, or a local MiniCPM5-2B. The point is the comparison, and the interface is built around showing the same task decided four ways.

Each cycle the engine proposes candidate actions, simulates each one and attaches the outcome — where the tool centre point and the object end up, whether the grasp still holds, whether the placement makes contact, the residual error in metres — then asks the model to pick one. The request carries measurements and a goal sentence; images belong to the separate visual-planning path and go to a chat or local model, never to Jev. A guard in that path refuses planning text containing embedded image data.

It ran, and the gate did its job

The rule baseline finished the transfer task in eight cycles with zero model calls, in a container with no key configured. That is the whole loop — physics, previews, verification — available before you spend anything.

With our key attached, the same task stopped at cycle five:

status: uncertain    phase: lower    threshold: 0.55
choice: "direct"  probabilities: {hold 0.02, direct 0.54, gentle 0.44}
message: 候选动作概率低于设定门槛，等待人工处理

The model preferred lowering directly, but only just, over doing it gently — and because the winning probability sat under the configured gate, the arm stopped and waited for a person instead of guessing. Resuming with the gate at 0.3 completed the task in eight cycles and fifteen model calls, ending at stage: verified.

That is the behaviour we want to find and rarely do: a tie between two options is treated as a reason to stop, not as a 54% mandate.

Key handling is the best in this batch

connection_store.py stores connection metadata on disk and the key only in the operating system’s credential store — and it checks which backend it got:

allowed = {"keyring.backends.macOS", "keyring.backends.Windows",
           "keyring.backends.SecretService", "keyring.backends.kwallet"}
if type(backend).__module__ not in allowed:
    # In particular, never accept keyrings.alt plaintext/encrypted file fallbacks
    raise RuntimeError("No supported OS credential backend")

If no supported keyring exists — our container, for instance — it falls back to memory only and says so in the interface: the configuration lasts until the service restarts, and no plaintext key is written. serve --memory-only makes that explicit, and the server has no --host flag at all, so it binds loopback and stays there.

Saving a key does not test it, which the response says in as many words, and the separate connection test reports back that “the model returned a valid candidate action; the robot did not execute an action”.

Smaller things worth knowing

• The test suite is large and passed: 400 passed, 1 skipped. One concurrency test failed the first time, while we had three containers competing for four cores, and passed on its own and in a second full run — worth knowing if you run the suite on a small machine.
• shuffle_candidates is a switch in the API: it randomises the order options are presented in, which is how you check whether a model is picking on merit or on position. Finding it in a two-day-old project is a good sign.
• Everything is exportable: the experiment JSON, the replay timeline, and camera frames as a zip, with the export path deliberately separated from credentials and raw image bytes.
• The documentation and interface are Chinese-only. The code, API and event messages are Chinese too. For a Chinese-reading audience that is no obstacle; for anyone else, docs/ is a wall.

Verdict

This is the most complete robotics workbench we have run, and the one most clearly built for comparison rather than demonstration: the baseline is a peer of the model rather than a fallback, the previews are shown before the choice, and the uncertainty gate is on by default at a value that actually fires.

Two days old and one author, so treat it as a laboratory. If you read Chinese and want to see what a typed decision model does and does not add to a control loop, start it, run the baseline first, and then turn the model on and watch where the two differ.

For a smaller CPU-only version of the same loop see RoboJEV; for the previews-then-pick pattern on LIBERO tasks, jev-libero.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 21, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.