In April, Andrej Karpathy posted a short "idea file" called LLM Wiki. The pitch: stop making your model re-read raw documents on every question. Let it build and maintain a wiki from your sources instead, a persistent Markdown knowledge base that gets better every time you add something.
The internet went wild. Within a week there were thousands of repos implementing it, and two of them crossed 20,000 GitHub stars.
There was one thing missing for me: none of them felt at home on a Linux desktop. So we built gknowledge: Karpathy's LLM Wiki as a native GNOME app.
openapi
/
gknowledge
🐧 A native GNOME knowledge workstation that turns documents into evolving AI-assisted knowledge bases.
gknowledge
Karpathy's LLM Wiki as a native GNOME app.
Drop in your documents. Get a linked wiki that an LLM keeps up to date.
A native GNOME app. Offline by default, plain Markdown on disk, Obsidian-compatible.
Bring your own brain: a local model, any OpenAI-compatible endpoint, or your own ChatGPT plan
Real output of the offline engine on six AI papers (data/demo/papers), no API key
Regenerate with make demo-svg.
Install
One line, on Ubuntu 24.04+ and Debian 13+ (falls back to a per-user install on other distributions):
curl -fsSL https://github.com/openapi/gknowledge/releases/latest/download/install.sh | bash
Or download the package and install it with apt, which also pulls GTK 4, Libadwaita and PyGObject:
wget https://github.com/openapi/gknowledge/releases/latest/download/gknowledge_all.deb
sudo apt install ./gknowledge_all.deb
Then open gknowledge from the app grid. To remove it: sudo apt remove gknowledge.
Other distributions, from source, and release builds
- Fedora, Arch and others: install…
What it does, in 30 seconds
- Drop in your documents. Markdown, text, PDF, HTML. Papers, notes, specs, whatever you are trying to understand.
-
gknowledge builds a linked wiki. Every source gets a summary page; the people, systems and ideas it talks about get their own pages; everything is cross-linked with
[[wikilinks]]and every page records where it came from. - Ask questions. Answers come from the wiki, with numbered citations you can click to open the page they came from.
The whole knowledge base is a plain folder of Markdown files with YAML frontmatter. Open it in Obsidian, grep it, put it in git. No lock-in, no sync service.
Why another LLM wiki?
Because the existing ones are great, but they are web apps in a desktop costume. gknowledge makes different trade-offs:
- 🐧 Native GTK 4 + Libadwaita. No Electron, no Tauri, no embedded browser. It follows the GNOME HIG, uses a Nautilus-style sidebar, and respects your light/dark theme and accent colour.
- 🔌 Works with no model at all. A built-in offline engine ingests documents and answers with extracts. Plug in a model when you want real synthesis.
- 🔑 Bring your own brain, without an API key. gknowledge supports OpenAI's new Sign in with ChatGPT for local, open-source apps: you log in with your own Plus or Pro plan, and usage is charged to your plan. Nobody resells tokens. Ollama, LM Studio and any OpenAI-compatible endpoint work too.
- 🧹 No wiki spam. LLM wikis love to generate hundreds of one-line stub pages. gknowledge only creates a page when there is real content, merges duplicates ("Retrieval-Augmented Generation (RAG)" and "retrieval augmented generation" are the same page; "Kasparov" links to "Garry Kasparov"), and keeps minor names as mentions until a second source cites them. On our sample of six AI papers that took the wiki from 114 pages to 64, all of them with an actual description.
- 🤖 Agents welcome. gknowledge ships an MCP server, so Claude Code, Codex or Cursor can search, read, ask and add sources to the same wiki you browse in the app:
claude mcp add gknowledge -- gknowledge-mcp ~/Knowledge/my-project
How it compares
All of these are excellent open-source projects and worth your time. Here is where gknowledge sits (GitHub numbers as of October 2026):
| gknowledge | LLM Wiki (nashsu) | Tolaria | OpenKnowledge | Reor | Khoj | |
|---|---|---|---|---|---|---|
| UI | native GTK 4 | Tauri | Tauri | Electron | Electron | web, Electron |
| Works with no model | yes | no | AI optional | agent-driven | local model | self-host |
| Markdown vault | yes | yes | yes | yes | yes | reads your files |
| MCP server | yes | yes | yes | yes | no | not checked |
| License | MIT | GPL-3.0 | AGPL-3.0 | GPL-3.0 | AGPL-3.0 | AGPL-3.0 |
| Status | new | ~20.5k ⭐ | ~20k ⭐ | ~4.5k ⭐ | archived | ~37.7k ⭐ |
If you love LLM Wiki's knowledge graph or Tolaria's git-first editor, keep using them. If you live on GNOME or Ubuntu and want something that feels like Files or Text Editor, that is exactly the gap gknowledge is trying to fill.
Try it
On Ubuntu 24.04+ or Debian 13+:
curl -fsSL https://github.com/openapi/gknowledge/releases/latest/download/install.sh | bash
Or grab the .deb from the latest release. On other distros the installer puts it in ~/.local.
Want to hack on it? git clone, then make start: it opens a demo project with six classic AI papers already ingested and restarts the app every time you save a file.
What's next
- Lint: find contradictions, orphans and stale pages, like Karpathy describes.
- A knowledge graph view.
- Faster parallel ingestion and streaming answers.
- Flatpak, a PPA and a Snap.
It is early (v0.2), MIT licensed and moving fast. Full disclosure: I'm one of the people building it, so I'd genuinely love to hear what would make you switch, and what feels wrong. Issues and PRs are very welcome.
If this is the kind of tool you want to exist on the Linux desktop, a ⭐ on GitHub really helps other GNOME users find it.
Top comments (6)
Nice to see more native GTK 4 + libadwaita apps instead of another Electron wrapper. I’m building a GNOME photo app myself, so a couple of thoughts from a little further down the same road.
I’d pull Flatpak forward on the roadmap. I’m on Fedora, so the .deb and the install script don’t really work for me, and Flathub is how most GNOME users outside Ubuntu will find you. The bigger reason is what happens if you develop against your host’s GTK and package later: the GNOME runtime you end up targeting can ship a different GTK from your host, and APIs you’ve come to rely on aren’t there or behave differently. Building inside the GNOME SDK from the start means you develop against what your users will actually run. I wrote up the setup I use here. It’s Rust, but the Flatpak side carries over to Python.
On the stale-pages lint: I ran agents over legacy ETL code and built a checker expecting it to catch hallucinations. What it actually caught was documentation that had been correct and drifted out of date as the source changed. Since your pages already record where they came from, checking them against the current sources (if the lint doesn’t already) could make it really useful.
Starred, and I’ll give it a proper go once there’s a Flatpak.
Thanks again, Justin — your comment shaped the last release.
Flatpak is out (v0.3.0, GNOME 51 runtime, PDF support included):
flatpak install --user --from openapi.github.io/gknowledge/io.gi...
Source drift is now tracked, straight from your point: gknowledge notices when an original file changed after ingestion. It flags the source, can update and re-ingest it, and exposes a stale_sources tool over MCP
(github.com/openapi/gknowledge/pull/42).
We took your runtime advice too: make start-flatpak runs the dev loop inside the GNOME runtime, so UI work is tested against the GTK/libadwaita that Flatpak users actually get. It already caught a real bug (SQLite WAL vs. the
document portal) before release.
We've only tested on Ubuntu so far. If you give it a spin on Fedora, I'd love to hear what breaks, and reviews or issues are very welcome. Also: would you mind if we linked your GNOME SDK write-up from our contributor docs?
That was fast, and a stale_sources tool over MCP is a really nice touch. Good catch on the WAL and document portal bug.
Of course, link away. Part 1 is the one: fromthearchitect.dev/posts/gnome-r...
I'm on Fedora 44, so I'll install the Flatpak this week and open issues for anything that breaks.
Thanks Justin! Linked: CONTRIBUTING now points to your Part 1 right after the make start-flatpak section, for anyone setting up the GNOME SDK for the first time: github.com/openapi/gknowledge/blob...
Great to have a Fedora 44 test. That's the one combination I haven't been able to check myself. No issue is too small, and I'll get to yours first.
Looking forward to Part 2 of your series!
Gave it a spin on Fedora 44 and it works fine. No issue from me yet. Thanks for linking Part 1 in CONTRIBUTING. Part 2 is already out if anyone wants to keep going.
Thanks Justin, a clean run on Fedora 44 is exactly the report I was hoping for! I just saw the series is already at Part 6, so I'll point CONTRIBUTING to the series page instead of Part 1 alone.
One idea: would you be OK if I used Building GNOME Apps with Rust as a demo knowledge base for gknowledge? Feed the posts in as sources, compile the wiki, and show agents asking cited questions like "how does the bind/unbind
rhythm work in GtkListView?". It would link back to every post. Happy to share the result with you before publishing anything.