Kuku: open source - Your open-source, local second brain for every AI

by
Kuku is back as an open-source, local-first second brain for the AI era. It keeps your knowledge in plain Markdown files, then turns your vault into reusable context: wikilinks, backlinks, graph, search, and AI-assisted edits with reviewable diffs. Unlike closed note apps or one-off AI chats, Kuku is built to make your memory portable across tools, models, and self-hosted setups.

Add a comment

Replies

Best
Hey Product Hunt 👋 I’m Minkyu Lee, design engineer on Kuku. Our first launch started as an Obsidian-like Markdown editor. Thanks to this community, we got a ton of attention, feedback, and energy from it. Since then, we’ve been rebuilding Kuku almost from the ground up, many late nights included. Kuku is now open source and moving toward something bigger: a local-first second brain that can become shared memory for your AI tools. Think plain Markdown, wikilinks, graph, search, Cursor-style AI edits, and a Mem0-like memory layer — but open, hackable, and yours. We’re still early, still shipping hard, and looking for people who want to help shape it: users, contributors, plugin builders, and anyone obsessed with AI context. Would love your feedback, questions, and weirdest use cases.
Mohsin Ali ✪

@bigmacfive how does the memory handling compare to obsidian's smart connections plugin or official copilot?

DAYAL PUNJABI

@bigmacfive How does it ensure your personal notes stay truly private and local when feeding context to external AI, without any cloud leakage?

It’s Friday, so we’re going for it. @Y Combinator

Kuku is open source, but we’re building it like a real company: a local-first second brain and memory layer for the AI era.

Othman Katim

How do you handle sync between devices if it’s local first, like is there a recommended setup with Git?

GyeongTaek Kim

@othman_katim 
Great question. We already have an E2EE sync layer in place, but I’d still consider it alpha, so I don’t want to oversell it yet.

If you’re comfortable with Git, setting up a Git repo per vault is a really good approach. Since your notes are local Markdown files, you can sync them across devices, keep history, and handle changes in a way that feels familiar to developers.

One small recommendation: add the .kuku folder to your .gitignore, since it may contain local indexing/cache data that doesn’t need to be synced.

GyeongTaek Kim

Hi everyone, I’m one of the developers behind Kuku, mainly working on the core logic and implementation.

We’ve rebuilt a lot of the product from the ground up for this launch, while thinking deeply about how local-first Markdown knowledge management can connect with an AI memory layer.


Kuku is still early, and there’s a lot we want to improve.

Please feel free to share anything. I’d be happy to answer as openly as I can.


We’ll also be shipping frequent updates from here, so please keep an eye on what’s coming next.

Igor Martynyuk

Finally someone said "fuck Electron" for a markdown editor. Tauri + local-first + AI that actually writes to files instead of just yapping. Pure signal. Congrats on the launch! ⚡️

@igor_martinyuk 
Haha exactly. The whole bet was: what if a markdown editor didn’t feel like a browser wearing a trench coat?

Tauri + plain files + local-first felt obvious to us. And AI should not just yap in a sidebar forever — it should understand the vault, propose real file changes, and let you review the diff before anything lands.

Appreciate you Igor ⚡️

Saad El Gueddari

congrats on the relaunch. the tauri + local-first call is the right one, electron-based note apps always feel like they're fighting the OS. the cursor-style diffs for AI edits is the part that sells it for me, "AI suggests, u review" is way better than the yolo-edit pattern most tools ship with.

curious where ur memory layer goes from here, is the plan to expose it as a context source other AI tools can read from, or keep it inside kuku?

@saad_el_gueddari 
Thank you, really appreciate it.

And yes, that’s exactly the direction. We don’t want the memory layer to stay trapped inside Kuku. The goal is for Kuku to become an open, local-first context source that other AI tools can read from, while the user stays in control of what gets exposed.

Kuku starts as the place where your Markdown vault, wikilinks, graph, search, and AI edits live. But longer term, we want it to work more like a portable memory layer: local API, MCP-style bridges, self-hostable sync, and permissioned access for different agents/tools.

So the principle is: your memory lives with you, Kuku organizes it, and AI tools can use it only when you allow them to.

GyeongTaek Kim

