Lyapunov puts an agent, a 3D viewer and a physics engine in one Linux desktop

What the product is and who it is for

Lyapunov is described as an LLM-first, 3D-native robotics and agent desktop framework, produced by Vorynel Co., Ltd. For robotics developers, simulation and research teams and 3D creators, it brings scene construction, robot preparation, controlled simulation and camera data into one workspace. The specific claim is that chat, code, files, the 3D viewer and physics share one desktop workspace. The recommended workflow follows from that. You ask the agent to use native product tools, or you use workbench controls for scene, robot and simulation operations. The published metadata is specific. The platform is Linux x64, the licence is the Apache License 2.0 with retained notices in a NOTICE file, the copyright is 2026 Vorynel Co., Ltd., and the development was sponsored by UAD, the Architectural Design and Research Institute of Zhejiang University Co., Ltd. The author team is listed by name, and the homepage is vorynel.com/lyapunov. The README carries a Blake epigraph about seeing a world in a grain of sand, which is the sort of flourish that tells you a company is selling a vision alongside a tool.

Installing on Linux with the shell installer

The documented installation runs from a regular terminal in your graphical desktop session, and it is a single pipe.

curl -fsSL https://vorynel.com/lyapunov/install.sh | sh

After installation succeeds and reports ready, Lyapunov is started separately.

"$HOME/.local/bin/lyapunov"

The default installation prepares MuJoCo and its Python runtime, verifies native physics, and creates a per-user launcher and desktop entry. Isaac Sim or Newton can optionally be installed as needed, and they are not prepared by the default installation. The dependency story is unusually well isolated. Node.js, Electron and the pinned DSH runtime are included in the main archive, the default installation downloads MuJoCo and Python into a dedicated environment inside that version, and neither the default installer nor the packaged launcher depends on Node, DSH or Python from PATH, or on a developer's source checkout. You do not need a system Node.js, DSH, Python, pip, Conda, Bun or a model key to install it. User sessions and credentials live in the product data directory, which survives upgrades.

Version directories, the current link, and reading the script first

The installer keeps versions under ~/.local/share/lyapunov/versions/, switches the current link only after its checks pass, and leaves older versions and user data in place. If ~/.local/bin is on your PATH you can launch with lyapunov, otherwise you need the absolute command. The README also tells you how to inspect the installer before running it, which is the advice worth following when a script arrives over a pipe.

curl -fsSL https://vorynel.com/lyapunov/install.sh -o lyapunov-install.sh
less lyapunov-install.sh
sh lyapunov-install.sh --help
sh lyapunov-install.sh

The flags are specific. The --version RELEASE_ID option selects a published release, and --prefix /absolute/install/path and --bin-dir /absolute/bin/path customise the location. Spaces in the install prefix are supported, while a prefix containing a single quote is rejected for the default MuJoCo runtime. Manual archives, checksums, updates, rollback and removal are covered in the installation guide, and the installation page is described as the authority for release identifiers, downloads and system requirements. The README is careful about which document says what. This repository holds the product source, the release notes in docs/releases describe product changes and their verified scope, and the installation page plus its release manifest are the authority for identifiers and requirements.

The Alpha8 release: what changed in the physics and state layer

The release notes in the README are the clearest statement of where the product is, and Alpha8 is a substantial update. World closure is retried after a temporary failure, as described in Issue 1. Native physics properties and state are connected, covering MuJoCo flex and physical cables, restricted Newton source-position control, static-container water MPM, and native RGB-D cameras, along with parameters and node or particle readback for existing Isaac USD deformables and PBD particles, with availability following each engine's supported scope and local runtime requirements. You can edit native parameters, synchronise and read actual values, and then save and reopen portable projects with their native documents and resources. A new Open copy command creates a new scene from a same-name project while preserving the original scene and its resources. Automatic checkpoints are scoped to the selected project directory, and their preparation can be cancelled. The releases are rapid alpha iterations, v0.1.0-alpha.8 on 2026-10-12, v0.1.0-alpha.7 on 2026-10-09 and v0.1.0-alpha.6.1.1 on 2026-10-09.

The plugin architecture: DSH and Cordis

Lyapunov builds on the everything-is-a-plugin architecture of DSH and uses Cordis's composition mechanism to integrate tools and capabilities, and the README thanks the authors and contributors of both, with a pointer to the paper describing the Cordis design, A Programming Paradigm for Spatiotemporal Composability. The practical consequence is that the workspace is assembled rather than monolithically written. Chat, code, files, the 3D viewer and physics are capabilities in one composition, and a feature that can be expressed as a capability can be added or removed without rewriting the rest. The repository layout supports that reading. There is a packages directory, a distribution directory, a config directory, a packs directory, a development directory and a script directory, with the root package.json declaring workspaces over packages/* and distribution/* and pinning [email protected] as the package manager with node >=24 in the engines field. There is also an UPSTREAM_LOCK.json, which is how you pin what DSH and Cordis you build against, plus a RUN_MODES.md at the root.

Desktop input, and the Wayland caveat

The compatibility notes are unusually concrete, and they contain a real limitation. Normal keyboard input and GUI operations have been verified on the local X11 desktop. In the tested Ubuntu 26.04 QEMU/KVM Wayland session, native screenshots, accessibility trees and semantic interaction worked, but the RemoteDesktop Start authorization response could time out after 120 seconds, and the actual Return key did not pass verification. The recommendation follows directly: for desktop automation that needs reliable keyboard input, prefer an X11 session. The README calls this a known compatibility limitation of the tested Wayland path, and explicitly says it is not a claim that all Wayland interaction is unsupported. That distinction matters for anyone running the product inside a virtual machine, because the failure mode is a timed-out authorisation and a keystroke that never arrives rather than an error message naming Wayland.

Where Lyapunov is the wrong choice

Three limits are structural. The first is the platform, and it is not negotiable: Linux x64. There is no Windows or macOS build, and the installation page is described as the authority for downloads and system requirements, so a team on other platforms is out. The second is maturity. The version is 0.1.0-alpha.8, the releases are dated days apart, and the release notes describe product changes and their verified scope, which is a candid way of saying the feature set is still moving. An alpha in this space also implies that the saved-project formats and the plugin composition may change between versions, and the Alpha8 note that you can save and reopen portable projects with their native documents is a statement about current behaviour rather than a promise about the format. The third is the relationship to the agent. This is an LLM-first product, and the recommended workflow is to ask the agent to use native product tools, which means the agent is in the loop for scene and simulation operations. If your requirement is deterministic, scripted, reproducible simulation runs with no model in the loop, you are paying for a component you do not want and taking on the reproducibility questions that come with it.

Editorial conclusion

Adopt Lyapunov if you are a robotics developer or simulation researcher who wants an agent to drive scene construction and simulation inside the same desktop as the 3D viewer. Skip it if you need Windows or macOS, since the product is Linux x64 only, and skip it if you need a stable release, since the current tag is 0.1.0-alpha.8. Before you install, read the script rather than piping it blind, and check whether the Wayland session you use is one where keyboard input has been verified.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. ManfredCh/Lyapunov on GitHub
3. Project website
4. README
5. Releases