Most second brain apps stop at storage. You capture a note, tag it, link it, and hope you find it again someday. NeverWrite is built around the idea that your second brain should actually help you think, not just hold your thoughts. It's a local-first desktop app for macOS and Windows where your notes are plain Markdown files on your machine. No cloud sync, no account required, no telemetry. Your vault is yours.

The part I'm most excited about is the AI layer. NeverWrite supports agents powered by Claude, Codex, Gemini and Kilo, that work directly inside your vault. You can ask an agent to help you synthesize notes on a topic, find connections you missed, or draft a new note from your existing material. The key thing is that agents propose edits and you review them before anything changes, it has inline review hunks like modern code editors. The AI helps you process and connect your knowledge; it never rewrites your vault behind your back. That felt like the only honest way to build this.

If you've been frustrated by second brain tools that are great at capture but useless at synthesis, or by AI tools that feel like a black box you can't trust, NeverWrite is trying to solve both at once. Happy to answer any questions about how the agent review flow works or anything else.

Also, is open source ;)

https://neverwrite.app/

https://github.com/jsgrrchg/NeverWrite

Have fun with your vaults!

Ask questions across your Markdown notes using a fully local Graph RAG engine. Built for Obsidian vaults, works with any folder of Markdown files. Extracts entity-relation triples from wikilinks & YAML frontmatter, retrieves answers via hybrid search (vector + BM25 + temporal). Multilingual. No cloud. Runs on Ollama.

https://github.com/benmaster82/Kwipu

Dev here, 20 years in. Built Editorio for myself a while back because nothing on the mac did everything I wanted in one place. It's polished enough now that I figured I'd share it.

Subscription text editor. Subscription notes app. Subscription markdown previewer. (lol). We live in the future. Macs have neural engines, and the industry's answer to "I want a nice text editor" is 4.99/month to render # heading as bold text. Cool.

Problem

Most Mac markdown editors are either Electron bloatware (500MB+ RAM, slow cold start) or behind a subscription / one-time fee just to render basic markdown. And most code editors don't do markdown preview well. I wanted one fast native app that handles both: markdown writing AND code files, without paying rent on a monospace font.

Comparison

• vs Typora: Typora is 14.99 USD one-time and not native AppKit. Editorio is free and native, opens files in under 100ms.
• vs iA Writer: iA Writer is ~50 USD and writing-focused. Editorio also handles 180+ programming languages with syntax highlighting, so it doubles as a code editor.
• vs VS Code: VS Code is Electron, ~500MB RAM, slow cold start. You don't need a full IDE just to open a markdown file or peek at some code. Editorio is ~40MB RAM, native AppKit, instant launch.
• vs Sublime Text: Sublime is 99 USD per license and still doesn't do real markdown preview out of the box. Editorio is free and ships with live markdown preview built in.

Pricing

Free. Forever. No nag, no asterisk, no "free for personal use only".

https://apps.apple.com/app/editorio/id6759334075

What's in it:

• Markdown editor with live preview
• Code editor with syntax highlighting (swift, py, ts, rust, etc.)
• Mac native, AppKit. No Electron, no web views
• Light/dark themes, minimap, tabs
• ~40MB RAM, lightning fast

Me posting to reddit is the entire marketing budget. Already gave Apple my 100 bucks for the dev account, so if you actually like it, send it to a friend or drop it in a Slack somewhere.

Planning to open source it on github too once I clean up the repo.

Long live free apps instead of charging rent on a monospace font.

Edit: since so many of you keep insisting... yes, fine, you can buy me a coffee. I'm genuinely a little embarrassed about it, but here we are.

MarkdownAI adds one line to the top of any .md file and makes it live.

MarkdownAI Directives

All directives available in MarkdownAI, organized by category.

Document Structure

