# rutis: A Rust reimplementation of Cordis with an agent framework on the aimux seam

> rutis is a Rust workspace that ports the Cordis plugin kernel to idiomatic Rust, adds a minimal agent framework over the aimux LanguageModel trait, and ships a CLI with a TUI. The five-pillar design is faithful to Cordis, but the agent layer is thin and the crates.io CLI lags behind the GitHub release.

**eric8810/rutis** — Cordis core paradigm in idiomatic Rust: five-pillar kernel + minimal agent framework on the aimux LanguageModel seam

- Repository: https://github.com/eric8810/rutis
- Stars: 22 · Forks: 1
- Language: Rust
- License: MIT
- Published: 2026-08-26 · Updated: 2026-08-26 · Language: en
- Canonical page: https://hysenlabs.com/projects/eric8810-rutis

## What rutis solves and who it is for

rutis addresses a specific gap: Cordis, a TypeScript plugin framework, has a core paradigm that many developers want in Rust, but no idiomatic port existed. The README states that rutis is an independent library extracted from a Rust workspace, originally derived from min-cordis. The target user is a Rust developer who wants Cordis-like plugin architecture, with typed services, fiber-based lifecycles, and an event bus, without depending on a JavaScript runtime. The project also bundles a minimal agent framework, so it serves two audiences: those who need the kernel, and those who want a small coding agent TUI. The agent layer is not a full product; it is a demonstration of how the kernel can host an agent loop. The README calls the agent crate 'one sentence': one aimux LanguageModel service, one ToolRegistry plugin, one driver plugin implementing an Agent interface, and an in-memory session. That is the scope. If you need a production agent, this is a starting point, not a finished tool.

## The five-pillar kernel: how the core is structured

The kernel is organized around five pillars, each with a specific mechanism. First, a plugin is an assembly unit: one apply call provides services, listeners, and cleanup. Second, a fiber is a lifecycle container with a six-state state machine, dependency gating, cascading unload, and exactly-once cleanup. Third, services are a type-keyed registry with isolate scopes. Fourth, the event bus has four dispatch semantics: emit, parallel, serial, and waterfall. Fifth, dependency-driven reload means that when a provider is unloaded, consumers are evicted and automatically reloaded. This is not a loose collection of ideas; the README claims 115 contract tests that compare against the original Cordis spec. That parity testing is the strongest evidence of fidelity, but it also means the kernel is bound to Cordis semantics, which may not fit every Rust project. The design docs referenced, such as design-rust-port.md and cordis-spec-parity-2026-08-18.md, are the place to verify the exact state machine and dispatch rules. The kernel crate is named rutis, and it is the foundation for the other crates.

## The aimux seam and the agent framework

The agent framework sits on the aimux LanguageModel trait, which is a unified access layer for LLMs. The README says aimux supports 329 providers, and rutis consumes aimux from crates.io, so you do not need to check out aimux locally. The aimux-llm crate is a plugin that registers an llm service, using aimux's native DTO and StreamPart as the neutral protocol schema. It handles factories, keyed caching, listModels caching, and fallback, all with zero bridge code and zero dsh knowledge. The rutis-agent crate then combines that llm service with a ToolsPlugin and an AgentDriverPlugin. The driver supports streaming followup, waterfall middleware, and agent/* event broadcasting. There is an in-memory session that acts as the source of truth for the loop. The design is deliberately minimal: the README lists only two built-in tools in minimal mode, bash and replace_text. This is not a general agent framework; it is a proof that the kernel can host an agent with a small surface. The verification strategy is three layers: unit tests with a ScriptedLlm that implements the real LanguageModel trait, integration tests with aimux's MockReplayModel, and real end-to-end tests that are ignored and require an API key.

## Getting it running: commands and configuration

The README gives clear commands. To test everything, run cargo test, which covers the kernel parity tests and the first two layers of the agent verification. For the latest CLI, download from GitHub Releases, because cargo install rutis-cli installs an older version from crates.io that lacks the rutui TUI. The source build is cargo build -p rutis-cli. For an offline demo without any API key, run rutis-cli --scripted. For a real backend two-turn conversation with dependency-driven eviction, run cargo run -p rutis-agent --example demo, which requires DEEPSEEK_API_KEY. For an interactive TUI with streaming, tool visibility, and Esc to cancel, run cargo run -p rutis-agent --example tui. There is also tui_scripted for an offline scripted backend. Real end-to-end tests are run with cargo test -p rutis-agent --test real_backend -- --ignored, and they do not run in CI. Provider and model selection is done through environment variables: AIMUX_PROVIDER and AIMUX_MODEL. The README gives an example of using a local model: AIMUX_PROVIDER=ollama AIMUX_MODEL=qwen3:8b. That is the whole configuration surface; there is no mention of a config file.

## Limitations and cases where rutis is the wrong tool