@saad_el_gueddari 
From the implementation side, I also think the memory layer loses a lot of value if it stays locked inside Kuku. We wanted the memory format to be easy for humans to read, easy for AI to understand, and simple enough to edit from other tools.

That’s one of the main reasons we chose Markdown as the base format. Even for memory, we want to keep it as close as possible to Markdown or plain text, rather than hiding it behind a closed internal format.

The core idea is that your knowledge and context should not be trapped in a single app. Kuku should organize and connect it, but the user should ultimately own and control it as an AI context layer.

i said wish i had llm on obsidian 2 days ago and now... you guys cooked.

GyeongTaek Kim

@fatalerrorist 
Perfect timing 😄. That’s exactly the kind of problem we started from. If you try it out, we’d love to hear what LLM workflows you’d want next.

Curious Kitty
The Cursor-style edit preview is a strong trust signal—what kinds of edits does it handle well today (refactors, link hygiene, summaries), and where does it still struggle compared to manual editing?

@curiouskitty It works best today for structure-heavy edits: summaries, heading cleanup, wikilinks, splitting messy notes, and turning raw notes into reusable context.

It still struggles with personal nuance and deciding what should be remembered.

That’s why we use reviewable diffs — AI suggests, you stay in control.

GyeongTaek Kim

@curiouskitty I also think the reviewable part is really important here.
AI is already quite good at general cleanup and writing tasks, but adapting to each person’s own writing habits, structure, and tone still needs a lot of improvement.
That’s why we’re focusing on a flow where AI suggests first, and the user reviews before applying. We’re actively improving this, so any feedback from real usage would be greatly appreciated.

IMAD EL KHAFI

Local-first is the right call for a second brain cloud sync always feels like a liability for personal notes. Does it handle multiple AI models or is it locked to one?

GyeongTaek Kim

@imad_elkhafi 
Totally agree. For personal notes and a second brain, local-first feels like the right default.

On the AI side, we’re trying to avoid being tightly locked to a single model. The idea is to keep your Markdown vault and memory/context layer local, then let different models or tools connect on top of it when needed.

We’re still early and expanding the supported flow, but the principle is: your notes and memory should belong to you, and the AI model should be replaceable.

IMAD EL KHAFI

@mansuiki "The AI model should be replaceable" that's the right philosophy. Your data outlives any single model. Good foundation to build on.

Samir Asadov

Local-first + plain markdown is the only second-brain shape that survives long-term — closed note apps eventually break trust on either lock-in or pricing, and the migration cost on a 5-year vault is brutal. The portable-memory framing is what most AI-note tools miss; they treat notes as in-app data instead of files you own. I run a podcast (https://open.spotify.com/show/0m1oR8AyQv17DVpc5MmirG) on financial modelling and the listener-feedback I get most is exactly this: "where do I keep the takeaways?" — audio doesn't fold into a closed notes app cleanly, but plain markdown with backlinks does. Curious how Kuku handles AI-edits on existing files: do diffs apply per-paragraph or per-file, and is there a way to reject just one chunk of a multi-edit suggestion?

GyeongTaek Kim

@samir_asadov 
Thanks for the thoughtful question.

Right now, Kuku shows AI edits in a file-diff style, but you can still preview the actual changes in detail — whether that’s a line, a phrase, or a paragraph. The important part for us is that users can clearly review what will change in the real file before applying it.

At the moment, the flow is closer to approving the full suggestion. If something feels off, the user can ask the AI to revise it again.

That said, the idea of accepting or rejecting specific chunks inside a multi-edit suggestion is a really good one. More precise control is definitely important for AI editing, so we’ll take that as a strong improvement direction.

Samir Asadov

@mansuiki  Right — "approve full suggestion, ask AI to revise if off" is the safer default, but the chunk-level accept/reject is where most of the high-trust workflows will eventually land. The parallel I see in financial modeling: when you sensitize a model and the AI proposes a sweep of cell rewrites, you want to keep 4 of the 7 changes, not all-or-nothing. Same trust loop. We've been talking about exactly this kind of granular review on the ModeLoop podcast — the bridge between AI-suggested edits and human-confirmed deltas is going to be where the next round of tooling differentiates.

12
Next
Last