Directive	Purpose
u/markdownai	Document header - activates the MarkdownAI runtime
u/include	Inline file content at the directive site
u/import	Import definitions (macros, connections) without rendering content
u/define / u/end	Declare a named macro
u/call	Invoke a macro
u/phase / u/end	Declare a workflow phase
u/if / u/end	Conditional block
u/section	Named section boundary
u/chunk-boundary	Explicit chunk split point for rendering

Variables & Environment

Directive	Purpose
u/env	Resolve an environment variable

Data Sources

Directive	Purpose
u/connect	Register a named data source connection
u/db	Execute a database query
u/http	Fetch from an HTTP endpoint
u/query	Query a registered data source
u/read	Read raw file content
u/list	List directory contents
u/tree	Directory tree output
u/date	Current date/time
u/count	Count items in a source

Processing & Output

Directive	Purpose
u/pipe	Chain output through transformations
u/render	Render output in a specific format
u/graph	Generate a visualization
u/header	Document-level metadata header

Annotations & Constraints

Directive	Purpose
u/constraint	Machine-readable rule or constraint
u/define-concept	Vocabulary alignment - bind a term to a precise definition
u/prompt	Embedded instruction for the AI reading the document
u/note	Human-readable annotation (not rendered in AI format)

Caching

Directive	Purpose
u/cache	Cache directive output (option on data source directives)

Phase Events

Directive	Purpose
u/on complete ->	Declare what executes when a phase finishes (only valid inside u/phase blocks)

What is MarkdownAI? There seems to be a lot of confusion.

Most people assume MarkdownAI works like this:

Claude reads a rendered MarkdownAI file and acts on it.

That's not what happens.

Yes, MarkdownAI can parse and render a .md file into a result - and that's perfectly useful if you're using it as a CLI tool. But that's not why it's called MarkdownAI.

The reason it's called MarkdownAI - and where the real power comes from - is the MCP server, the hooks, and the phase design.

Here's what actually happens:

Claude requests a .md file. The MarkdownAI MCP server intercepts that request. Instead of dumping the whole rendered file into context, it reads the document, identifies the current phase, and hands Claude only what it needs for that phase - exactly like a human would prompt it.

Claude never sees the whole document. It only gets the current phase plus its constraints. This means Claude is always aligned - it only knows what it should know, and it's always working within the boundaries defined for that phase.

This means:

• Massive token savings - Claude isn't processing 890 pages of documentation on every request
• No stale context - each phase is executed fresh with live data
• No hallucination about what exists - the runtime tells Claude exactly what's there
• Always aligned - constraints are delivered with every phase, not assumed

The power isn't the markdown format. The power is the MCP server turning a document into a live, phase-aware, always-aligned conversation between Claude and your codebase.

That's MarkdownAI.

GitHub: https://github.com/TheDecipherist/markdownai

npm: https://www.npmjs.com/package/@markdownai/markdownai

MarkdownAI - GitHub

It's been a bit of a long time coming, but I finally managed to get version 1.5 out with better support for cross document links and support for table of contents. Use of [TOC] as a tag in markdown will produce an auto generated, auto-updating table of contents. If you have other table of contents tag formats, we support every tag format we could find. Oh, and our word export creates an actual word table of contents for that, not just a list of links.

Cross document links was a bit of a hard subject - Obsidian style links are standard, so we support those. GFM slugs are different but "more correct" so we support those as well. Those are both a bit fragile though - if someone comes along and changes a heading name in a document you've linked to then your link gets broken, so we also support ID based heading links. That does need you to write the id to the end of the heading, which possibly involves updating the other file to add a heading, but it's worth it to keep references stable in codebase documentation. You can pick the model you prefer.

Outside of that, the back and forward navigation needed to get smarter and take you to the right scroll position in the target document. That was a pig as there's a lot at play with document dynamic loading, but hopefully you'll find it's all working pretty smoothly now.

The usual general quality of life updates too - users reported loss of selection highlight so that's fixed along with some other issues and bug fixes. All in the release notes. Starting to get close to where I envisioned the "base" functionality being!