DEV Community: Le Anh Phi

Your AI coding CLI is expensive, forgetful, and overconfident. I built one that isn't.

Le Anh Phi — Wed, 08 Jul 2026 09:19:36 +0000

Le Anh Phi

Jul 4

Your AI coding CLI is expensive, forgetful, and overconfident. I built one that isn't.

#ai #cli #opensource #productivity

10 min read

Your AI coding CLI is expensive, forgetful, and overconfident. I built one that isn't.

Le Anh Phi — Sat, 04 Jul 2026 07:45:56 +0000

If you've been using AI coding agents for a while, you already know the three papercuts that never stop bleeding:

The bill. Every token routed through a premium model. $50–100/month before you notice.
The amnesia. Every session starts from zero. The agent makes the same mistake it made last week, because it remembers nothing.
The overconfidence. One model gives you one answer in a confident voice — and sometimes that answer is just wrong, with no second opinion in sight.

I got tired of all three and built muonroi-cli — a bring-your-own-key (BYOK) coding agent that lives in your terminal (Bun + React 19 + OpenTUI + AI SDK v6). Its entire design is a reaction to those papercuts: it makes several models from different vendors argue with each other before a high-stakes answer, it remembers what it learned so it stops repeating mistakes, and it routes each task to the cheapest capable model so the whole thing costs about $5/month.

Here's each pain — and exactly how it's solved.

TL;DR — the pain → the fix

The papercut	How muonroi-cli fixes it
🎲 One model, one overconfident answer	Council — models from different vendors (DeepSeek, Z.ai GLM, Kimi) debate with a verify-then-refute, cite-your-evidence protocol, then a judge scores confidence
🧠 Agent forgets everything, repeats mistakes	Experience Engine — a self-curating brain that recalls prior gotchas before acting and gets sharper each session. Shared across Claude/Codex/Gemini over MCP
💸 $50–100/month bill	~$5/month by design — role-based routing + auto-compaction + sub-agent token caps + `usage forensics`
⏳ Long sessions get slow and pricey	Auto-compaction after every turn keeps cost flat
🐛 UI regressions unit tests can't catch	Semantic blocks — the agent QA-tests its own terminal UI as a real user, no screenshots/OCR
🔒 Vendor lock-in, keys in plaintext	BYOK — 7 providers, keys in your OS keychain, OAuth, Bitwarden sync, encrypted cross-device export

Pain #1: One model gives you one confident answer — and sometimes it's wrong

You ask a hard architectural question. One model answers in a self-assured voice. There's no dissent, no second opinion, no one poking holes — so a plausible-but-wrong answer sails straight through. That's the single-model trap.

The fix — the Council. Run /council <topic> and muonroi-cli spins up a structured, adversarial debate between different models from different vendors before it answers you.

That last part matters. A debate is only worth running if the participants can actually disagree — and two instances of the same model tend to violently agree. So the council defaults to prefer_multi_provider: true and seats participants from distinct providers:

Debate role	Provider	Model
implement	DeepSeek	`deepseek-v4-flash`
verify	Z.ai	`glm-5.2`
research	opencode-go	`kimi-k2.7-code`

DeepSeek, a GLM model, and Kimi — three different training lineages — argue the same question. When a participant call fails mid-debate, the fallback deliberately retries on a different provider ([research] … failed; retrying via <model> (different provider)), so provider outages degrade the debate instead of killing it. This is where BYOK multi-provider stops being a checkbox and becomes the whole point: you're not paying for one opinion, you're paying for a panel that doesn't share blind spots.

A single question flows through a real pipeline:

Clarification — the leader model asks 3–5 clarifying questions before anyone debates.
Debate planning — the leader assigns stances (e.g. "Pragmatist", "Performance Analyst") so participants attack the problem from genuinely different angles instead of nodding along.
Research phase — participants can hit bash, grep, read_file, plus MCP tools (Tavily web search, Playwright) to ground claims in evidence. Findings are split into Source Code Findings ([file:line]), Internet Findings ([url]), and live Frontend Findings.
Rounds — up to 8 rounds of a verify-then-refute pattern. A claim isn't rebutted with vibes; it's rebutted with a citation:

  [Pragmatist] → [Performance Analyst]:
  REST has zero migration cost and our team knows it.
  [REFUTED via tavily: "Proto tooling has improved significantly in 2024"]

  [Performance Analyst] → [Pragmatist]:
  Benchmarks show 40% lower latency for internal calls.
  [CONFIRMED via bash: hyperfine results]

Convergence detection — the leader tracks an evidenceDensity score (citations ÷ claims). If the debate is running on opinion instead of evidence, it forces a mid-debate research query. It stops when disagreement is genuinely resolved, not after a fixed number of turns.
Synthesis + a confidence judge — the outcome is structured JSON, then a separate judge scores it 0–1. Below 0.5 it gets stamped [NEEDS HUMAN REVIEW] instead of pretending to be sure.

Every debate is persisted. /council inspect <session-id> replays the whole thing — participants, per-round evaluations, tool traces, extracted citations. You can audit why the agent recommended what it did.

The tagline on the repo is literal: "An AI coding agent where models argue with each other before answering."

Pain #2: Your AI coding bill is quietly $50–100/month

Every token routed through a premium model. Every long session getting pricier as context grows. A runaway sub-agent silently ballooning one call to hundreds of thousands of tokens. The bill creeps up and you can't even see where it went.

The fix — cost as a first-class constraint. muonroi-cli attacks it from four directions at once:

1. Route by role. The Prompt Intelligence Layer (PIL) classifies each turn (task type, complexity, domain) and maps it to a role — leader, implement, verify, or research — each pointing at whatever model you configured:

"roleModels": {
  "leader":    "deepseek-v4-pro",    // hard decisions → premium
  "implement": "deepseek-v4-flash",  // grunt work     → cheap + fast
  "verify":    "deepseek-v4-pro",
  "research":  "deepseek-v4-flash"
}

