Memex: A Local-First AI Journal That Turns Fragments Into Markdown Cards

The problem is that journalling apps ask you to write, and most days you do not

Memex is aimed at people who accumulate small pieces of life and never turn them into entries. A photo of a receipt, a voice note on a walk, a sentence about a book, a measurement from a scale. The README frames the product against traditional journalling apps directly: instead of asking you to sit down and write polished entries, it lets you capture fragments and hands the sorting to an AI system. That is a real distinction and it changes what the app has to be good at. It does not need a nice writing surface. It needs a capture path short enough that you use it, and an organisation layer accurate enough that the fragments are findable later. The target user is closer to someone running a personal knowledge management habit than to a diarist. The topic list on the repository says as much: personal-knowledge-management, life-logging, pkm. If you want a blank page and a date header, this is more machinery than the task requires.

One orchestrator agent, a set of specialist skills, and cards as the unit of output

The architecture described in the README is a single conversational agent that coordinates specialist skills and child agents. The named responsibilities include timeline cards, PKM filing, schedule updates, knowledge insights, diagnostics, comments, memory curation, media handling, and companion chat. So the flow is roughly: a fragment arrives, the orchestrator decides which skills apply, and the result is written as a card. Cards are typed. The README groups them into life and productivity (task, routine, event, duration, progress), knowledge and media (article, snippet, quote, link, conversation), people and places (person, place, with map preview), data and metrics (metric, rating, transaction, spec sheet), and a visual gallery type for photos. On top of that sit insight cards, which are generated across records rather than from one record: charts (trend, bar, radar, bubble, composition, progress ring), narrative forms (highlight, contrast, summary), and spatial or temporal forms (map, route, timeline). The knowledge layer is organised on P.A.R.A: Projects, Areas, Resources, Archives. The design choice worth noting is that the LLM is not asked to produce prose you read once. It is asked to produce structured records that persist and get cross-referenced. Auto-tagging, entity extraction and cross-reference linking are listed as part of that. Whether the extraction is reliable enough to trust is not something the README addresses, and I have not run it, so treat card accuracy as the first thing to probe on your own fragments.

Bring your own model: what the provider table actually commits you to

Memex does not bundle a model. You supply one, and the README lists the options with their API types. Google Gemini is supported through the Gemini API and through an OAuth sign-in path that needs no API key, which the README labels unofficial and says to use at your own risk. The same warning applies to the ChatGPT OAuth path. OpenAI is supported via Chat Completions and the Responses API. Anthropic Claude has its own entry, and AWS Bedrock is listed for Claude models. Beyond those, the OpenAI-compatible column covers Kimi (Moonshot), Aliyun (Qwen), Volcengine (Doubao), Zhipu GLM, DeepSeek and MiniMax. There is also an optional Memex AI service described as managed model access, which the README says only proxies model requests and does not store your journal. That last point deserves precision. A proxy is a different trust boundary from a direct call, even when the operator states it does not retain data. The README's claim that prompts go directly from your phone to your provider is true for the direct provider paths. It is not the same statement for the managed path. If the distinction matters to you, choose a direct provider or a local endpoint. Ollama is named in the repository description as a supported option, though it does not appear in the provider table in the README text supplied here.

Storage, export and the Markdown bet

Data lives in the filesystem plus SQLite, according to the README, with an app lock behind biometric authentication. Storage location is selectable: iCloud Drive, a custom folder on device storage, or app storage. There is a one-tap full backup and restore. The archiving story is the part with the strongest argument behind it. After AI organisation, records settle into interconnected Markdown files, and the README describes one-click export of everything as standard Markdown for migration to any note-taking app. The stated reasoning is that plain text outlives model churn: as LLMs change, simple records remain readable and re-processable. That is a defensible position and it is the main thing separating Memex from a hosted AI journal, where the value sits in a database you cannot take with you. It also means the export format is the real contract. Before committing a year of entries, export a week of them and open the files. Check whether the front matter, tags and cross-references survive the round trip, because a Markdown export that flattens structure is technically portable and practically lossy.

The AI companion layer, and why SillyTavern compatibility is the interesting detail

