Why?

Why another API mock server? Because the alternatives are either toys that lie to you or projects you have to babysit. Mocking should be neither. Here is what akuma believes.

1. Mocking should be easy, not a project.

   A few lines of YAML and one command. If standing up a fake backend takes longer than the feature you are prototyping, the tool has already failed you.

2. Configurable, because real APIs are messy.

   Production is full of inconsistent shapes, odd status codes, and endpoints that disagree with each other. A mock that only serves the happy path teaches you nothing. akuma lets you model the mess on purpose, per route.

3. A real server, not static types.

   Type stubs and fixtures rot the instant you touch the code, and they drag you back into hand-writing mock logic. akuma runs an actual HTTP server backed by a real SQLite database, so your client talks to something that behaves, not a hardcoded blob.

4. Close to the code, part of CI and CD.

   The definition lives in your repo, next to what it serves. It runs in a pipeline, a container, a test job. Reviewed in pull requests, not buried in a GUI nobody opens.

5. Versionable like everything else.

   Your API has versions. Your mock should too. It is a text file under git: branch it, diff it, roll it back, tag it to a release. Pinning a versioned project to a static, un-versioned API is how you lose an afternoon.

6. Collaborative, and offline.

   Share one config and the whole team runs the same server, no "works on my machine." Push it to the cloud when you want a shared, always-on URL, but you are never forced to. On a plane with no signal, it still starts.

7. Built for the age of AI agents.

   Agents need a backend to act against, and they need it now, not after a human provisions one. A config an agent can read, write, and run unattended is the line between an agent that ships and one that just talks. akuma is built so an agent can just use it.

That is the bar. akuma is built to clear it, without mercy.