The premium model only appears for the parts that need it; the cheap, fast model does the mechanical typing.

2. Compact after every turn (see below) so long sessions don't cost more per turn as they grow.

3. Cap the blast radius. Sub-agents get hard token budgets, so a runaway delegation can't quietly balloon a single call to hundreds of thousands of input tokens.

4. Make leaks findable. When something does look expensive, usage forensics (Pain #6 below) tells you exactly where the tokens went instead of leaving you to guess.

The result is real, measured, not aspirational: on your own keys, everyday use lands around $5/month. And it's genuinely multi-provider — DeepSeek, SiliconFlow, OpenAI, xAI, Z.ai and more, each with its own key. Keys live in your OS keychain, never plaintext config. Log in via OAuth (OpenAI/Google/xAI), sync from Bitwarden, or move an encrypted, passphrase-protected bundle between machines with keys export / keys import.

Pain #3: The longer the session, the more every turn costs

Context grows with every message, and if nothing trims it, each turn re-sends the whole ballooning history — so a long, productive session gets slower and more expensive exactly when you're in flow.

The fix — auto-compaction. After every turn, context is silently compressed. Instead of your prompt cost creeping up as the conversation grows, it stays roughly flat. You don't manage it; it just happens. (There's a manual /compact if you want to force it.)

Pain #4: Your agent forgets everything and repeats the same mistake

You correct the agent. It nods, fixes it, and then next session — clean slate — it walks into the exact same trap, because it remembers nothing. Every conversation is Groundhog Day. This is the one that wastes the most of your time, quietly.

The fix — the Experience Engine. This is the feature I'd point to if you only tried one thing. muonroi-cli ships an Experience Engine (EE) — a persistent, self-curating behavioral brain that turns each session's decisions, gotchas, and corrections into knowledge the agent carries forward.

It's not a chat-history dump. It's a learning flywheel with real mechanics:

Recall-first, not react-later. Before working in an unfamiliar area or taking a risky, hard-to-reverse step, the agent queries the brain first — "what did we already prove about this?" — so it orients from prior evidence instead of re-deriving it or walking into a known trap. Recall replaces broad blind exploration: read the one file the brain points at, not ten.
Passive hints at the moment of risk. Before every edit/write/command, learned high-confidence warnings fire inline — ⚠️ [Experience — High Confidence] — right where you'd otherwise repeat a past mistake.
Tiered knowledge. Retrieval spans tiers: durable principles → behavioral rules learned from this codebase → session seeds → self-QA lessons. General wisdom and project-specific scar tissue both surface, scope-filtered to the repo and language you're in.
A closed feedback loop that prunes itself. Every surfaced hint carries an id; after the agent acts, it reports followed / ignored / noise. Useful hints get reinforced, wrong ones get their scope narrowed or deleted. The brain gets sharper with use instead of accumulating cruft.
It feeds the Council. When the brain holds a high-confidence warning relevant to a debate, it auto-injects an "Experience Auditor" stance — "watch for the operational pitfalls this team has already hit." Your past incidents become a debate participant.
Shared across agents. The same brain is reachable over MCP, so Claude, Codex, and Gemini driving this codebase all draw from — and contribute to — one memory. A lesson one agent learns on Monday is a warning another agent gets on Tuesday.

Memory that changes the agent's behavior next time — and gets more accurate the more you use it — is genuinely rare in this category. Here it's a first-class subsystem, not a bolt-on. It's optional and degrades gracefully: if the brain is unreachable, the agent just proceeds without it.

Pain #5: UI regressions that unit tests can't catch (and screenshots are too flaky to)

A modal steals focus. A slash menu opens on the wrong item. A toast fires at the wrong level. Unit tests pass green — because none of that is function-level behavior — and you only find out when a user hits it. Screenshot/OCR testing is the usual escape hatch, and it's slow and flaky.

The fix — the agent QA-tests its own TUI. muonroi-cli has an agent harness that drives its own terminal UI as a real user would — via structured JSON, with no screenshots and no OCR.

The trick is semantic blocks. Every user-visible element is wrapped in a role-fixed primitive — <Dialog>, <TextBox>, <ListItem>, <Menu>, … — that emits an invisible semantic node (id, role, name, focus/selected/disabled state) into a live tree. An automated driver can then query, press, type, and wait_for against that tree the way a browser test queries the DOM — except it's a terminal UI. The primitives fix the role per component so it can't drift or be typo'd, and mirror interactive state (focused, selected) to the harness automatically — killing the single biggest source of UI/test drift. They're zero-cost: when the agent runtime is unset (normal user mode) they render nothing at all.

That semantic layer is what unlocks everything below:

Self-QA — change a modal, a slash menu, or the focus chain, and the CLI can spin up a child process, drive the real TUI through template scenarios, and judge pass/fail — catching regressions unit tests structurally cannot reach (modal lifecycle, toast levels, focus restoration). Passing scenarios get emitted as permanent regression specs.
MCP driver — the harness is exposed as an MCP server (tui.start, tui.snapshot, tui.press, tui.query, …), so an external agent (Claude, Cursor, etc.) can drive the TUI programmatically. It works cross-platform: POSIX fd 3/4 sidechannels on Linux/macOS, named pipes on Windows.

An agent that can test its own UI is an agent that can safely improve its own UI.

Pain #6: "Why did that one prompt cost so much?" — and no way to tell

Something spiked. Your usage graph has a bump. But which call? Which sub-agent? Which uncompacted history got re-sent? Most tools leave you guessing.

The fix — cost-leak forensics. When a prompt costs more than it should, you don't have to guess:

muonroi-cli usage forensics <session-id-prefix>

You get a per-event breakdown with inline anomaly flags tied to specific spend regressions — e.g. "peak single-call input > 80,000 → the sub-agent budget cap didn't engage." Real measured wins from this tooling: one prompt dropped from a 504,737-token peak to 31,702 — a 16× reduction — after the caps were wired correctly. That number came from the forensics view, not a hunch.

