Launching today
Kinet Aios
One dashboard for Claude Code, Codex & a built-in agent
11 followers
One dashboard for Claude Code, Codex & a built-in agent
11 followers
KinetAios is a local-first AI agent dashboard. Run multiple sessions in parallel, switch between a built-in ReAct agent, Claude Code and Codex, bring your own model (OpenAI-compatible / Anthropic), plug in any MCP server, and keep everything on your machine β SQLite history, long-term memory, no account required.
Local-first setup sounds great, especially the no-account and SQLite history bits. One thing that would really help me as a daily user is a diff view for the ReAct agent's tool calls, so I can quickly see exactly what files or commands it touched before it finishes a run. Right now I have to scroll through raw logs to reconstruct what happened. A side panel that shows the diff in real time and lets me approve or reject each step would make long sessions way less anxiety-inducing.
@derinalmargwooΒ Hi,
Thanks β appreciate the specifics. Agree local-first + SQLite history is
the right baseline; glad it lands for you.
The diff view + per-step approve/reject is the most useful feedback I've
gotten this week. Honest status of where things stand:
- Shell commands already gate through a confirm modal (when approval is
set to "always")
- Tool calls (write_file, read_file, shell, web_fetch, etc.) render as
- No dedicated side panel yet β everything renders inline under each
answer
- Approve/reject is shell-only, not per-step on every tool
What I'm planning, in the order I can ship them cleanly:
1. Before/after diff on write_file step cards β small, monospace, +/-
colors. Days, not weeks.
2. Side panel that consolidates the current turn's tool calls in one
scrollable view. Same data as the inline steps, just easier to scan
mid-run.
3. Per-step approve/reject for write_file (and any tool, not just shell).
This is the real design call β interrupting the ReAct loop mid-batch means
handling aborted partial state, so I want to land (1) and (2) first and
make the panel the surface where approve/reject actually happens.
If you're up for it, a screenshot of a long session where the current step
view broke down would help me size the panel and pick which fields to
surface first. Will ping you when (1) is in.
Thanks again for the writeup.
How does the long-term memory actually work under the hood with SQLite, and does it get shared across the different agent types or stay siloed per session?
@aydn87772573347Β
β Two good questions, let me take both.
β
β Is it embedding search?
β
β No β and that was a deliberate choice. We use two distinct mechanisms,
β both running on local SQLite (better-sqlite3, FTS5 enabled):
β
β 1. FTS5 keyword search over raw history. Every user message, assistant
β reply, and tool result gets appended to a full-text-search virtual
β table. When the agent needs to recall something specific, a
β recall_memory tool runs a MATCH query β fast, deterministic, zero vector
β overhead. Embeddings would have meant shipping a model and a vector
β index for marginal gains on the conversational recall use case.
β 2. Structured long-term facts (memories table). After each turn, an
β async job asks the model to extract durable facts about you β your
β stack, your preferences, recurring patterns β and stores them as a flat
β list. On the next turn those facts get injected into the system prompt
β so the agent starts already knowing your context. This is the
β "structured" part you were asking about.
β
β So: FTS5 for recall (search past conversations) + a curated fact table
β for continuity (carry preferences forward). The two work together β
β search pulls specifics, facts pull generalizations.
β
β Can you inspect or edit it?
β
β Honest answer: not yet, and that's the gap I'm most aware of. Right now
β the data lives in a SQLite file under your user data directory, so
β technically you can open it with any SQLite client and SELECT * FROM
β memories β but there's no UI for it. No list view, no edit, no delete,
β no export button.
β
β That's changing soon. We're adding:
β - A Memory panel in settings β list every extracted fact, delete the
β wrong ones, edit imprecise ones
β - Per-project isolation so a fact learned in repo A doesn't leak into
β repo B (today it's global)
β - Export to JSON / Markdown for backup and portability
β - Expiry β facts that haven't been referenced in N days auto-expire, so
β noise doesn't accumulate
β
β All four are tracked in our public improvements log. If you want early
β access to the memory panel build, ping me β happy to send a test build
β before it ships broadly.
β
β Appreciate the question β it's exactly the right thing to push on for a
β tool that holds this much context about you.
How does the long-term memory actually get stored and retrieved across sessions, and can I inspect or export it? Curious whether it stays truly local or quietly syncs somewhere.
@recep728172Β export and import just shipped.
How does the long-term memory actually work under the hood β is it just embedding search over past sessions, or something more structured that I can inspect and edit?
@zgepirazcraqΒ export and import just shipped.
How does the long-term memory actually work under the hood, and can I inspect or export what's stored in the local SQLite db?
@toprakcwekΒ export and import just shipped.
β Good news on the inspect/edit/export front β export and import just
β shipped.
β
β What landed today:
β - Export β Settings β Long-term memory β Export as JSON. Picks a save
β path via the native file dialog, writes a structured file ({ version,
β exportedAt, memories: [{ content }] }). Back it up, share it, diff it.
β - Import β Same section β Import from JSON. Reads the file (lenient:
β accepts the structured form, a bare array of strings, or an array of
β {content} objects), dedupes against existing memories, and reports how
β many landed vs. how many were skipped as duplicates.
β
β What's still coming:
β - In-app list/edit/delete UI β right now the only way to inspect is to
β export and read the JSON, or open the SQLite file directly. A proper
β Memory panel is next.
β - Per-project isolation β today memories are global; we're adding a cwd
β axis so a fact learned in repo A stops leaking into repo B.
β - Expiry β auto-prune memories that haven't been referenced in N days.
β
β Under the hood: it's still the same two-mechanism design (FTS5 keyword
β search over raw history + a structured memories table of LLM-extracted
β facts), both in local SQLite β nothing leaves your machine.
β Export/import operates on the structured table; the FTS history stays
β put since it's derivable from your past conversations.
β
β If you want to drop me a backup file you've exported, happy to look at
β it and confirm the format round-trips cleanly on re-import.