The most obvious limitation is the CLI version split. The README explicitly warns that the crates.io version of rutis-cli is old and does not include the rutui TUI. That means a casual user who runs cargo install rutis-cli gets a degraded experience. The agent framework is also minimal by design: only two built-in tools, and the session is in-memory, so there is no persistence across runs. There is no mention of multi-agent coordination, memory beyond the session, or tool-use policies. The kernel's dependency-driven reload is powerful, but it can be surprising: unloading a provider evicts consumers and reloads them, which could cause cascading restarts in a complex plugin graph. The README does not describe failure modes for that mechanism. The project is at v0.1.0, so the API is not stable. The dual-core architecture, described in design-dual-core-2026-08-20.md, plans a Rust spine and a TypeScript functional surface, but that bridge is still a design, not a released feature. If you need a production-grade agent with a stable CLI, or if you want to avoid the complexity of a Cordis-like lifecycle, rutis is not the right fit.

## Alternatives: how they differ in approach

The most direct alternative is the original Cordis, which is TypeScript. Cordis has the same five-pillar paradigm, but it runs on Node.js. If your team is already in the TypeScript ecosystem, using Cordis directly avoids the porting gap and gives you the original spec as the source of truth. The difference is not just language: Cordis has a mature ecosystem of plugins and a longer history, while rutis is a fresh Rust port with a small set of crates. Another alternative is to use a Rust-native plugin framework that is not Cordis-inspired, such as a simple trait-based service registry. That approach would be less faithful to Cordis semantics but potentially simpler, because you would not need to implement the six-state fiber machine or the four dispatch modes. The trade-off is between fidelity to a specific paradigm and the flexibility of a custom design. There is also the option of using the aimux crate directly without the rutis kernel, if you only need LLM access and not the plugin lifecycle. The README says aimux is a unified access layer with 329 providers, so you could build your own agent loop on top of aimux and skip the Cordis-style overhead. That is a legitimate path if you do not need the dependency-driven reload or the event bus.

## Maintenance, licensing, and what to verify before adopting

The project is MIT-licensed, inherited from Cordis, which is permissive for commercial use, but this is not legal advice. The maintenance cost is a real concern. The repository has a single release, v0.1.0, and the last push is from 2026-08-19, which is recent, but there is no evidence of a long-term maintenance history. The README references many design documents, which suggests active development, but also means the architecture is still evolving. The dual-core design, with a Rust spine and a TypeScript dsh surface, is a plan, not a shipped feature. The crates.io CLI lag is a concrete maintenance issue: users must know to download from GitHub Releases instead. Before adopting, verify that the 115 contract tests cover the exact Cordis behaviors you rely on, especially the event dispatch semantics and the fiber state machine. Check the design docs for any known deviations from Cordis. Confirm that the aimux provider you need is supported, and test the real backend path with your own API key. The agent layer is minimal, so if you need more than two tools or persistent sessions, you will have to extend it yourself. The project is young, so expect breaking changes between versions.

## Conclusion

Adopt rutis if you need a Rust-native plugin kernel that mirrors Cordis semantics, especially for building or porting plugins that rely on typed services, fiber lifecycles, and four-mode event dispatch, and if you want a small agent loop over any aimux-compatible provider. Do not adopt it if you expect a mature, feature-complete agent framework or a stable CLI: the agent crate is intentionally minimal, the crates.io CLI is outdated and lacks the TUI, and the project is at v0.1.0 with a single release. Before adopting, verify that the 115 contract tests match your expected Cordis behavior, check the dual-core design docs for how the Rust spine will coexist with the TypeScript dsh surface, and confirm that the aimux provider you need is supported through AIMUX_PROVIDER and AIMUX_MODEL. The project is MIT-licensed, so licensing is permissive, but the maintenance cost is on you: the repository is young, the last push is recent, and there is no evidence of a stable API or migration path.

## FAQ

### What does RUDIS mean, and is that the same thing as rutis?

Those queries are about RUDIS wrestling shoes and apparel. This repository shares the spelling but is a Rust library of six workspace crates implementing the Cordis core paradigm, under an MIT license inherited from Cordis by Shigma.

### Where can I buy RUDIS products, and does that apply to rutis?

Nothing here is for sale. The CLI is distributed through GitHub Releases, and cargo install rutis-cli pulls the older crates.io build that does not include the rutui TUI.

### What type of business is RUDIS, and is rutis a business?

The business questions belong to the apparel brand. This is open source code: a five pillar kernel plus a minimal agent framework, built on the aimux LanguageModel seam, with six crates in one Cargo workspace.

### When did RUDIS become a thing, and when was rutis last changed?

There is one GitHub release, v0.1.0 for rutis-cli, dated 2026-08-19, and the last push to the main branch is dated 2026-09-22. The repository is not archived.

### What is a rutis blessing, in the sense used by this project?

No such term is defined. The closest guarantees are lifecycle ones: a fiber is a six state lifecycle container with dependency gating, cascading unload, and cleanup that runs exactly once.

## Sources

- [Official README](https://github.com/eric8810/rutis#readme)
- [Project repository](https://github.com/eric8810/rutis)
- [Release notes](https://github.com/eric8810/rutis/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eric8810-rutis