Pain #7: "Autonomous" agents that either need constant babysitting — or run wild with no audit trail

Hands-off agents usually come in two bad flavors: the ones that stop and ask every five seconds (so not really autonomous), or the ones that YOLO through your repo with no record of what they touched (so not really safe).

The fix — /ideal, autonomous and accountable. /ideal is the Council, the router, and the Experience Engine wired into one autonomous loop — the Product Ideal Loop. Give it a goal and it drives the whole build itself:

Discovery & context — it reads the target project, and when the goal is high-stakes it kicks off a Council debate to settle the design before writing a line of code.
Plan → implement → verify — it plans the work, implements it with the cheap implement-role model, then runs a verification gate. A failing gate doesn't get shrugged off: the loop iterates again with the failure as context until the work actually passes.
It learns as it goes — the Experience Engine feeds prior gotchas in, and outcomes flow back out, so each loop is a little less naive than the last.

Crucially, "autonomous" never means "unaccountable." A three-level permission model (safe confirms everything → auto-edit auto-approves file ops → yolo runs hands-off) gates the whole thing, and every privileged action is written to an always-on audit log. usage security-audit --since 7d surfaces every yolo session, dangerous command (secrets redacted), and approval override after the fact. You can let it run and still prove exactly what it did.

Try it

# npm (Node ≥ 20)
npm install -g muonroi-cli

# or Bun
bun add -g muonroi-cli

muonroi-cli

First launch runs a wizard: paste a key, import a bundle, sync Bitwarden, or add keys later with /providers. Then the interesting commands:

Command	What it does
`/council`	Multi-model adversarial debate on your question
`/ideal`	Product Ideal Loop — autonomous build from idea to ship
`/providers`	Manage providers, keys, and the default
`/compact`	Compact conversation context
`muonroi-cli usage forensics <id>`	Per-event cost breakdown of a session

Full docs: docs.muonroi.com/docs/cli · Source: github.com/muonroi/muonroi-cli · MIT licensed.

One line: it debates when the answer matters, remembers so it stops repeating mistakes, and keeps the bill around $5/month. If those three papercuts sound familiar, muonroi-cli was built for you.

Which of these papercuts hurts you the most right now? Tell me in the comments — and if you give it a spin, I'd love to hear what your monthly bill actually landed at.

Muonroi Building Block: an open-core .NET foundation for rule engines, decision tables, and multi-tenancy

Le Anh Phi — Tue, 14 Apr 2026 11:16:47 +0000

Repository: https://github.com/muonroi/muonroi-building-block

Status: public repo, open-core (Apache-2.0 OSS packages + commercial-licensed packages).

Target audience: unknown (repo docs suggest teams building .NET services that need rule orchestration, decision tables, multi-tenancy, and governance primitives).

Version: 1.0.0-alpha.9 (repo-wide versioning is configured via Directory.Build.props).

Executive summary

Muonroi Building Block is the .NET foundation of the Muonroi ecosystem. It bundles a rule engine stack (strongly typed rules + orchestration + tracing), decision tables (with common hit policies), and supporting infrastructure like governance/licensing concepts and multi-tenancy helpers. The repository is open-core: OSS packages are Apache 2.0, while commercial packages are distributed under a separate commercial license and are expected to be gated at runtime.

A key differentiator is its developer experience around rule authoring: write rule logic in normal C#, mark it with an attribute, then let source generators and CLI tools generate rule classes and DI registration glue. This reduces handmade boilerplate and allows verification steps (e.g., dependency checks) before runtime.

Key features and use cases

Key features (as described by repo README + deep map)

Strongly typed rule abstraction (IRule<TContext>) and shared state via a FactBag.
Rule orchestration with execution hooks, ordering, and dependency constraints.
Decision table engine with widely used hit policies (Unique, Any, First, All, Collect, RuleOrder).
Source generators + analyzers to extract rules from code and generate DI registration.
CLI toolchain (RuleGen) for extract/verify/register/watch flows.
Multi-tenancy packages for resolving tenant context and linking per-tenant resources.
Explicit OSS/commercial boundary enforcement via scripts (modular boundary checks).

Practical use cases

Policy/risk/fraud scoring where rules evolve faster than deployments.
Decision tables for business-friendly rule maintenance with deterministic evaluation.
Multi-tenant SaaS foundations: consistent tenant resolution + quota enforcement primitives.
Preproduction verification: catch rule dependency errors (and other analyzer-driven issues) before runtime.

Architecture and main components

Big-picture: rule execution pipeline

flowchart TD
  Input[Input context + facts] --> Orchestrator[IMRuleOrchestrator.ExecuteAsync]
  Orchestrator --> FactBag[FactBag shared state]
  FactBag --> Rules[Compiled rules / FEEL / decision tables / flow graph]
  Rules --> Result[OrchestratorResult + updated facts]

Big-picture: code-first rule authoring + generation

