LiminisA local-first context stack

What Liminis is ​

Liminis is a workspace for thinking with an amanuensis — a machine that reads what you write, keeps track of what is in it, and is available to work on it with you.

The premise is that this should not require handing your notes to anyone. Every part of it runs on your own machine, against a directory of ordinary files.

The workspace is a folder ​

Notes are markdown files in a directory you choose. There is no import step and no database that owns them: point Liminis at a folder that already exists and it works on what is there. Everything derived from those files — the search index, the context graph — is rebuildable from them, so the files remain the thing that matters and the rest is cache.

That constraint is what makes the rest tractable. Anything that can be regenerated can be thrown away, versioned with git, or inspected in a text editor when it misbehaves.

Material arrives from elsewhere ​

Notes rarely start in a notes app. Liminis takes handwritten pages from a reMarkable tablet, articles from a browser extension posting to a local endpoint, highlights from a reading app, and PDFs, audio, video or images dropped into the workspace — and turns them into markdown you own, filed and indexed.

A context graph is built from what you write ​

As material lands, an extraction pass turns it into a graph of entities, relationships, and episodes: the people, projects, and concepts in your notes, the facts connecting them, and a time-stamped record of which piece of text produced which fact.

This is the part that became Liminis Context Graph, and it now runs as a separate process that Liminis talks to over a socket. It is a single embedded engine — property graph, vector search, and full-text search in one place — with a plain-JSONL write-ahead log as its source of truth.

Search fuses three ways of looking ​

A single palette answers every query by fanning out to three independent retrievers and merging them with reciprocal rank fusion:

• a text scan over workspace files — needs no indexing, so it is always current and works even when the graph service is down;
• passage search — vector similarity over indexed content, which finds related material when the words don't match;
• entity and fact lookup — the structured knowledge extracted into the graph.

They are complementary rather than redundant, which is why the results are fused instead of one being chosen.

The agent sees the workspace through tools ​

The assistant is not a chat box bolted to the side. It reaches the workspace through in-process MCP servers that expose search, longer-running work items, and human-assigned actions as tools — and your own MCP servers plug into the same surface. Inference goes directly to the model provider with your own key; embedding runs locally where the hardware allows.

Everything renders where you are writing ​

Markdown, but also LaTeX, Mermaid, C4 architecture diagrams you can drag into shape, Marp slide decks, and handwritten reMarkable pages — rendered next to the writing rather than behind a preview toggle.

Two of those rendering paths are now standalone packages: Liminis Editor and Liminis Diagrams.

The application is in private alpha ​

Liminis Notes, the desktop application described above, is distributed to a small group of testers and is not generally available. That is deliberate, and it is not what this site is about.

What is available is the technology underneath it.

Why there are components at all ​

Liminis was not built as a set of libraries. It was built as an application, and the libraries fell out of it: each of these started as a subsystem and was extracted once it became clear it was useful to someone who would never run the app.

That order matters, and it shows in the shape of them. Each was pulled out of a working system rather than designed in the abstract, so each has a real consumer, a narrow seam where the application used to sit, and no dependency on the thing it came from. The editor renders in a host that supplies nothing at all. The context graph is a single binary you can point at a directory. The diagram library hands you a parsed syntax tree and a computed layout, and leaves the rendering to you if you want it.

They are MIT-licensed and independent of one another. You can take one and ignore the rest.

What you can use today ​

• Liminis Context Graph — a local-first context graph engine in one Rust binary. Property graph, vector search, and full-text search in a single embedded process.
• Liminis Editor — a Lexical-based markdown WYSIWYG editor that round-trips through mdast, embeddable in any host.
• Liminis Diagrams — C4 architecture diagrams for JavaScript: parse, lay out, render, drag.

Read about each one →