Launching today
OpenMarkdown
A markdown editor you and your agent co-edit
154 followers
A markdown editor you and your agent co-edit
154 followers
A fast, light markdown editor that opens any `.md` file instantly. Your agent reads, writes, and co-edits the same file you're in — through a CLI, an agent plugin, and MCP. Local-first: no account, no telemetry, your files never leave your disk.
OpenMarkdown
Co-edit mode writing into the same .md file I'm actively typing in is the part I'd stress-test first — most 'agent + editor' tools use a separate pane precisely to dodge that. When the agent and I write to the same section at once, how does it reconcile: file-watch reload with last-write-wins, or an actual diff merge so my in-flight edits aren't clobbered? And since you dropped caching for RAM on Tauri 2, does peek-open stay instant on large multi-MB markdown, or is that where the no-cache tradeoff shows?
OpenMarkdown
@hi_i_am_mimo You're stress-testing exactly the right thing 😊
On reconciliation: it's not a file-watch reload with last-write-wins. Agent writes are section-scoped and land as a transaction in your live buffer. If you're both in the same section, it's optimistic concurrency — every agent write carries a hash of what it read, and if you've touched that section since, the write is rejected (not merged, not overwritten). Your in-flight edits are never clobbered; the agent re-reads and retries. The plain .md stays the source of truth.
On speed: peek-open stays instant for everyday files — dropping the cache is about not hogging RAM (personally, I'd be frustrated to see a "simple editor" eat a huge amount of it). In my own daily use I haven't hit response-time issues with large .md files.
Would love your stress-test notes~
The concurrency answers here all assume the agent sends a small edit, but in practice most coding agents rewrite the whole file even for a one-line change. When an agent edited a CLAUDE.md I was mid-sentence in, the pain wasn't a merge conflict, it was losing my cursor position and undo history to a wholesale rewrite that section-level hash-CAS still treats as one big dirty region. Do you constrain the agent to patch anchored ranges, or accept a full write and reconstruct the minimal diff yourself?
OpenMarkdown
@dipankar_sarkar Sharpest version of the question — thank you.
Short answer: both, and which one kicks in depends on whether the agent goes through our MCP tools or just writes the file itself.
- Through our MCP (write_section): the agent is constrained to an anchored range — it patches a section by heading, never the whole document (there's no full-document replace).
- Writing the file directly (the case you hit — most agents rewrite the whole thing with their bash tool): we diff the new file against your live buffer and apply only the minimal change, as a remote edit, so your cursor maps through it instead of resetting.
Honest limit: if the rewrite also reflows the whole file, the "minimal" diff stops being minimal — and keeping the agent's edit out of your undo stack is still on my list (still looking for the best design for the best user experience).
You've named the real open gap. Would love your take on anchoring that survives a reflow~
The co-editing angle is the interesting part. The section-scoped hash-CAS approach makes sense for simple edits, but OT and CRDTs usually struggle with the same edge case: an agent producing a large structural rewrite while a user is mid-sentence in that region. Does it fall back to last-writer-wins, or is there a way to express intent at finer granularity than section level?
OpenMarkdown
@anand_thakkar1 Thank you for the insightful question~
Not last-writer-wins — that's the line I most wanted to avoid. On a stale write (section-scoped) the agent's edit is rejected (the section's hash no longer matches what it read) and it re-reads; your in-flight text is never overwritten. So even in your edge case — a big rewrite while you're mid-sentence in that region — the agent yields, not you.
On finer granularity, we are still exploring the right approach. The applied edit is minimal-diffed, so it's small when the real change is small — but the unit of conflict is still the section, not a sub-range. Block-level scoping is likely the right next step for finer control — curious how you'd approach it. Would love your take~
The local-first angle is exactly what pulled me in, and the co-editing through MCP feels genuinely useful. One thing that would make this a daily driver for me: a quick toggle to preview the markdown in a side pane with synced scrolling, so I can spot broken links or formatting drift while my agent is still writing.
OpenMarkdown
@berkantozg31053 So glad the local-first + MCP co-edit clicked for you 😊
This might already cover it: OpenMarkdown doesn't do a split source / preview pane — it renders live, inline, in the same pane as you (or your agent) type. So formatting drift shows up the moment it's written, with no second pane to keep scroll-synced. One button also cycles to reading mode (the clean rendered page) and source mode.
Personally, live preview has been the best experience for me — each line renders in place as I type. And when I do need the raw markup, source mode renders it with syntax colors (easier on my eyes) instead of a second pane. I kept it single to stay light.
Genuinely curious what a dual pane would give you over live preview — if it's a real gap, I'd love to understand the workflow before deciding.
(I attached two screenshot of the app under "live preview" and "source" mode for reference~
OpenMarkdown
@berkantozg31053
Congrats on the launch! I like the idea of keeping the editor lightweight while letting users bring whichever agent already understands their project.
The shared-file approach feels much more natural than copying content between an editor and a separate AI pane. I’m curious how you prevent collisions when the user and agent edit the same section at once.
Looking forward to trying it.
OpenMarkdown
@mingtian_zhang Thank you, that means a lot 😊
On the same-section case: agent writes are section-scoped and carry a hash of what the agent read. Before applying, `openmd` check you haven't changed that section under it — if you have, the write is rejected (not merged, not overwritten) and the agent re-reads and retries, so your edits are never clobbered. Different sections just interleave cleanly.
There's a step-by-step interactive agent demo on the landing page, and you can install by pasting a prompt into your agent: https://openmarkdown.dev Would love to hear how it feels~
Interesting call to make it "co-edit" instead of AI-suggest. How do you handle simultaneous
edits when both you and the agent are typing in the same block — CRDT-style merge or last-write-wins?
OpenMarkdown
@chetan00118 Great question!
OpenMarkdown's MCP supports section-level writing. There are two situations then.
1. When the agent writes to a different section than the one you're in, its edit lands as a scoped transaction in your live buffer. No reload, no lock.
2. When you're both in the same section, it's optimistic concurrency: every agent write carries a hash of what it read, and if you've touched that section since, the write is rejected (not merged, not overwritten) — your edits are untouched and the agent re-reads and retries. So on a real collision the agent yields 😊
A compare-and-swap per section is lighter, and it keeps the plain .md as the source of truth.
We are still looking for the best way to handle the concurrency for the best user experience and best performance. Let me know if you have any suggestions or other questions~
(ps: a new section for step-by-step interactive agent demo on the landing page should be sync'ed within the next 30 mins; please feel free to give it a try~)
@xueyanzhang Optimistic concurrency with per-section hash-CAS is a nice compromise — keeps .md as source of truth while letting agents yield gracefully on real collisions. That's more elegant than CRDT overhead for a doc format. I'll try the interactive demo when it's live. Thanks for the deep dive 🙏
OpenMarkdown
@chetan00118 Exactly — "yield gracefully on real collisions" is the phrasing I'm stealing 😄
Good news, no waiting — it's live now.
Thanks for the sharp questions! It means a lot.