flowchart LR
  Dev[Developer writes C# method] --> Attr[[MExtractAsRule]]
  Attr --> CLI[muonroi-rule extract/register/verify]
  CLI --> Gen[Generated rule classes + DI registration]
  Gen --> DI[services.AddRuleEngine<T>() + AddGeneratedRules()]
  DI --> Runtime[Runtime executes rules via orchestrator]

Monorepo layout (high level)

muonroi-building-block/
  src/
    Muonroi.RuleEngine.Abstractions/
    Muonroi.RuleEngine.Core/
    Muonroi.RuleEngine.DecisionTable/
    Muonroi.RuleEngine.SourceGenerators/
    Muonroi.Tenancy.*
    Muonroi.Governance.*
    Muonroi.Observability
    (...more packages...)
  tools/
    Muonroi.RuleGen/                  # CLI for rule extraction/registration/verification
    Muonroi.DecisionTableGen/         # decision table tooling (per deep map)
    Muonroi.RuleGen.VisualStudio/     # VS extension (per deep map)
    Muonroi.RuleGen/vscode-extension/ # VS Code extension (per deep map)
  samples/
    Quickstart.RuleEngine/
    Quickstart.DecisionTable/
    FraudDetection/
    LoanApproval/
    MultiTenantSaaS/
    RuleSourceGen/
  REPO_DEEP_MAP.md
  OSS-BOUNDARY.md
  LICENSE-APACHE / LICENSE-COMMERCIAL

If you want the “map of everything,” the repo provides it:

https://github.com/muonroi/muonroi-building-block/blob/main/REPO_DEEP_MAP.md

Installation and quickstart

Install the core rule engine packages

dotnet add package Muonroi.RuleEngine.Core
dotnet add package Muonroi.RuleEngine.SourceGenerators

Exact versions are unknown here; prefer pinning versions explicitly for production.

Quick example: write a rule in plain C

[MExtractAsRule("HIGH_VALUE_ORDER", DependsOn = new[] { "CREDIT_SCORE" })]
public RuleResult HighValue(OrderContext context, FactBag facts)
{
    if (context.Amount <= 1000m) return RuleResult.Failure("Below threshold.");
    facts["requiresReview"] = true;
    return RuleResult.Success();
}

Generate the glue code and wire up DI

muonroi-rule extract --source src/Rules --output Generated/Rules
muonroi-rule register --rules Generated/Rules --output Generated/RuleEngineRegistrationExtensions.g.cs

using Muonroi.RuleEngine.Generated;

builder.Services.AddRuleEngine<OrderContext>();
builder.Services.AddGeneratedRules();

Run a sample (Rule Engine quickstart)

cd <workspace-root>\muonroi-building-block\samples\Quickstart.RuleEngine\src\Quickstart.RuleEngine.Api
dotnet restore
dotnet run

Test request:

curl -X POST http://localhost:5000/api/orders/evaluate `
  -H "Content-Type: application/json" `
  -d "{\"amount\":1200,\"customerType\":\"premium\",\"countryCode\":\"US\"}"

Run a sample (Decision Table quickstart)

Start Postgres locally:

docker run --name muonroi-sample-postgres `
  -e POSTGRES_USER=admin -e POSTGRES_PASSWORD=admin -e POSTGRES_DB=muonroi_decision_tables `
  -p 5432:5432 -d postgres:16

Run the API sample:

cd <workspace-root>\muonroi-building-block\samples\Quickstart.DecisionTable\src\Quickstart.DecisionTable.Api
dotnet restore
dotnet run

Create and execute a table via REST APIs:

Invoke-RestMethod -Method Post -Uri "http://localhost:5000/api/v1/decision-tables" `
  -ContentType "application/json" -InFile ".\assets\discount-table.json"

$body = '{"inputs":{"amount":1200,"customerType":"premium","country":"US"}}'
Invoke-RestMethod -Method Post -Uri "http://localhost:5000/api/v1/decision-tables/discount-rules/execute" `
  -ContentType "application/json" -Body $body

Contribution guide and license

Contributing

The contribution guide emphasizes “boundary-safe” work:

Default working branch: develop
Prereqs: .NET SDK 8+, PowerShell 7+; Postgres/Redis only if your change needs them
Run tests + the modular boundary check before opening a PR:

pwsh ./scripts/check-modular-boundaries.ps1 -RepoRoot .
dotnet test Muonroi.BuildingBlock.sln -c Debug

Contributing guide:

https://github.com/muonroi/muonroi-building-block/blob/main/CONTRIBUTING.md

License (open-core)

OSS packages: Apache 2.0 (LICENSE-APACHE)
Commercial packages: Muonroi commercial license (LICENSE-COMMERCIAL)
The repo documents an OSS/commercial boundary rule and checks it via a script:
- OSS packages MUST NOT depend on commercial packages.
- Commercial packages MAY depend on OSS packages.

Key boundary doc:

https://github.com/muonroi/muonroi-building-block/blob/main/OSS-BOUNDARY.md

License files:

Comparison to similar projects (brief)

Microsoft RulesEngine: JSON-defined workflows and dynamic expression evaluation; Muonroi Building Block offers a more “code-first + source-generated” workflow (plus decision tables, tenancy/governance packages).

References:
- https://microsoft.github.io/RulesEngine/
- https://github.com/microsoft/RulesEngine
NRules: Rete-based .NET rules engine with an internal DSL in C#. Muonroi’s approach leans more toward orchestration + multiple rule types (compiled rules, decision tables, FEEL, flow graphs) and a CLI/source-generator pipeline.

Reference: https://github.com/NRules/NRules
Drools / DMN decision tables: DMN decision tables and FEEL are widely used in decision modeling; Muonroi explicitly implements decision tables and FEEL-related pieces in its runtime/tooling.

Reference: https://docs.drools.org/7.73.0.Final/drools-docs/html_single/index.html

Suggested tags and social blurb

Suggested dev.to tags

dotnet, csharp, rulesengine, decisiontable, opensource, multitenant, architecture, sourcegenerators, cli, observability

Social blurb (3–5 lines)

Muonroi Building Block is an open-core .NET foundation for rule engines, decision tables, and multi-tenant services.

It supports code-first rules + source-generated registration, decision table evaluation, and runtime orchestration with shared FactBag state.

If you’re building policy-heavy systems (risk/fraud/pricing) and want strong DX around rule authoring, it’s worth a deep look.

Repo: https://github.com/muonroi/muonroi-building-block

References

Repo deep map: https://github.com/muonroi/muonroi-building-block/blob/main/REPO_DEEP_MAP.md
OSS boundary doc: https://github.com/muonroi/muonroi-building-block/blob/main/OSS-BOUNDARY.md
Microsoft RulesEngine: https://github.com/microsoft/RulesEngine
NRules: https://github.com/NRules/NRules
Drools DMN + decision tables: https://docs.drools.org/7.73.0.Final/drools-docs/html_single/index.html

Muonroi UI Engine: a manifest-driven UI runtime + rule-authoring web components (open-core)

Le Anh Phi — Tue, 14 Apr 2026 11:16:02 +0000

Repository: https://github.com/muonroi/muonroi-ui-engine

Status: public repo, open-core (some packages are Apache-2.0 OSS, some are commercial-licensed).

Target audience: unknown (repo docs suggest teams building backend-driven UI + rule-authoring UIs).

Version: workspace 0.1.22 (from package.json); MVC package 0.1.0 (from .csproj).

Executive summary

Muonroi UI Engine is the frontend / host-integration layer of the Muonroi ecosystem. Its core idea is backend-driven UI: a host app fetches a manifest that describes navigation, screens, components, actions, and the component registry, then a runtime turns it into a render plan for your framework (React / Angular / PrimeNG).

The repo also contains open-core rule-authoring UI surfaces built as Web Components (Lit): decision tables, rule flow designer, FEEL playground, tracing, etc. These appear to require a commercial license / “activation proof” at runtime, while the base runtime + adapters stay usable without commercial dependencies.

Key features and use cases

Key features (from repo structure and deep map)

Manifest schema (v1/v2) that models navigation groups, screens, components, actions, data sources, registry, auth profile, and more.
Core runtime that resolves screens by route and checks what can render/execute.
Framework adapters for:
- React (@muonroi/ui-engine-react)
- Angular (@muonroi/ui-engine-angular)
- PrimeNG (@muonroi/ui-engine-primeng)
Web Components (Lit) rule-authoring widgets (commercial modules), exposed via tags like:
- <mu-decision-table>
- <mu-rule-flow-designer>
- <mu-feel-playground>
- <mu-rule-trace-viewer>
ASP.NET MVC bridge (Muonroi.Ui.Engine.Mvc) for server-rendered hosts: manifest models + helper extensions.

Practical use cases

Backend-driven admin portals where navigation + screen composition are shipped from a server.
Composable UIs across multiple frontend stacks: reuse the same manifest across React and Angular apps via adapters.
Embedded rule-authoring experiences (decision tables / flow designer) inside an internal control plane.
Server-rendered hosts that need to load a manifest and drive “what to show” in MVC views.

Architecture and main components

Big-picture (how the UI engine flows)

flowchart LR
  Host[Host app (React / Angular / MVC)] -->|fetch JSON manifest| Manifest[MUiEngineManifest]
  Manifest --> Runtime[MUiEngineRuntime]
  Runtime --> Plan[Render plan / layout plan]
  Plan --> Adapter[Framework adapter<br/>(React/Angular/PrimeNG)]
  Adapter --> UI[Actual UI components<br/>+ custom elements]
  UI -->|calls| APIs[Backend endpoints]

Monorepo layout (high level)

muonroi-ui-engine/
  packages/
    m-ui-engine-core/                 # OSS runtime + schema contracts
    m-ui-engine-react/                # OSS React wrappers
    m-ui-engine-angular/              # OSS Angular mappers
    m-ui-engine-primeng/              # OSS PrimeNG adapter
    m-ui-engine-rule-components/      # Commercial: decision tables, flow designer, FEEL, trace...
    m-ui-engine-rule-components-primeng  # Commercial: PrimeNG adapter for rule components
    m-ui-engine-signalr/              # Commercial: schema watcher via SignalR
    m-ui-engine-sync/                 # Commercial: CLI sync tooling
  src/
    Muonroi.Ui.Engine.Mvc/            # OSS .NET MVC bridge package
  tests/
    Muonroi.Ui.Engine.Mvc.Tests/      # tests mostly concentrated here (per repo README)
  REPO_DEEP_MAP.md                    # file-level map of the monorepo
  LICENSE / LICENSE-APACHE / LICENSE-COMMERCIAL

Core runtime package: what’s inside

The file-level map highlights core “building blocks” such as:

contracts.ts: the manifest schema (MUiEngineManifest, MUiEngineScreen, MUiEngineAction, etc.).
runtime.ts: MUiEngineRuntime (screen resolution, permission checks).
bootstrap.ts: bootstrapper, manifest provider, schema watcher, telemetry.
adapters.ts: render adapters + render-plan builders.
license/MLicenseVerifier.ts: license verification used to gate commercial modules.

If you only read one file before diving deeper, start here:

https://github.com/muonroi/muonroi-ui-engine/blob/main/REPO_DEEP_MAP.md

Optional commercial rule-authoring surface

The deep map lists many UI widgets shipped as custom elements (Lit). A typical flow is:

flowchart TD
  App[Host app] -->|bootstraps custom elements| Loader[MLoadRuleEngineCustomElements]
  Loader --> Gate[Commercial license check]
  Gate -->|license ok| Widgets[Decision table / Flow designer / FEEL / Trace widgets]
  Gate -->|not licensed| Prompt[Upgrade prompt / restricted UI]

Installation and quickstart

Build the monorepo locally (TypeScript workspace)

pnpm install
pnpm build

Notes:

The root package.json indicates a workspace layout with packages/* and scripts that run workspace builds/tests.
Tooling includes TypeScript and Vitest (for tests), and the repo references Vite configs for certain bundles.

Install the ASP.NET MVC host bridge

dotnet add package Muonroi.Ui.Engine.Mvc

Compatibility warning: the .csproj targets net9.0 (check your runtime/SDK availability).

Example usage

1) Bootstrapping rule-authoring custom elements from React

The README shows a React setup that loads custom elements and renders the flow designer:

import {
  MLoadRuleEngineCustomElements,
  MuRuleFlowDesignerReact
} from "@muonroi/ui-engine-react";

await MLoadRuleEngineCustomElements({ activationProof });

<MuRuleFlowDesignerReact
  graph={{
    nodes: [],
    edges: [],
    metadata: { version: 1, workflowName: "wf.orders" }
  }}
  apiBaseUrl="/api/v1"
  height={720}
/>;

What’s unknown: how activationProof is obtained and what exact fields it contains (it’s part of the commercial story).

2) A minimal (illustrative) manifest snippet

Based on the TypeScript contracts, a manifest is shaped roughly like this:

{
  "schemaVersion": "mui.engine.v2",
  "generatedAtUtc": "2026-04-14T00:00:00Z",
  "userId": "00000000-0000-0000-0000-000000000000",
  "tenantId": "tenant-a",
  "navigationGroups": [],
  "screens": [],
  "actions": [],
  "dataSources": [],
  "componentRegistry": {
    "components": {}
  }
}

3) MVC host: working with manifest models

The MVC package includes manifest models like MUiEngineManifest, MUiEngineNavigationGroup, MUiEngineScreen, etc. You can also use extension helpers like MVisibleItems() for view-level rendering logic:

@using Muonroi.Ui.Engine.Mvc
@using Muonroi.Ui.Engine.Mvc.Models
@model MUiEngineManifest

<nav>
  @foreach (var group in Model.NavigationGroups)
  {
    <h3>@group.GroupDisplayName</h3>
    <ul>
      @foreach (var item in group.MVisibleItems())
      {
        <li>@item.Title</li>
      }
    </ul>
  }
</nav>

Contribution guide and license

Contributing

The repo’s contributing guide highlights:

Default branch: develop
Prereqs: Node.js 20+, pnpm
Usual workflow: pnpm install, pnpm test, pnpm build
Keep the OSS/commercial boundary intact; add docs/tests when behavior changes.

Contributing guide:

https://github.com/muonroi/muonroi-ui-engine/blob/main/CONTRIBUTING.md

License (open-core / dual license)

The root license file describes a dual-license structure:

OSS core + adapters: Apache 2.0 (LICENSE-APACHE)
Commercial modules: Muonroi commercial license (LICENSE-COMMERCIAL)

License files:

Comparison to similar approaches (brief)

Compared to microfrontend orchestrators (e.g., single-spa): Muonroi UI Engine is centered on a backend-driven manifest + runtime + component registry, not only on “mount multiple frontends into one shell.”

Reference (microfrontends concept): https://single-spa.js.org/docs/microfrontends-concept/
Compared to low-code/internal tool builders (e.g., Appsmith): Appsmith focuses on a visual app builder with drag-and-drop widgets + integrations, while Muonroi UI Engine looks like a programmable runtime + adapters with optional embedded rule-authoring widgets.

Reference: https://www.appsmith.com/
Compared to form builders (e.g., Form.io): Form.io’s open source core is strongly focused on form rendering/builder, whereas Muonroi UI Engine’s scope includes navigation/screen composition plus rule-authoring widgets (decision tables/flows).

Reference: https://form.io/open-source/

Suggested tags and social blurb

Suggested dev.to tags

muonroi, typescript, webcomponents, react, angular, dotnet, lit, backenddrivenui, monorepo, opensource

Social blurb (3–5 lines)

Muonroi UI Engine is a manifest-driven UI runtime (open-core) that lets your backend describe navigation/screens/components—and renders them through React/Angular/PrimeNG adapters.

It also ships optional Lit-based rule-authoring widgets (decision tables, flow designer, FEEL playground, tracing).

If you’re exploring backend-driven UI + embeddable rule tooling, this monorepo is worth a look.

Repo: https://github.com/muonroi/muonroi-ui-engine

References

Repo deep map: https://github.com/muonroi/muonroi-ui-engine/blob/main/REPO_DEEP_MAP.md
single-spa microfrontends concept: https://single-spa.js.org/docs/microfrontends-concept/
Appsmith: https://www.appsmith.com/
Form.io open source: https://form.io/open-source/

Quick Codex: a lightweight workflow layer for Codex CLI

Le Anh Phi — Tue, 14 Apr 2026 09:50:02 +0000

Codex is very good at focused execution.

But once a task gets a little bigger, a familiar problem shows up: the work starts living in chat memory.

You clarify the task in one turn, research a few gaps in the next, begin implementation, then come back later and wonder:

What exactly was the agreed scope?
Which part is done?
What is the next safe step?
Can I trust the current state, or am I already drifting?

That pain point is why I built Quick Codex.

It is an open-source, lightweight workflow layer for Codex CLI. The goal is simple: make medium-sized work more resumable, auditable, and harder to derail.

Not bigger. Not more complex. Just more durable.

The problem is not coding, it is continuity

In my experience, raw Codex is strongest when the task is already clear and the execution window is short.

The trouble starts when a task spans multiple turns and the workflow stays implicit.

Something like this happens:

You explain the problem
Codex explores a few files
A plan starts to form
Implementation begins
Context gets fuzzy
The next step is no longer obvious
Drift starts

At that point, you are not fighting code generation anymore. You are fighting state loss.

That is the gap Quick Codex is trying to close.

What Quick Codex actually does

Quick Codex adds a small local workflow surface around Codex CLI.

Core capabilities

qc-flow → front-half work
qc-lock → strict execution

CLI utilities

status
resume
doctor-run
repair-run
lock-check
verify-wave
close-wave

Key idea: workflow state should live in files, not only in chat memory.

Two modes, two different jobs

qc-flow

Use when the task is still unclear.

qc-lock

Use when the scope is already defined and needs strict control.

Example commands

npx quick-codex install
node bin/quick-codex.js status --dir /path/to/project
node bin/quick-codex.js resume --dir /path/to/project
node bin/quick-codex.js doctor-run --dir /path/to/project

Experience Engine: AI Memory That Shrinks As Your Agent Learns

Le Anh Phi — Fri, 10 Apr 2026 01:44:43 +0000

Every AI coding session, my agent made the same mistakes.

DbContext as singleton — state corruption, 15 minutes debugging. Again. ILogger instead of IMLog — lost tenant context. Again. Wrong project reference path — build fails. Again.

I had 500 memory notes. My agent was still a junior with a bigger notebook.

So I built something different.

The Problem With AI Memory

Every AI memory tool — Mem0, Letta, Zep — stores facts. More sessions = more entries = more tokens = more cost. They're giving your agent a bigger notebook.

But here's the thing: a notebook doesn't make you experienced.

A junior developer with 500 notes is still a junior. A mid-level developer with 15 principles understands why things work. The difference isn't how much you remember — it's whether you can generalize.

Junior (500 notes):
  "DbContext singleton caused bug"
  "HttpClient singleton caused leak"  
  "SmtpClient singleton caused corruption"
  → Encounters RedisConnection singleton → NO MATCH → makes the mistake

Mid-level (1 principle):
  "Stateful objects must be scoped, never singleton"
  → Encounters RedisConnection singleton → MATCHES → avoids the mistake

That's what Experience Engine does. It doesn't store more facts. It evolves facts into principles, then deletes the facts.

How It Works

When you code with any AI agent (Claude Code, Gemini CLI, Codex CLI), Experience Engine runs silently in the background:

Before every Edit/Write/Bash:
A hook queries the experience store: "Have I seen this mistake before?" If yes, it injects a warning directly into the agent's context:

⚠️ [Experience - High Confidence (0.85)]: Stateful objects must be 
scoped, never singleton. Last time SingleInstance caused state 
corruption in DbContext.

The agent reads this warning and avoids the mistake. No human intervention needed.

After every session:
An extractor scans the session transcript for mistake patterns:

Retry loops (same tool call 3+ times)
User corrections ("no, not that", "wrong", "undo")
Test fail → fix cycles
Git reverts

Each detected mistake gets extracted into a structured Q&A entry and stored in a vector database.

Weekly (automatic):
The evolution engine runs:

Promote: entries confirmed 3+ times move from cache → behavioral rules
Abstract: clusters of 3+ similar entries → one general principle
Demote: entries ignored 3+ times get deprioritized
Archive: entries unused for 90 days get cleaned up

The result: memory shrinks as capability grows.

The 4-Tier Architecture

T0 Principles  (~400 tokens)  — generalized rules, always loaded
    "Stateful objects must be scoped, never singleton"

T1 Behavioral  (~600 tokens)  — specific reflexes, always loaded
    "WHEN DbContext + DI → MUST check lifetime FIRST"

T2 QA Cache    (semantic)     — detailed Q&A, retrieved on match
    Q: "Why not singleton?" → A: "State corruption across requests"

T3 Raw         (staging)      — unprocessed mistakes, TTL 30 days

Lifecycle: T3 → extract → T2 → promote (3x confirmed) → T1 
           → generalize (cluster 3+) → T0
           Memory SHRINKS as capability GROWS

What Makes This Different

	Mem0	Letta	Zep	Experience Engine
Over time	Entries grow forever	Entries grow forever	Entries grow forever	Entries shrink into principles
Novel cases	Only exact matches	Only exact matches	Only exact matches	Principles generalize
Mistake learning	No	No	No	5 detection patterns
Dependencies	Python + SDK	PostgreSQL	PostgreSQL	Zero (Node.js built-in)
Local-first	Optional	Optional	Partial	Default
Data ownership	Cloud vendor	SaaS terms	Cloud vendor	You own everything

Experience Graph

Experiences aren't isolated entries — they're linked with typed edges:

DbContext singleton ──generalizes──→ "Stateful objects: always scoped"
                    ──relates-to───→ HttpClient singleton  
                    ──supersedes───→ [old] "Use transient for DbContext"
                    ──contradicts──→ [demoted] "Singleton is fine for DbContext"

When one experience matches your current action, the engine follows edges to surface related experiences too. This is how it catches RedisConnection singleton — not because it's seen Redis before, but because it's connected to the principle about stateful objects.

Temporal Reasoning

Knowledge evolves. What was true in January might be wrong in March:

January:  "Use singleton for HttpClient" (confirmed 5x)
March:    "Use IHttpClientFactory instead" (contradicts January)
          → January entry superseded, not deleted
          → March entry ranks higher (recent confirmation)
          → GET /api/timeline?topic=httpclient shows the evolution

The engine tracks confirmedAt[] arrays — not just "what was learned" but "when it was last confirmed." Stale knowledge gets penalized. Recent confirmations get boosted.

REST API

Everything is accessible via HTTP — not just CLI hooks:

# Start the server
node server.js
# Experience Engine API running on http://localhost:8082

# Check health
curl localhost:8082/health

# Query experience before a tool call
curl -X POST localhost:8082/api/intercept \
  -H "Content-Type: application/json" \
  -d '{"toolName":"Write","toolInput":{"file_path":"src/Startup.cs"}}'

# Response:
{
  "suggestions": "⚠️ [High Confidence (0.85)]: Stateful objects must be scoped",
  "hasSuggestions": true
}

# Trigger evolution
curl -X POST localhost:8082/api/evolve
# {"promoted":2,"abstracted":1,"demoted":0,"archived":3,"success":true}

# View stats
curl localhost:8082/api/stats?since=30d

# Knowledge timeline
curl "localhost:8082/api/timeline?topic=dependency+injection"

# Experience graph
curl "localhost:8082/api/graph?id=abc-123"

10 endpoints total. Zero dependencies — uses Node.js built-in http module. CORS enabled for browser extensions.

Python SDK

from muonroi_experience import Client

client = Client("http://localhost:8082")

# Query experience
result = client.intercept("Write", {"file_path": "app.py"})
if result["hasSuggestions"]:
    print(result["suggestions"])

# Extract lessons
client.extract("Agent tried singleton for DbContext, caused corruption...")

# Trigger evolution  
evolution = client.evolve()
print(f"Promoted: {evolution['promoted']}, Abstracted: {evolution['abstracted']}")

# Check stats
stats = client.stats(since="7d")
print(f"Mistakes avoided: {stats['suggestions']}")

# View knowledge timeline
timeline = client.timeline("dependency injection")
for entry in timeline["timeline"]:
    status = "[superseded]" if entry["superseded"] else ""
    print(f"  {status} {entry['solution']}")

Zero dependencies — uses Python stdlib urllib. Python 3.8+.

Multi-User Support

Multiple developers on the same machine get isolated stores:

EXP_USER=alice node server.js    # Alice's experiences
EXP_USER=bob node server.js      # Bob's (completely isolated)

Share principles without sharing personal data:

# Alice shares a principle she evolved
curl -X POST localhost:8082/api/principles/share \
  -d '{"principleId": "abc-123"}'
# Returns portable JSON — no personal data included

# Bob imports it
curl -X POST localhost:8082/api/principles/import \
  -d '{"principle":"Stateful objects must be scoped","solution":"...","confidence":0.85}'
# Bob's evolution engine manages it independently from here

Quick Start (5 minutes)

git clone https://github.com/muonroi/experience-engine.git
cd experience-engine
bash .experience/setup.sh --local   # Docker Qdrant + Ollama (100% free)

The setup wizard handles everything. After setup, your agent starts learning automatically through hooks.

Supported providers

You're not locked to Ollama. The engine supports:

Embedding: Ollama, OpenAI, Gemini, VoyageAI, SiliconFlow, or any OpenAI-compatible API

Brain (extraction): Ollama, OpenAI, Gemini, Claude, DeepSeek, SiliconFlow, or any OpenAI-compatible API

Mix and match — e.g., SiliconFlow for cheap embeddings + Ollama for free extraction.

Anti-Noise Scoring

Not all experiences are equal. Results are ranked by:

Hit frequency — confirmed experiences rank higher
Recency — recently confirmed > stale (60+ days penalty)
Confidence aging — new entries start lower, climb with confirmation
Ignore tracking — suggestions ignored 3x get demoted
Domain match — editing .ts file → TypeScript experiences rank higher
Temporal boost — confirmed in last 7 days → score boost
Superseded penalty — replaced knowledge ranks lower

This means your agent gets the most relevant, most trusted experience for the current context — not just the most similar vector match.

The Philosophy

Every AI memory company stores your data on their cloud and charges you to access it. Mem0 stores your memories. Letta stores your agent state. You pay monthly to access your own knowledge.

Experience Engine is different:

Your data never leaves your machine (unless you choose cloud sync)
Zero vendor lock-in — standard formats, portable profiles
Zero dependencies — Node.js built-in modules only
The engine is open source — you pay for convenience, never for capability

"Enterprise AI replaces you. Personal AI empowers you. Same technology. Different owner."

What's Next

The engine is live and working. I'm dogfooding it on my own projects right now. After 2 weeks:

47 suggestions fired
12 mistakes avoided
5 principles evolved from ~50 raw entries
Memory footprint decreased (entries compressed into principles)

Next up: dashboard for visualizing the "Saves" feed (mistakes the agent didn't make), and a browser extension that injects experience into ChatGPT/Claude/Gemini web interfaces.

DEV Community: Le Anh Phi

Your AI coding CLI is expensive, forgetful, and overconfident. I built one that isn't.

Your AI coding CLI is expensive, forgetful, and overconfident. I built one that isn't.

Your AI coding CLI is expensive, forgetful, and overconfident. I built one that isn't.

TL;DR — the pain → the fix

Pain #1: One model gives you one confident answer — and sometimes it's wrong

Pain #2: Your AI coding bill is quietly $50–100/month

Pain #3: The longer the session, the more every turn costs

Pain #4: Your agent forgets everything and repeats the same mistake

Pain #5: UI regressions that unit tests can't catch (and screenshots are too flaky to)

Pain #6: "Why did that one prompt cost so much?" — and no way to tell

Pain #7: "Autonomous" agents that either need constant babysitting — or run wild with no audit trail

Try it

Muonroi Building Block: an open-core .NET foundation for rule engines, decision tables, and multi-tenancy

Executive summary

Key features and use cases

Key features (as described by repo README + deep map)

Practical use cases

Architecture and main components

Big-picture: rule execution pipeline

Big-picture: code-first rule authoring + generation

Monorepo layout (high level)

Installation and quickstart

Install the core rule engine packages

Quick example: write a rule in plain C

Generate the glue code and wire up DI

Run a sample (Rule Engine quickstart)

Run a sample (Decision Table quickstart)

Contribution guide and license

Contributing

License (open-core)

Comparison to similar projects (brief)

Suggested tags and social blurb

Suggested dev.to tags

Social blurb (3–5 lines)

References

Muonroi UI Engine: a manifest-driven UI runtime + rule-authoring web components (open-core)

Executive summary

Key features and use cases

Key features (from repo structure and deep map)

Practical use cases

Architecture and main components

Big-picture (how the UI engine flows)

Monorepo layout (high level)

Core runtime package: what’s inside

Optional commercial rule-authoring surface

Installation and quickstart

Build the monorepo locally (TypeScript workspace)

Install the ASP.NET MVC host bridge

Example usage

1) Bootstrapping rule-authoring custom elements from React

2) A minimal (illustrative) manifest snippet

3) MVC host: working with manifest models

Contribution guide and license

Contributing

License (open-core / dual license)

Comparison to similar approaches (brief)

Suggested tags and social blurb

Suggested dev.to tags

Social blurb (3–5 lines)

References

Quick Codex: a lightweight workflow layer for Codex CLI

The problem is not coding, it is continuity

What Quick Codex actually does

Core capabilities

CLI utilities

Two modes, two different jobs

qc-flow

qc-lock

Example commands

Links

Experience Engine: AI Memory That Shrinks As Your Agent Learns

The Problem With AI Memory

How It Works

The 4-Tier Architecture

What Makes This Different

Experience Graph

Temporal Reasoning

REST API

Python SDK