Memex includes AI characters that comment on new timeline cards and hold one-to-one conversations, with memory described as persistent across both the comment and chat scenes. The mechanism that matters here is the import format: the README states compatibility with SillyTavern character cards in V2 JSON and PNG form, including persona, world book and example dialogues. That is a concrete interoperability choice rather than a vague claim of extensibility, and it means existing character definitions can be moved in rather than rebuilt. It also tells you who this feature is for. If you have never used a character card, the companion feature is a chat surface bolted to your journal. If you have, the appeal is obvious: the same persona you use elsewhere now has access to your own timeline and knowledge base as context, which is a different proposition from a general-purpose chat client. The README does not describe how memory is stored, how it is pruned, or what the context window budget looks like when a character has months of cards to draw on. Memory curation is listed as one of the orchestrator's skills, which suggests it is managed rather than unbounded, but the policy is not documented in the material available here.

Getting it running, and where the build situation actually stands

The practical path is the one most users will take: install from the App Store or Google Play, then configure a provider. The README links both store listings. For the provider step you pick an API type and supply credentials. For the OAuth routes (Gemini with a Google account, ChatGPT with an OpenAI account) no API key is entered at all, and both are marked unofficial. For the API-key routes you paste a key for OpenAI, Claude, Gemini, Bedrock, Kimi, Qwen, Doubao, GLM, DeepSeek or MiniMax. The repository itself is Dart, default branch main, licensed GPL-3.0. The release feed supplied here contains only Android builds, dated 2026-09-08 through 2026-09-09, all tagged with the android-early prefix and a short commit hash. That naming is the honest signal in this whole listing. There is no stable channel in the feed, no iOS artifact, and the cadence is roughly daily, which for a journal app holding your personal records is a meaningful risk: daily Android early builds are not a release process you want underneath data you care about. If you build from source instead, note that the README does not document a build procedure, a Flutter version, or the environment setup in the material provided, so plan on reading the repository rather than following a guide.

Where Memex is the wrong tool

The clearest failure mode is the dependency itself. Every organisation feature described here runs through a model. If your API key expires, your quota runs out, or your local endpoint is off, capture may still work but the filing, insight generation and companion commentary do not. A traditional journalling app degrades to a text editor in that situation. Memex degrades to a folder of unprocessed fragments. That is a real difference and it is not addressed in the README. The second limitation is the maintenance surface. Supporting roughly a dozen providers across four API shapes (Gemini API, Chat Completions, Responses, Bedrock) means every provider-side change lands on this project. The OAuth paths carry their own warning in the README, which is appropriate: unofficial sign-in flows break without notice. The third is the platform split. The release feed shows Android early builds only, and the iOS app is distributed through the App Store, which means iOS users get whatever the store review cycle produced rather than a version they can pin. If you need a reproducible build on both platforms, this is not the project for that yet. Finally, GPL-3.0 is a copyleft licence. Using the app is unproblematic. Reusing its code inside a closed product is a different question, and the answer is one for your own counsel rather than for this article. The licence identifier is stated in the repository; the obligations that follow from it are not something a review can settle for you.

The alternative: Obsidian plus a capture shortcut

The obvious comparison is a plain Markdown vault in Obsidian, or Logseq, with a mobile capture shortcut and a plugin that calls an LLM. The difference in approach is where the intelligence sits. In Memex the agent pipeline is the product: it decides what type of card a fragment becomes, files it into P.A.R.A, and generates insight cards across records. In an Obsidian setup the vault is the product and any AI is a command you invoke on a note you have already made. That gives you determinism (nothing is reorganised without you asking), a plugin ecosystem, and no provider lock-in at the app level, at the cost of doing the filing yourself. Memex's bet is that the filing is the tedious part and worth automating. Its export path is what makes the bet reversible: because records land as Markdown, moving from Memex to a vault is a file copy rather than a migration project. If you already run a vault you are happy with, adding Memex means two places your notes live, and the export is the only thing keeping that from being a trap.

Editorial conclusion

Adopt Memex if you already have an LLM API key or a local Ollama endpoint, you want your journal to end up as plain Markdown files you can move, and you accept that the Android build is labelled early. Do not adopt it if you need a stable, versioned release channel today, if you want the app to work with no model provider at all, or if you are not prepared to review GPL-3.0 obligations before embedding any of this code in your own product. Verify three things first: which storage location the app writes to on your device (iCloud Drive, a custom folder, or app storage), what the one-tap export actually emits, and whether your chosen provider is reached through the direct path or through the optional Memex AI proxy, because the proxy is a different trust boundary even though the README states it does not store the journal.

Official sources

1. License: GPL-3.0
2. memex-lab/memex on GitHub
3. Project website
4. README
5. Releases