Maka keeps your agent's memory in a local SQLite log, not the cloud

What it does

Maka inspects projects, executes local tools like Read, Write, Edit, Bash, and Grep, and produces artifacts through a desktop Electron app, a terminal TUI, a non-interactive CLI, and a headless runner for long-running tasks. Every model message, tool call, and result is written to an append-only local SQLite log instead of being treated as disposable chat context. You bring your own model via cloud API, local endpoint, or compatible gateway.

The interesting bit

The architecture treats the immutable Runtime Event Log as the single source of truth: sessions, UI state, and model context are merely projections over that log. The system prunes tool results and compacts LLM context without destroying evidence, while a separate Task Event Log lets durable work survive crashes, pauses, and retries via budgets and continuation logic.

Key highlights

• Local-first by default: sessions, settings, and run records stay on your machine; you supply the model via cloud API, local endpoint, or compatible gateway.
• Immutable execution log: canonical state lives in runtime.sqlite, with legacy data migrated through fingerprinted, crash-safe cutover journals.
• Permission engine: file writes, shell commands, and dangerous tool calls pass through a permission policy with watchdogs and abort controls; the renderer never receives plaintext credentials.
• Multi-surface runtime: the same backend powers the desktop app, terminal TUI, non-interactive CLI, and headless evaluation runner.
• Durable tasks: headless mode supports interruptible TaskRun graphs with isolated Git worktrees, self-check evidence, and result export.

Caveats

• The desktop app is an early public release for Apple Silicon Macs only; Intel Macs, Windows, and Linux builds are not yet supported, and data formats may still change.
• Runtime credentials currently reside in a local plaintext credentials.json protected by POSIX permissions, though legacy tokens are decrypted via Electron safeStorage only once at startup.
• “Computer Use” is not included in this first public build, and complete automatic self-iteration remains an external or experimental workflow.

Verdict

Developers who want an inspectable, recoverable agent that treats local storage as the authority rather than a cache should look here. If you need a polished, cross-platform desktop assistant or a fully autonomous self-improving agent, this is still too early.