Several years ago, we started LitmusChaos with a simple belief: chaos engineering is not just for Ops. Litmus has since grown into a CNCF incubating project, and many SRE and platform teams use it to put chaos to work on Kubernetes.

But one moment kept nagging us. You are about to open a pull request. You added a retry, a timeout, maybe a fallback. You think it works. The honest way to find out is to make the dependency slow or flaky and watch, but that usually means a cluster, a platform team, or a throwaway script nobody will ever run again. So most of us skip it, and production runs the test for us.

So we built the other end of the loop, at the developer's desk.

litmus-lite is chaos testing for developers and their agents.

It is one static binary. You describe a failure and what must stay true, it injects the failure, watches your service, and tells you which of your statements held. No cluster, no control plane, no account.

From a sentence to a verdict

In Cursor (or any MCP client), you just ask:

Add 800 ms of latency to the checkout API for 12 seconds and tell me whether it copes and how fast it recovers.

The agent writes a *.chaos.yaml next to your service, validates it, runs it, and answers in terms of the hypotheses it wrote. The important part: the test is the file. Commit it, review it, change a number, and run it again without the agent. Every MCP tool is just a CLI command you could have typed.

It fits how developers already work

• Tests live in your repo. A scenario sits beside the service it tests and goes through code review like any other test.
• It runs where your tests run. In a terminal or in CI, with -junit for your test reporter. The exit code is the verdict: 0 every hypothesis held, 3 the run finished and one did not. That is a finding about your service, not a tool error.
• CI setup is one command. litmus-lite ci github writes a workflow that validates every scenario on every push.
• It can reach into your code. For Go services, a small failpoint package lets you put hooks in your own code. They stay dark until a scenario arms them, so you can fail "the charge step" and not just "the network".
• You stay in control. An agent cannot grant itself destructive permissions. Loopback targets only, PIDs you name, -yes for anything irreversible, and every fault is rolled back on exit or Ctrl-C.

A verdict you can trust

There is no "resilience: 73" here. You state what must hold, such as error_rate < 15% or recovery <= 5s, and the run reports which statements held. No data counts as a failure, and a service that never came back fails as "not recovered".

Every run also writes one self-contained HTML report that puts the fault next to its impact, so you can see the failure land and the service recover (or not):

A real red run: the sample service has no fallback, and the report says so.

Under the hood there is plenty to break: HTTP latency, errors and timeouts through a built-in proxy, failpoints, process pause and kill, docker pause, CPU and memory pressure, and disk fill. Add a load generator (VegaLoad, k6 or your own command) when you want to see what real traffic felt during the fault. And there is no telemetry: by default, nothing leaves your machine.

Try it in five minutes

# Grab a release: https://github.com/litmuschaos/litmus-lite/releases
litmus-lite init     # connects Cursor (MCP server + rules); other MCP clients work too

Then ask your agent for a failure. The quick start walks you through one green run and one red run against a sample service. The red one ends with a line I like a lot:

Hypothesis charge survives its own outage failed: error_rate < 5% (observed 100.00%).

A test that can fail, and tells you why in plain words, is the whole point.

Where this goes next

This is a start, not a finish. Directions we are excited about (ideas, not promises):

• Richer probes: request headers and bodies, JSON assertions, TCP probes.
• Per-probe hypotheses and breakdowns in the report.
• A published container image, so a scenario can also run as an in-cluster Job.
• More faults, driven by what you ask for, including reaching apps running in VMs and path to the bigger experiments on your Kubernetes clusters via the OG LitmusChaos!

Come build it with us

litmus-lite is Apache-2.0 and developed in the open, and the best time to shape it is now:

• Try it on your own service and tell us what broke, what confused you, and what you wished it did. Open an issue.
• Add a fault or a hub template. Faults are plugins, so adding one barely touches the engine. See CONTRIBUTING.
• Improve the docs, or share the prompt that made your agent do something clever.
• Say hi in #litmus on Kubernetes Slack.

Start here:

• Overview: litmuschaos.io/litmus-lite
• Docs: litmuschaos.github.io/litmus-lite
• Code and releases: github.com/litmuschaos/litmus-lite

Chaos engineering began as a way for teams to build confidence in production. We would love litmus-lite to help it start a little earlier, at the developer's desk, with a sentence and a file. Pip is waiting.

Uma Mukkara and Karthik Satchitanand, co-creators of LitmusChaos