Agent runtimes have mostly been a single-repo, single-vendor affair. Apache Maka is an agent runtime that's gone through the Apache Software Foundation's incubation intake. But the Apache stamp isn't the interesting bit on its own. It's the design decision underneath: Maka treats the append-only execution log as the runtime, and treats the chat UI and the model's context window as views over that log. Everything else follows from that.
If you've spent time with coding agents, you know the frustration this targets. A long session eats context, the model forgets what it did, and you lose the trail of exactly what tools ran and why. Most agent tools keep the transcript in the chat UI and let that be the source of truth. Maka flips it: model messages, tool calls, tool results, permission decisions, and termination events all land in one append-only event log, and sessions, UI state, and recovery are projections computed from that log rather than independent copies.
The consequence is that shortening context doesn't mean deleting history. Maka can keep old tool output out of the next prompt without throwing away the saved evidence, because the record and the prompt are two different things. That's what makes long-running, recoverable agent work plausible instead of a hope.
The log is the runtime
Every surface, from the Electron desktop app to the terminal TUI, the non-interactive CLI, and the headless evaluation runner, funnels through one execution authority called Runtime Host. The architecture document is blunt: "Maka has one execution authority: Runtime Host." Desktop, TUI, CLI, bots, and evaluation clients all ask it to run work, and none of them owns a second runtime. @maka/eval only owns experiment semantics, such as subjects, tasks, repetitions, cells, immutable attempts, and budgets. It never reaches into the runtime directly.
Storage is SQLite on your machine, under the user's own data directory: runtime.sqlite, a connection catalog, a credential vault, settings, and artifacts under Electron userData by default. Cloud sync isn't shipped. Maka is single-tenant and local-first by design.
You bring the model. There's no bundled model account; you point Maka at a cloud API, a local model, or a compatible gateway. The workspace and tool execution stay on your machine while the inference provider is whatever you chose.
What "append-only" buys you
The payoff is recovery and reproducibility. Maka records how a turn ended, keeps a durable execution record, and can resume an interrupted turn. Newer releases keep tightening things. v0.1.11 preserved live turns across a refresh, kept restored tasks safe from concurrent removal, and bounded summarizer inputs. With an event log, those failure cases come down to replaying facts that exist independent of the prompt, not reconstructing whatever the model happened to output.
It also makes evaluation more honest. maka eval run <spec> --out <directory> runs declarative multi-arm experiments expanded into task by repetition by subject cells. When a cell has multiple attempts, the earliest valid attempt is authoritative, so operators can't hand-pick a favorable outcome. The result kernel is deliberately small: score, normalized usage, attributable cost, duration, status or failure reason, and artifacts.
A security story that doesn't oversell
Maka's security policy is explicit about what it does not claim. Its position: the only real enforcement boundary against an adversarial LLM is the operating system, not any in-process screen. The permission engine, output redaction, URL allowlists, and the fail-closed web-search chain are called what they are: useful UX safety nets that slow an adversary down enough for a human to notice, not containment.
The load-bearing boundaries are the OS user account, a credential store with 0o700/0o600 file permissions and atomic writes, the sandboxed renderer with a masked IPC bridge, and masking of tokens at the settings boundary. Notably, Maka does not run tools in a separate process or container by default. There's a macOS Seatbelt command transformer in the runtime, but the project is candid that current product compositions don't route command execution through it yet. That honesty about ceilings reads better than the usual trust me.
The Apache angle
Maka entered incubation on 2026-08-13, per the ASF incubator status page. That matters because the ASF brings expectations a startup repo doesn't: neutral governance, community oversight, and a path to a real source release instead of convenience artifacts. Right now Maka hasn't made an Apache release yet. A banner across the README makes clear that published packages were produced before or during incubation and haven't been reviewed by the incubator PMC. For now the README recommends building from source.
There are active limitations. The desktop build targets Apple Silicon macOS (arm64) as the supported tier; Intel Macs and Linux are unsupported so far, and Windows is an unsigned preview. Computer Use ships as a bundled skill but its executor is excluded from releases for now. The CLI is an early beta (maka-agent@next). This is early software; the appeal is the architecture and the governance, not polish at this stage.
The verdict
Maka is a real shift in framing for agent tools: stop optimizing the chat transcript, start recording execution as facts, and let everything else be a projection. Whether it succeeds depends on whether the event-sourcing rigor survives contact with the broader ecosystem, and on whether the ASF's process brings adoption rather than just process. Still, it's a welcome change of pace to see an agent runtime designed around auditability and recovery from day one, in a foundation that treats those as a feature.
Sources: the repository, architecture doc, security policy, release notes, ASF incubation status, and the incubator proposal.