davideisinger.com

gist-github-com-4bt2rw.txt (74023B)

---

 [1]Skip to content 
 [2]
 [3](Toggle navigation)
 Search Gists
 [4][                    ]
 [5] Search Gists
 [6]All gists [7]Back to GitHub [8] Sign in [9] Sign up
 [10]
 [11] Sign in [12] Sign up
 You signed in with another tab or window. [13]Reload to refresh your session. 
 You signed out in another tab or window. [14]Reload to refresh your session. 
 You switched accounts on another tab or window. [15]Reload to refresh your
 session. [16] Dismiss alert
 [17](Dismiss this message)
 {{ message }}
 
 Instantly share code, notes, and snippets.
 
 [18]@karpathy
 
 [19]karpathy/[20]llm-wiki.md
 
 Created April 4, 2026 16:25
 
 [21] Show Gist options
 
   • [22] Download ZIP
 
   • [23] Star 5,000+ (5,000+) You must be signed in to star a gist
   • [24] Fork 5,000+ (5,000+) You must be signed in to fork a gist
 
   • [25] Embed
 
     Select an option
 
     [26](Close)
       □ [27] Embed Embed this gist in your website.
       □ [28] Share Copy sharable link for this gist.
       □ [29] Clone via HTTPS Clone using the web URL.
 
     No results found
 
     [30]Learn more about clone URLs
     Clone this repository at <script src="https://gist.github.com/
     karpathy/442a6bf555914893e9891c11519de94f.js"></script>
     [31][<script src="https:/]
   • [32] Save karpathy/442a6bf555914893e9891c11519de94f to your computer and
     use it in GitHub Desktop.
 
 [33] Code [34] Revisions 1 [35] Stars 5,000+ [36] Forks 5,000+
 [37] Embed
 
 Select an option
 
 [38](Close)
 
   • [39] Embed Embed this gist in your website.
   • [40] Share Copy sharable link for this gist.
   • [41] Clone via HTTPS Clone using the web URL.
 
 No results found
 
 [42]Learn more about clone URLs
 Clone this repository at &lt;script src=&quot;https://gist.github.com/karpathy/
 442a6bf555914893e9891c11519de94f.js&quot;&gt;&lt;/script&gt;
 [43][<script src="https:/]
 [44] Save karpathy/442a6bf555914893e9891c11519de94f to your computer and use it
 in GitHub Desktop.
 [45]Download ZIP
 llm-wiki
 [46] Raw
 [47] llm-wiki.md
 
 LLM Wiki
 
 [48] 
 
 A pattern for building personal knowledge bases using LLMs.
 
 This is an idea file, it is designed to be copy pasted to your own LLM Agent
 (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to
 communicate the high level idea, but your agent will build out the specifics in
 collaboration with you.
 
 The core idea
 
 [49] 
 
 Most people's experience with LLMs and documents looks like RAG: you upload a
 collection of files, the LLM retrieves relevant chunks at query time, and
 generates an answer. This works, but the LLM is rediscovering knowledge from
 scratch on every question. There's no accumulation. Ask a subtle question that
 requires synthesizing five documents, and the LLM has to find and piece
 together the relevant fragments every time. Nothing is built up. NotebookLM,
 ChatGPT file uploads, and most RAG systems work this way.
 
 The idea here is different. Instead of just retrieving from raw documents at
 query time, the LLM incrementally builds and maintains a persistent wiki — a
 structured, interlinked collection of markdown files that sits between you and
 the raw sources. When you add a new source, the LLM doesn't just index it for
 later retrieval. It reads it, extracts the key information, and integrates it
 into the existing wiki — updating entity pages, revising topic summaries,
 noting where new data contradicts old claims, strengthening or challenging the
 evolving synthesis. The knowledge is compiled once and then kept current, not
 re-derived on every query.
 
 This is the key difference: the wiki is a persistent, compounding artifact. The
 cross-references are already there. The contradictions have already been
 flagged. The synthesis already reflects everything you've read. The wiki keeps
 getting richer with every source you add and every question you ask.
 
 You never (or rarely) write the wiki yourself — the LLM writes and maintains
 all of it. You're in charge of sourcing, exploration, and asking the right
 questions. The LLM does all the grunt work — the summarizing,
 cross-referencing, filing, and bookkeeping that makes a knowledge base actually
 useful over time. In practice, I have the LLM agent open on one side and
 Obsidian open on the other. The LLM makes edits based on our conversation, and
 I browse the results in real time — following links, checking the graph view,
 reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the
 wiki is the codebase.
 
 This can apply to a lot of different contexts. A few examples:
 
   • Personal: tracking your own goals, health, psychology, self-improvement —
     filing journal entries, articles, podcast notes, and building up a
     structured picture of yourself over time.
   • Research: going deep on a topic over weeks or months — reading papers,
     articles, reports, and incrementally building a comprehensive wiki with an
     evolving thesis.
   • Reading a book: filing each chapter as you go, building out pages for
     characters, themes, plot threads, and how they connect. By the end you have
     a rich companion wiki. Think of fan wikis like [50]Tolkien Gateway —
     thousands of interlinked pages covering characters, places, events,
     languages, built by a community of volunteers over years. You could build
     something like that personally as you read, with the LLM doing all the
     cross-referencing and maintenance.
   • Business/team: an internal wiki maintained by LLMs, fed by Slack threads,
     meeting transcripts, project documents, customer calls. Possibly with
     humans in the loop reviewing updates. The wiki stays current because the
     LLM does the maintenance that no one on the team wants to do.
   • Competitive analysis, due diligence, trip planning, course notes, hobby
     deep-dives — anything where you're accumulating knowledge over time and
     want it organized rather than scattered.
 
 Architecture
 
 [51] 
 
 There are three layers:
 
 Raw sources — your curated collection of source documents. Articles, papers,
 images, data files. These are immutable — the LLM reads from them but never
 modifies them. This is your source of truth.
 
 The wiki — a directory of LLM-generated markdown files. Summaries, entity
 pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this
 layer entirely. It creates pages, updates them when new sources arrive,
 maintains cross-references, and keeps everything consistent. You read it; the
 LLM writes it.
 
 The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex)
 that tells the LLM how the wiki is structured, what the conventions are, and
 what workflows to follow when ingesting sources, answering questions, or
 maintaining the wiki. This is the key configuration file — it's what makes the
 LLM a disciplined wiki maintainer rather than a generic chatbot. You and the
 LLM co-evolve this over time as you figure out what works for your domain.
 
 Operations
 
 [52] 
 
 Ingest. You drop a new source into the raw collection and tell the LLM to
 process it. An example flow: the LLM reads the source, discusses key takeaways
 with you, writes a summary page in the wiki, updates the index, updates
 relevant entity and concept pages across the wiki, and appends an entry to the
 log. A single source might touch 10-15 wiki pages. Personally I prefer to
 ingest sources one at a time and stay involved — I read the summaries, check
 the updates, and guide the LLM on what to emphasize. But you could also
 batch-ingest many sources at once with less supervision. It's up to you to
 develop the workflow that fits your style and document it in the schema for
 future sessions.
 
 Query. You ask questions against the wiki. The LLM searches for relevant pages,
 reads them, and synthesizes an answer with citations. Answers can take
 different forms depending on the question — a markdown page, a comparison
 table, a slide deck (Marp), a chart (matplotlib), a canvas. The important
 insight: good answers can be filed back into the wiki as new pages. A
 comparison you asked for, an analysis, a connection you discovered — these are
 valuable and shouldn't disappear into chat history. This way your explorations
 compound in the knowledge base just like ingested sources do.
 
 Lint. Periodically, ask the LLM to health-check the wiki. Look for:
 contradictions between pages, stale claims that newer sources have superseded,
 orphan pages with no inbound links, important concepts mentioned but lacking
 their own page, missing cross-references, data gaps that could be filled with a
 web search. The LLM is good at suggesting new questions to investigate and new
 sources to look for. This keeps the wiki healthy as it grows.
 
 Indexing and logging
 
 [53] 
 
 Two special files help the LLM (and you) navigate the wiki as it grows. They
 serve different purposes:
 
 index.md is content-oriented. It's a catalog of everything in the wiki — each
 page listed with a link, a one-line summary, and optionally metadata like date
 or source count. Organized by category (entities, concepts, sources, etc.). The
 LLM updates it on every ingest. When answering a query, the LLM reads the index
 first to find relevant pages, then drills into them. This works surprisingly
 well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need
 for embedding-based RAG infrastructure.
 
 log.md is chronological. It's an append-only record of what happened and when —
 ingests, queries, lint passes. A useful tip: if each entry starts with a
 consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log
 becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives
 you the last 5 entries. The log gives you a timeline of the wiki's evolution
 and helps the LLM understand what's been done recently.
 
 Optional: CLI tools
 
 [54] 
 
 At some point you may want to build small tools that help the LLM operate on
 the wiki more efficiently. A search engine over the wiki pages is the most
 obvious one — at small scale the index file is enough, but as the wiki grows
 you want proper search. [55]qmd is a good option: it's a local search engine
 for markdown files with hybrid BM25/vector search and LLM re-ranking, all
 on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server
 (so the LLM can use it as a native tool). You could also build something
 simpler yourself — the LLM can help you vibe-code a naive search script as the
 need arises.
 
 Tips and tricks
 
 [56] 
 
   • Obsidian Web Clipper is a browser extension that converts web articles to
     markdown. Very useful for quickly getting sources into your raw collection.
   • Download images locally. In Obsidian Settings → Files and links, set
     "Attachment folder path" to a fixed directory (e.g. raw/assets/). Then in
     Settings → Hotkeys, search for "Download" to find "Download attachments for
     current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping
     an article, hit the hotkey and all images get downloaded to local disk.
     This is optional but useful — it lets the LLM view and reference images
     directly instead of relying on URLs that may break. Note that LLMs can't
     natively read markdown with inline images in one pass — the workaround is
     to have the LLM read the text first, then view some or all of the
     referenced images separately to gain additional context. It's a bit clunky
     but works well enough.
   • Obsidian's graph view is the best way to see the shape of your wiki —
     what's connected to what, which pages are hubs, which are orphans.
   • Marp is a markdown-based slide deck format. Obsidian has a plugin for it.
     Useful for generating presentations directly from wiki content.
   • Dataview is an Obsidian plugin that runs queries over page frontmatter. If
     your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts),
     Dataview can generate dynamic tables and lists.
   • The wiki is just a git repo of markdown files. You get version history,
     branching, and collaboration for free.
 
 Why this works
 
 [57] 
 
 The tedious part of maintaining a knowledge base is not the reading or the
 thinking — it's the bookkeeping. Updating cross-references, keeping summaries
 current, noting when new data contradicts old claims, maintaining consistency
 across dozens of pages. Humans abandon wikis because the maintenance burden
 grows faster than the value. LLMs don't get bored, don't forget to update a
 cross-reference, and can touch 15 files in one pass. The wiki stays maintained
 because the cost of maintenance is near zero.
 
 The human's job is to curate sources, direct the analysis, ask good questions,
 and think about what it all means. The LLM's job is everything else.
 
 The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal,
 curated knowledge store with associative trails between documents. Bush's
 vision was closer to this than to what the web became: private, actively
 curated, with the connections between documents as valuable as the documents
 themselves. The part he couldn't solve was who does the maintenance. The LLM
 handles that.
 
 Note
 
 [58] 
 
 This document is intentionally abstract. It describes the idea, not a specific
 implementation. The exact directory structure, the schema conventions, the page
 formats, the tooling — all of that will depend on your domain, your
 preferences, and your LLM of choice. Everything mentioned above is optional and
 modular — pick what's useful, ignore what isn't. For example: your sources
 might be text-only, so you don't need image handling at all. Your wiki might be
 small enough that the index file is all you need, no search engine required.
 You might not care about slide decks and just want markdown pages. You might
 want a completely different set of output formats. The right way to use this is
 to share it with your LLM agent and work together to instantiate a version that
 fits your needs. The document's only job is to communicate the pattern. Your
 LLM can figure out the rest.
 
 [62]Load earlier comments...
 [63]@frankchu91
 
 [64]frankchu91 commented [65]Jul 18, 2026 •
 edited
 Loading
 
 Uh oh!
 
 There was an error while loading. [66]Please reload this page.
 
 Copy link
 Copy Markdown
 
 MindBase — an open-source implementation of this post (MCP server, MIT)
 
 Built this over the past few months: [67]https://github.com/frankchu91/mindbase
 
 [68]MindBase web UI — the LLM-maintained context.md of a research project
 
 Mapping to the three layers as specced:
 
   • Raw sources → sources/ is append-only, enforced by tooling rather
     than convention: each operation runs as a sub-agent with a strict tool
     allowlist — the builder agent has no file-write tool at all, only an
     atomic-write MCP call that snapshots context.md before replacing it.
   • The wiki → LLM-maintained markdown with [[wikilinks]], plus a typed
     link index (sqlite, derived state — markdown stays the source of truth):
     edges carry contradicts/supersedes/mentions, so lint can proactively
     surface "this new source contradicts what you wrote in March."
   • The schema → a per-project README.md the LLM re-reads at every
     operation; user-editable, co-evolves with the wiki.
 
 All three operations are in — a day looks like:
 
 /mb:contribute paper.pdf → sub-agent reads, discusses 3 takeaways, waits
 for approval, then updates 5-15 wiki pages
 /mb:ask "my stance on X?" → cited answer from the already-synthesized wiki
 /mb:lint → contradictions · orphans · stale claims · gaps
 
 Works in any MCP client (Claude Code / Cursor / Windsurf / Cline):
 npx -y mindbase-mcp. All local markdown — you can open the data dir
 straight in Obsidian.
 
 One finding for the drift discussion in this thread: the biggest drift
 reducer for us wasn't better prompts — it was making the layer contract
 physically unviolable via tool boundaries. A sloppy LLM turn can't
 corrupt the sources layer even in principle, so drift stays confined to
 the wiki layer, where lint can catch it.
 
 Happy to compare notes with the other implementations here.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [71]Please reload this page.
 
 [72]@sturlese
 
 [73]sturlese commented [74]Jul 19, 2026
 
 Copy link
 Copy Markdown
 
 I looked at a lot of personal second brains before building this one, and
 bounced off most of them for the same two reasons: I could never tell what the
 system was actually doing, and getting started meant installing a stack. I
 wanted something simple enough that I always know exactly what happens when,
 and that asks you to install as little as possible.
 
 That constraint produced the design:
 [75]https://github.com/sturlese/hippocampus
 
 No vector database, no embeddings, no MCP server, no Obsidian plugins, no
 dependencies. Markdown, one stdlib Python linter, one shell hook, git.
 
 Retrieval is three reads instead of a similarity search: a 500-word
 working-memory cache injected at session start, then the master index (one line
 per page), then the three to five pages it points to. Grep as fallback.
 
 Every step is a file you can open and read.
 
 That's the part I care about most. A missed lookup is a bad line in index.md —
 visible, editable. With embeddings you get a number, and the cause could be a
 chunk boundary, a stale index or an unlucky neighbour, none of which you can
 see.
 
 It stops working somewhere in the low thousands of pages, when the index no
 longer fits in context.
 
 I wrote up the whole pipeline step by step, in case the approach is useful even
 without the tool:
 [76]https://github.com/sturlese/hippocampus/blob/main/docs/
 what-happens-when-you-ingest.md
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [79]Please reload this page.
 
 [80]@lucianfialho
 
 [81]lucianfialho commented [82]Jul 19, 2026
 
 Copy link
 Copy Markdown
 
 Built a variant of this pattern backed by Neo4j instead of markdown — same
 three layers (immutable Source nodes / a Concept+Claim graph / a
 schema-as-constraints), but cross-references become real typed edges you can
 run graph algorithms on.
 
 Benchmarked the two things that actually matter instead of just shipping a
 demo:
 
 Entity resolution: 45 labeled mention pairs (same-entity / related-but-distinct
 / unrelated), real embeddings. A single cosine threshold doesn't work —
 related-but-distinct pairs often score higher than true synonyms (best F1 =
 0.667). A two-stage pipeline instead — cheap embedding filter for candidates,
 then one real LLM judgment call per candidate ("same entity or just related?")
 — got F1 to 1.000 on the same pairs.
 
 Graph vs flat RAG on multi-hop questions: small real-facts corpus, 6 questions
 each needing 2-3 connected documents. Flat RAG (top-k) covered 4/6; graph
 traversal (N hops over typed edges) covered 6/6. Caveat: on this small dense
 corpus the traversal's recall win came with a precision cost (pulled 5-6 of 8
 docs on 3 of 6 questions) — not tested at scale.
 
 Full pattern, corpus, labeled pairs, and the chart: [83]https://gist.github.com
 /lucianfialho/44034e0d02a2bfccca2ad6358bde1dff
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [86]Please reload this page.
 
 [87]@bprice1000
 
 [88]bprice1000 commented [89]Jul 19, 2026
 
 Copy link
 Copy Markdown
 
 I’ve been applying lmm_wiki as a heavy influence in creating a CMMS; Manage
 assets, resources, build metrics, feed them with real time signals or data
 gathered from procedures, build fully fleshed unscheduled/preventable
 maintenance/upkeep plans, and create issues against any of the entities; All
 while being fully greppable, levering markdown in multiple ways, requiring no
 database or license. Llm_wiki is a great influence for a cmms as the systems
 themselves are relatively low event.
 
 Flattest. 1st principles. The assets don’t have logs, they are logs with
 fields, the resources are counts, etc.
 
 I just wanted to share the index file I am using inside of my project. Perhaps
 it shows how the schema aspect of the concept can be heavily expanded and most
 concepts on display held through testing during an earlier second iteration.
 Third iteration maybe in testing next month.
 
 [90]https://gist.github.com/bprice1000/f986547dda0a82c5178faa6e237247fe
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [93]Please reload this page.
 
 [94]@umezy
 
 [95]umezy commented [96]Jul 20, 2026 •
 edited
 Loading
 
 Uh oh!
 
 There was an error while loading. [97]Please reload this page.
 
 Copy link
 Copy Markdown
 
 [98]@geetansharora asked on day one how to share one of these with a team — the
 answers so far have been "serve the vault over MCP." We've been running a
 different, git-native answer for a few months, so here are some notes from
 actually operating it.
 
 Context: we build on a niche SDK that models happily hallucinate APIs for, so
 the wiki layer (synced official docs + our own verified tips) is not optional
 for us. It's a lighter take on the pattern than the gist describes — the LLM
 acts more as searcher than librarian, and the compiled layer is human-verified
 tips and SKILL.md procedures rather than an LLM-maintained wiki. The part that
 turned out to be interesting is distribution: that compiled layer replicates to
 every teammate's agent on git pull.
 
 The repo itself is the deployment. No MCP server, no RAG index, no sync
 service. One git repo with two layers: sources/ (the wiki: synced official
 docs, API references, tips) and skills/ (the agency side: SKILL.md packages,
 including the search skills that query sources/). A one-time setup command
 links each skill into ~/.claude/skills (symlinks; junctions on Windows), and a
 post-merge hook re-runs the sync — so daily operation for everyone on the team
 is literally git pull.
 
 Notes from living with it:
 
   • Working copy = live instance changes behavior. The linked skills point into
     each member's checkout, so editing a skill + git push is the entire publish
     flow. The unexpected outcome: our designers — not engineers — started
     pushing skills. The contribution barrier is "edit a markdown file," and
     that turned out to be low enough for non-engineers.
   • Retrieval stayed a skill in the repo, not a service. The template ships a
     ranked-grep search skill (generate keyword variants → grep sources/ → rank
     the hits). In our team repo we also run a hybrid semantic skill — embedded
     Chroma + a local multilingual MiniLM, RRF-fused with the grep results,
     index rebuilt incrementally by the skill itself — and honestly that's the
     one I reach for most: for natural-language "how do I…" queries over our
     (mostly Japanese) docs it beats keywords. So my data point for the
     grep-vs-RAG debate isn't "grep wins" — it's that at hundreds of pages, both
     flavors of retrieval fit inside the repo as skills, with nothing to host.
   • A failure worth writing down: we first tried a shared .claude/ in a parent
     folder above all projects. Claude Code doesn't pick it up for the
     git-managed projects underneath it. Per-skill links into ~/.claude/skills
     was the reliable path.
 
 Template (MIT): [99]https://github.com/umezy/team-ai-workflows
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [102]Please reload this page.
 
 [103]@suwonleee
 
 [104]suwonleee commented [105]Jul 20, 2026
 
 Copy link
 Copy Markdown
 
 Reading down this thread, nearly every tool here — mine included — exists to
 keep the model's memory current. But the pattern puts the judgment on the
 human: "you're in charge of sourcing, exploration, and asking the right
 questions." Nothing in it keeps that side from decaying. Your wiki stays
 current; your memory of why you decided things doesn't.
 
 So I built the other half of the loop. The wiki quizzes you back — day-granular
 spaced repetition (1·3·7·16·35·60) over the decision and insight pages only,
 since those are the ones whose why rots. It's the one part of the system that
 spends your time instead of saving it.
 
 Two things I didn't expect while building it:
 
 Citations don't survive leaving your machine. A footnote pointing at
 session-abc.jsonl is provenance for exactly one person. Pages now carry 1–2
 verbatim lines of the evidence inline — secret-screened, because transcripts
 really do contain credentials — so a teammate gets the grounding and not just
 the conclusion.
 
 Indexing that evidence made pages harder to find. BM25 length normalization:
 the excerpt lengthens the page's own chunk, which lowers its score for its own
 topic. Excluding excerpts from the index put recall@5 back to baseline.
 
 Markdown as the source of truth, local-first, no MCP, no build step. Works with
 Claude Code / Codex / OpenCode.
 
 [106]https://github.com/suwonleee/llmwiki
 
 ("llmwiki" is a crowded name in this thread — this is the one with the quiz.)
 
 [107][social-preview]
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [110]Please reload this page.
 
 [111]@kytmanov
 
 [112]kytmanov commented [113]Jul 20, 2026 •
 edited
 Loading
 
 Uh oh!
 
 There was an error while loading. [114]Please reload this page.
 
 Copy link
 Copy Markdown
 
 Synto v0.7.0 is out - 200★
 
 [115]https://github.com/kytmanov/synto
 
 Main addition: concept relations. Opt-in on ingest - the model extracts links
 between known concepts (e.g. Raft depends_on Consensus) with a short evidence
 quote. Packs ship the graph as graph/graph.json. Queries follow one hop to pull
 in related articles.
 
 Also new in v0.7:
 
 • reverse lookup: synto find ranks concept names, then titles, then body text.
 • provenance: synto trace shows where a term shows up in sources, or which
 articles used a source segment.
 • fix a wrong alias without a merge: synto concept alias add|remove|move.
 • silence known lint noise: ack advisories in synto.toml so they stop
 cluttering maintain.
 
 Same shape as before:
 
 • works with local LLMs
 • great with Ollama and LM Studio
 • plain Markdown
 • Obsidian-friendly
 • no vector DB
 • no cloud required
 • multi-language
 
 Star it if you want to support local-first AI tools. Fork it if you want to
 build on it.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [118]Please reload this page.
 
 [119]@Sarthib7
 
 [120]Sarthib7 commented [121]Jul 20, 2026 •
 edited
 Loading
 
 Uh oh!
 
 There was an error while loading. [122]Please reload this page.
 
 Copy link
 Copy Markdown
 
 CItadel 0.3.0
 
 This clicked hard — especially the contrast with RAG-as-rediscovery and the
 three-layer split (immutable sources → LLM-maintained wiki → schema). I've been
 running a team version of the same idea, and it maps cleanly onto your ingest/
 query/lint loop.
 
 For a personal wiki, your Obsidian + git + index.md approach is hard to beat at
 moderate scale. For a team, we hit different walls: who owns writes, what gets
 shared vs stays draft, semantic drift when five agents touch the same "entity
 page," and capture that can't depend on someone remembering to ingest after
 every meeting.
 
 We built [123]Citadel as that team layer — an Organization Vault on Cognee
 (Apache-2.0). It's not "markdown in a folder" (though markdown/Obsidian still
 fit as sources and UI):
 
 Node (seat:{slug}): private working memory; default target for autonomous
 capture (git pre-push + session hooks, fail-silent)
 Central: shared org memory; read-only for seats, evolves via governed promotion
 + org sync (GitHub/Linear digests)
 MCP + CLI: agents search before coding; citadel_search replaces "read index.md
 first" at scale
 Lint-ish: open Knowledge Conflicts instead of silently merging contradictions
 Re [124]@geetansharora team question: we did end up at MCP, but over a
 maintained vault rather than a static RAG index — closer to your wiki
 compounding than chunk retrieval.
 
 Repo + docs:
 
 [125]https://github.com/masumi-network/Citadel
 Connect an agent (MCP setup): [126]https://
 citadel-archive-production.up.railway.app/skills/connect
 Install the agent skill: npx skills add masumi-network/Citadel-Archive
 Would love to see a future where a Karpathy-style personal git wiki can promote
 curated pages into an org Central. Citadel is the org half today; the personal
 half still looks a lot like this gist.
 [127]Screenshot 2026-07-22 at 11 44 42
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [130]Please reload this page.
 
 [131]@gavischneider
 
 [132]gavischneider commented [133]Jul 20, 2026
 
 Copy link
 Copy Markdown
 
 I've been documenting everything LLM Wikis for the past 2+ months: [134]https:/
 /github.com/gavischneider/awesome-llm-wiki
 
 If you'd like your implementation/tool/guide/article to be added, PRs are
 welcome.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [137]Please reload this page.
 
 [138]@rath-muth
 
 [139]rath-muth commented [140]Jul 21, 2026
 
 Copy link
 Copy Markdown
 
 I'm a beginner in exploring Claude and LLMs. I'm trying to find the original
 copy of Karpathy's base prompt to feed it to my LLM agent to set up the system,
 I don't see it in the original post. Am I misunderstood something? or can
 someone help guide me by providing a prompt to start with?
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [143]Please reload this page.
 
 [144]@frankchu91
 
 [145]frankchu91 commented [146]Jul 22, 2026
 
 Copy link
 Copy Markdown
 
 
     I'm a beginner in exploring Claude and LLMs. I'm trying to find the
     original copy of Karpathy's base prompt to feed it to my LLM agent to set
     up the system, I don't see it in the original post. Am I misunderstood
     something? or can someone help guide me by providing a prompt to start
     with?
 
 there is no official prompt from Karpathy. Try this git repo here: [147]https:/
 /github.com/frankchu91/mindbase
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [150]Please reload this page.
 
 [151]@alfadur7
 
 [152]alfadur7 commented [153]Jul 22, 2026 •
 edited
 Loading
 
 Uh oh!
 
 There was an error while loading. [154]Please reload this page.
 
 Copy link
 Copy Markdown
 
 "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
 Taking that line literally is what made this click for me — if the wiki is a
 codebase, the discipline the AI-coding world is building around agents
 transfers. That discipline is harness engineering: everything around the agent
 — its checks, its review, the rules themselves — treated as the real
 engineering surface, organized as three nested loops. ([155]Dru Knox of Tessl)
 
 Each loop has a distinct job here:
 
 Inner — the agent checking itself while drafting, before you see anything. You
 note a source "might touch 10-15 wiki pages," and that you "could also
 batch-ingest many sources at once with less supervision." The inner loop is
 what makes that second option safe.
 
 Outer — review where a draft becomes part of the wiki. Right now that's you: "I
 read the summaries, check the updates, and guide the LLM on what to emphasize."
 Automating it takes two things a self-check can't do: deterministic checks
 across the whole wiki rather than the page in hand (your lint list, but at
 publication instead of "periodically"), and a fresh-eyes read by an agent that
 didn't write the page and can't see the writer's reasoning.
 
 Meta — the schema is what this loop edits. "You and the LLM co-evolve this over
 time" is already it; the mechanical version is that a defect caught twice
 becomes a rule, so you stop re-teaching it every session.
 
 Then the analogy breaks. Shipped code stays correct until the spec changes;
 knowledge doesn't. You already name the requirement — the wiki is "compiled
 once and then kept current" — and lint lists "stale claims that newer sources
 have superseded" right next to orphan pages and missing cross-references. But
 those are defects in the work; staleness is the world moving. Keeping a wiki
 current needs a fourth loop of its own, with published pages fed back in as
 input.
 
 I wrote up [156]the 4-loop Knowledge Factory in full — a design argument, not a
 measured result.
 
 [157]image
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [160]Please reload this page.
 
 [161]@ErikEvenson
 
 [162]ErikEvenson commented [163]Jul 24, 2026 •
 edited
 Loading
 
 Uh oh!
 
 There was an error while loading. [164]Please reload this page.
 
 Copy link
 Copy Markdown
 
 The additions that turn Karpathy’s sketch into something you can still trust
 after a few thousand pages:
 
 [165]https://www.erikevenson.net/building-an-llm-wiki-part-2.html
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [168]Please reload this page.
 
 [169]@ibehnam
 
 [170]ibehnam commented [171]Jul 24, 2026
 
 Copy link
 Copy Markdown
 
 
     The additions that turn Karpathy’s sketch into something you can still
     trust after a few thousand pages:
 
     [172]https://www.erikevenson.net/building-an-llm-wiki-part-2.html
 
 The article reads like AI slop.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [175]Please reload this page.
 
 [176]@denson
 
 [177]denson commented [178]Jul 25, 2026
 
 Copy link
 Copy Markdown
 
 Storing as OO-LD json seems to work well for at least up to 10k documents.
 
     This resonates strongly - and I'd push one layer deeper on why the
     bookkeeping gets abandoned. In our experience the thing that doesn't scale
     is unqualified links + free text. A lovingly hand-maintained personal wiki
     decays into prose and dead links within a couple of years; a team or
     corporate one gets there faster. What actually compounds is structure -
     typed entities you can query, not paragraphs you have to re-read.
 
     We took a structured variant of exactly this pattern into production about
     five years ago, on Semantic MediaWiki. Using MediaWiki's content-slot
     feature, every article keeps its unstructured body and a structured JSON
     slot side by side. The JSON slot's shape is defined by the article's
     category/categories, and each category carries a JSON Schema in its own
     slot - so one schema drives both auto-generated edit forms for humans and
     machine editing for everything else.
 
     Putting JSON-LD on top (we specced this as [179]OO-LD: one document that is
     simultaneously a JSON Schema and a JSON-LD context) turns the whole wiki
     into an RDF knowledge graph for free - you can run SPARQL across every
     entry. Your lint step (contradictions, orphans, missing cross-refs) becomes
     graph queries; query becomes structured retrieval, not just text search.
 
     When LLMs with JSON-Schema-driven structured output arrived, it was a
     drop-in fit: the exact schemas that render the forms also constrain LLM
     extraction.
 
     Mapping to your three layers: raw sources (immutable) / the wiki - but as
     typed, linkable entities rather than markdown / the schema - a JSON Schema
     per category rather than one prose config.
 
     Where we're putting research effort now is precisely your ingest loop at
     scale: take an unstructured knowledge chunk -> select the right schema(s)/
     categories to represent it -> fill them correctly and dedup against
     entities that already exist. That last "and" - entity resolution against a
     live graph - is the hard part; it's your lint moved to write-time.
 
     Curious whether others here have pushed on write-time dedup - that's where
     the pattern either compounds or sprawls.
 
     Reference implementation: [180]OpenSemanticLab (live demo: [181]https://
     demo.open-semantic-lab.org) · schema approach: [182]OO-LD.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [185]Please reload this page.
 
 [186]@akash07k
 
 [187]akash07k commented [188]Jul 25, 2026
 
 Copy link
 Copy Markdown
 
 [189]@frankchu91
 Wow, it's really fantastic!
 I read on your repo:
 
     still in v1 → v2 migration.
 
 So, when are you planning to migrate it to V2?
 
     there is no official prompt from Karpathy. Try this git repo here: [190]
     https://github.com/frankchu91/mindbase
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [193]Please reload this page.
 
 [194]@bollakarthikeya
 
 [195]bollakarthikeya commented [196]Jul 26, 2026 •
 edited
 Loading
 
 Uh oh!
 
 There was an error while loading. [197]Please reload this page.
 
 Copy link
 Copy Markdown
 
 This idea is very powerful and it resonates so deep with what I have been going
 through; a running inventory of knowledge that is constantly updated with the
 new incoming sources of information. Since I am an avid note taker and since it
 is nearly impossible to constantly sieve through the many hand-written pages,
 this idea - a knowledge wiki that is constantly evolving - is what I need.
 Thank you Andrej for this brilliant idea. Kudos to you!
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [200]Please reload this page.
 
 [201]@gowtham0992
 
 [202]gowtham0992 commented [203]Jul 28, 2026
 
 Copy link
 Copy Markdown
 
 Link 2.0.0 is out: the memory layer got a face.
 
 LinkBar puts the review gate in your menu bar. Session hooks already captured
 memory automatically; the missing half was reviewing it without going anywhere.
 Now a capture lands and you get a native notification with a one-tap Accept,
 showing the exact line it will save.
 
 [204]linkbar-tour
 
 The part I use most is the palette. Hit Option-Command-M anywhere on the
 machine and a floating bar opens over whatever app you're in: type a question
 to recall from your memory, or start with + to remember something. It's
 review-gated like every other write. I stopped switching to a terminal to ask
 my own memory things, which turned out to be the whole point.
 
 [205]image
 
 There's also a live pulse of which agent sessions are writing right now, a
 browser over every memory file with supersede lineage, and a status tab showing
 whether the CLI, workspace, MCP, hooks, recall tier, and viewer are actually
 healthy, each with a one-click fix that verifies it worked instead of just
 claiming success.
 
 The whole app is a thin SwiftUI client over lnk --json. No new backend, no new
 API, nothing new to trust: it runs the same reviewed commands as the CLI, so
 the app can never drift from what Link actually does.
 
 No breaking changes. Every CLI command, MCP tool, hook, and memory file from
 1.7 works exactly as before; the major version marks the app's debut, not an
 API break.
 
 Still: wiki as the storage layer, every memory a file you can open, nothing
 durable without review.
 
 brew upgrade link                                # CLI 2.0.0
 brew install --cask gowtham0992/link/linkbar     # the menu bar app
 
 Release notes: [206]https://github.com/gowtham0992/link/releases/tag/v2.0.0
 
 Repo: [207]https://github.com/gowtham0992/link
 Site: [208]https://gowtham0992.github.io/link/
 PyPI: [209]https://pypi.org/project/link-mcp/
 MCP: [210]https://registry.modelcontextprotocol.io/?q=
 io.github.gowtham0992%2Flink
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [213]Please reload this page.
 
 [214]@XBlueSky
 
 [215]XBlueSky commented [216]Jul 29, 2026
 
 Copy link
 Copy Markdown
 
 Update from my earlier comment here: I originally shared Cortexes when it was
 still an early workflow for collaboratively distilling Claude Code
 conversations into a Markdown vault.
 
 Since then, it has grown into an open-source, installable Claude Code plugin,
 currently at v1.1.0:
 
 [217]https://github.com/XBlueSky/cortexes
 
 A few things I learned while turning the idea into something I use across real
 coding sessions:
 
 Capturing everything is easy; deciding what deserves to become knowledge is the
 harder problem.
 
 Cortexes now captures sessions automatically, but filters low-value tool output
 before writing them into the Raw layer. Distillation is map-first and
 context-budgeted, so a long session can be processed in bounded spans without
 loading the entire transcript into the context window.
 
 The more important part for me is maintenance. Newly distilled findings do not
 always become new notes. The broadcast workflow can fuse them into related
 existing pages, correcting assumptions and adding caveats. This is my attempt
 to address knowledge rot rather than simply accumulating more memory.
 
 Recall now uses hybrid BM25 + vector retrieval with reciprocal-rank fusion,
 including mixed Chinese/English technical queries and a BM25-only fallback when
 offline.
 
 The durable artifact is still plain Markdown + Git. The vault can be opened
 directly in Obsidian, so the agent’s memory remains readable, editable,
 diffable, and reversible rather than hidden inside a vector database.
 
 I now think of Cortexes less as a memory store and more as a maintenance
 pipeline:
 
 capture → distill → fuse → retrieve
 
 Project: [218]https://github.com/XBlueSky/cortexes
 
 Interactive overview: [219]https://cortexes.pages.dev/
 
 I would be interested in feedback from people who have run an LLM-maintained
 wiki over time: what policies or checks have been most effective at preventing
 stale or contradictory knowledge from quietly accumulating?
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [222]Please reload this page.
 
 [223]@GeraldGrootRoessink
 
 [224]GeraldGrootRoessink commented [225]Jul 29, 2026
 
 Copy link
 Copy Markdown
 
 I agree with the motivation (using an LLM to maintain a persistent, compounding
 artifact as a “knowledge view”), but I’m skeptical of proposals that treat
 Markdown front-matter as the semantic backbone. We need something
 machine-executable: a precise way to define semantics, data selection, joins/
 mappings, and provenance for the resulting view. Human-oriented formatting from
 Markdown isn’t essential for that; an LLM can generate presentation at the end.
 
 Much of the relevant infrastructure already exists in the Semantic Web: HTTP,
 URIs, RDF, and SPARQL, plus established linked data vocabularies. So the gap is
 less about inventing a new container and more about producing view ready
 outputs in a repeatable, automated way.
 
 My conclusion: the key missing piece is not a new metadata container format,
 but a reliable, machine executable way to build and maintain an LLM ready
 “knowledge view” from multiple sources.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [228]Please reload this page.
 
 [229]@suwonleee
 
 [230]suwonleee commented [231]Jul 29, 2026
 
 Copy link
 Copy Markdown
 
 Follow-up to my earlier comment here (the project wiki that quizzes you back) —
 since then the interesting problems have all been trust boundaries, the kind
 that only show up once the thing runs on machines that aren't yours:
 
 A clone is not consent. Early versions treated git clone + setup as permission
 to start capturing sessions. It isn't. Everything is now inert until you enroll
 a repository explicitly, and until a session is known to belong to an enrolled
 repo, the capture layer reads exactly two routing fields from a transcript and
 stops — fail closed, by budget.
 
 The installing agent is your least-trusted user. On a nonstandard machine, the
 agent doing the install is also the thing searching your disk for where Claude
 Code / Codex / OpenCode keep their data. So discovery became three-tier:
 deterministic resolution → schema-signature verification (a candidate is judged
 by what's inside — transcripts, rollouts, a session table — never by its name;
 the E2E that motivated this watched a plain home directory pass as a Claude
 profile because it contained a folder called projects/) → and only then
 persistence, which the engine refuses unless verification passed. And a
 connected location stays read-only forever: capture reads from it, install
 wiring never writes into it.
 
 Models are observed, not declared. The engine shipped with a hardcoded model id
 for its generative passes; it had gone stale by the time the replacement landed
 — the argument making itself. Now a pass runs on whatever model the session
 actually recorded (every harness already writes this), with per-harness
 fallbacks only when nothing was observed. The follow-up lesson cost a day: the
 first id-validation regex rejected llama3.1:8b, and an over-strict guard fails
 exactly like a stale constant — silently.
 
 Still markdown as the source of truth, local-first, no MCP, no build step,
 three harnesses.
 
 [232]https://github.com/suwonleee/llmwiki — if any of this is useful to you, a
 star genuinely helps others in this thread find it among the many llmwikis.
 
 [233][social-preview]
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [236]Please reload this page.
 
 [237]@antondziatkovskii
 
 [238]antondziatkovskii commented [239]Jul 29, 2026
 
 Copy link
 Copy Markdown
 
 One failure mode this pattern has that plain RAG doesn't — and a measurement of
 it.
 
 A compiled wiki answers more confidently than raw retrieval. That's the point
 of it. But confidence gets decoupled from whether the answer is actually in
 there, and in an incrementally compiled wiki that compounds: a confident
 fabrication gets filed back as a page, and then it is a source.
 
 I measured this on my own vault (~4 months of ingested sources, e5 embeddings +
 a reranker on top). 6 questions — 3 with answers in the wiki, 3 deliberately
 outside it — looking at the top rerank score of each result set:
 
                question                 in the wiki? top rerank score
 our rule on treating a cause as a claim yes          +8.66
 how we sync machines                    yes          +5.87
 our memory-layer decision               yes          +1.57
 my pizza recipe                         no           −1.03
 bus fare in Kuala Lumpur                no           −3.82
 max depth of the bathyscaphe Trieste    no           −4.53
 
 Clean separation — worst "in" beats best "out" by 2.6, no overlap, natural
 cutoff at 0.
 
 The part that actually mattered: all six queries returned exactly 12 hits. The
 bathyscaphe question got 12 confident notes out of a personal vault that has
 never heard of bathyscaphes. Nothing anywhere in the output said "I found
 nothing." There was no threshold in the code at all — the reranker computed the
 score and then it was thrown away.
 
 Honest limits: n=6, I picked the questions, and the "out" ones are far from my
 domains. This shows the signal exists; it does not show where the threshold
 belongs. The dangerous case — a question from a domain adjacent to the wiki —
 is untested. Running it in shadow for a week, logging the top score of every
 real query without cutting anything, before wiring an actual cutoff.
 
 Concrete suggestion for the schema layer (CLAUDE.md / AGENTS.md), since that's
 where this belongs rather than in code: a rule that the agent must say "the
 wiki has no confident answer on this" instead of synthesizing from
 low-relevance hits — and that such an answer is never filed back.
 
 Retrieval layer this came out of, if useful: [240]https://github.com/
 Palo-Alto-AI-Research-Lab/sqlite-graph-memory — Graph RAG on SQLite over an
 Obsidian vault, [[wikilinks]] as the graph. The citation-checking half is
 separate: [241]https://github.com/Palo-Alto-AI-Research-Lab/
 verbatim-citation-gate
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [244]Please reload this page.
 
 [245]@Nikalo71
 
 [246]Nikalo71 commented [247]Jul 30, 2026
 
 Copy link
 Copy Markdown
 
 Voici un Gist très très utile, merci beaucoup pour votre travail et votre
 partage.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [250]Please reload this page.
 
 [251]@JanYork
 
 [252]JanYork commented [253]Jul 31, 2026
 
 Copy link
 Copy Markdown
 
 I've implemented a small version, and I think it's pretty good.
 
 If you're interested, you can check it out at [254]https://github.com/JanYork/
 llm-wiki-cli
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [257]Please reload this page.
 
 [258]@Nikalo71
 
 [259]Nikalo71 commented [260]Jul 31, 2026
 
 Copy link
 Copy Markdown
 
 Thanks again for this work. It's perfect and I'm sure it will help many people.
 I created the Claude.MD file so it's in French and everything seems to be
 working very well.
 
 One technical question, though: I'm using Claude in VS Code.
 My question (being a complete beginner with this kind of tool) is whether it's
 necessary or optional to create a Wordspace for this project?
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [263]Please reload this page.
 
 [264]@Nikalo71
 
 [265]Nikalo71 commented [266]Jul 31, 2026
 
 Copy link
 Copy Markdown
 
 
     I've implemented a small version, and I think it's pretty good.
 
     If you're interested, you can check it out at [267]https://github.com/
     JanYork/llm-wiki-cli
 
 Thank you fore sharring !
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [270]Please reload this page.
 
 [271]@alexadamus77-ui
 
 [272]alexadamus77-ui commented [273]Aug 1, 2026
 
 Copy link
 Copy Markdown
 
 Really clean approach to unified academic search and deduplication across
 sources! Managing source degradation and fallback queries across multiple
 endpoints takes a lot of effort.
 
 If you're looking for a fast, reliable academic search backend to simplify
 paper lookup, citation graphs, and metadata retrieval, [274]ScholarAPI is worth
 a look. It provides structured JSON responses directly, making paper search
 workflows much more deterministic.
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [277]Please reload this page.
 
 [278]@gowtham0992
 
 [279]gowtham0992 commented [280]Aug 3, 2026
 
 Copy link
 Copy Markdown
 
 Link 2.1.0 is out. This one is about trust: memory that cannot repeat itself
 and knows when to re-ask.
 
 Since 2.0 I dogfooded the automatic capture pipeline hard and my own review
 inbox grew to 20 pending captures, five of them the same conversation captured
 five times. 2.1 is everything that fixing that properly turned into.
 
 What's new:
 
   • Inbox zero. Proposals are fingerprinted and deduped against everything
     pending, accepted, or dismissed. Deleting a capture records the dismissal,
     so the same proposal never comes back. One conversation = one capture,
     refreshed in place. "lnk dedup-captures" collapses an existing backlog
     (mine went 20 to 9 in one command).
   • Trust lifecycle. Every memory now gets a review window by type: project
     context 3 months, preferences 6, decisions 12. Reviewing re-arms it. Aged
     memories are never hidden, they get labeled "review due" everywhere agents
     read, including the session brief. As far as I know no other memory system
     re-asks whether what it knows is still true.
   • Contradiction detection got serious. Revisions like "we don't use X
     anymore" now supersede the old memory: exposure went from 0.583 to 0.167 on
     the hygiene benchmark, and with the local semantic tier on, even
     rephrasings with zero shared words get caught ("SQLite with FTS" revised as
     "DuckDB files").
   • Memory poisoning benchmark. A planted memory gets injected into every
     future session, which makes agent memory the biggest prompt injection
     target there is. 15 authored attacks now run through the real pipeline in
     CI: 0 reach the inbox unlabeled, 0 false positives on real preferences.
     Injection-shaped proposals get flagged in the inbox: "verify you actually
     said this before accepting". I believe this is the only published
     adversarial benchmark on an agent memory write path.
 
 [281]linkbar-11-inbox-injection
 
   • lnk setup. Install is now two commands total. "lnk setup" detects every
     agent on your machine (Claude Code, Codex, Cursor, Windsurf, Zed, Kiro,
     Gemini CLI) and wires them all: workspace, MCP, session hooks. It ran on my
     own machine during the release and wired 5 agents first try. Upgrades are
     the same command.
   • LinkBar 1.1. Tap any memory for its trust card (where it came from, when it
     was reviewed, whether recall will use it and why). Injection warnings show
     right on the capture row. Full backlog is reviewable with a cleanup button.
 
 [282]linkbar-11-explain-card
 
   • The homepage now embeds a real exported Link workspace you can click
     through, generated by "lnk snapshot".
 
 # macOS, the full experience (CLI + menu bar app)
 brew install --cask gowtham0992/link/linkbar
 lnk setup
 
 # CLI only (or Linux)
 brew install gowtham0992/link/link
 lnk setup
 
 # already running Link
 brew upgrade && lnk setup
 
 Still: wiki as the storage layer, every memory a file you can open, nothing
 durable without review.
 
 Release notes: [283]https://github.com/gowtham0992/link/releases/tag/v2.1.0
 
 Repo: [284]https://github.com/gowtham0992/link
 Site: [285]https://gowtham0992.github.io/link/
 PyPI: [286]https://pypi.org/project/link-mcp/
 MCP: [287]https://registry.modelcontextprotocol.io/?q=
 io.github.gowtham0992%2Flink
 Benchmarks with full configs and the experiments that lost: [288]https://
 github.com/gowtham0992/link/blob/main/benchmarks/RESULTS.md
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [291]Please reload this page.
 
 [292]@mas213
 
 [293]mas213 commented [294]Aug 3, 2026
 
 Copy link
 Copy Markdown
 
 Update since my last comment. [295]https://gist.github.com/karpathy/
 442a6bf555914893e9891c11519de94f?permalink_comment_id=6237886#
 gistcomment-6237886
 Ran the behavioral graph against a frontier model (Claude Fable 5) on the same
 repo, same commit. Wanted to know: does a deterministic graph find the same
 things a reasoning model finds?
 Overlap: near zero.
 The model read ~75 files it picked itself and found defect mechanisms. Races,
 silent fallbacks, missing retries. The graph mapped all 4,849 behaviors
 exhaustively and ranked them by structural exposure. Completely different
 output lists. Each instrument's blind spot was the other's finding.
 Two agreements mattered. Both flagged the same message-queue layer (184
 importers, one spec file) as high-risk untested surface. Both deprioritized the
 same view/page-layout family. Convergent deprioritization from decorrelated
 instruments is harder to fake than convergent alarm.
 One disagreement was productive. The model's top finding sat in the graph's
 data but outside its top 20. Tracing why isolated two scoring factors
 documented in the methodology but not yet weighted in the shipped formula. The
 disagreement functioned as instrument calibration. Fixed same day, in public.
 Also closed the proof ladder end-to-end on a second repo (Go, ~8,700
 behaviors). Three mutation proofs. One was self-incriminating: the graph's own
 test generator hallucinated an expected value. The execution layer caught it.
 Oracle corrected from source. Mutation proof then closed the method. A
 verification layer that catches its own generator is the strongest evidence for
 the decorrelation argument.
 The Lint operation from the original gist now has four evidence tiers instead
 of binary tested/untested: dynamically proven (mutation killed), test signal
 (static link, no proof), candidate (name match only), no signal. The graph
 refuses to overstate. Nothing reaches "covered" without execution.
 
 [296]@jessicayoung12 , curious what domain you applied it to. The compounding
 effect you describe is exactly what we see. The graph after 50 PRs is a
 fundamentally different instrument than the graph after 5. Every incident filed
 teaches it a failure mode it didn't have before.
 
 Full comparison write-up: [297]https://orangepro.ai/blog/fable-vs-orangepro
 Repo unchanged: [298]https://github.com/OrangeproAI/orangepro-mcp
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [301]Please reload this page.
 
 [302]@BackendGameSetMatch
 
 [303]BackendGameSetMatch commented [304]Aug 3, 2026
 
 Copy link
 Copy Markdown
 
 My take on it: [305]https://github.com/BackendGameSetMatch/sourcebook
 
 Sorry, something went wrong.
 
 Uh oh!
 
 There was an error while loading. [308]Please reload this page.
 
 [309]Sign up for free to join this conversation on GitHub. Already have an
 account? [310]Sign in to comment
 
 Footer
 
 [311] © 2026 GitHub, Inc.
 
 Footer navigation
 
   • [312]Terms
   • [313]Privacy
   • [314]Security
   • [315]Status
   • [316]Community
   • [317]Docs
   • [318]Contact
   • [319] Manage cookies
   • [320] Do not share my personal information
 
 [321](Dismiss error) You can’t perform that action at this time.
 [322](Close dialog)
 
 References:
 
 [1] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#start-of-content
 [2] https://gist.github.com/
 [6] https://gist.github.com/discover
 [7] https://github.com/
 [8] https://gist.github.com/auth/github?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
 [9] https://gist.github.com/join?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f&source=header-gist
 [10] https://gist.github.com/
 [11] https://gist.github.com/auth/github?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
 [12] https://gist.github.com/join?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f&source=header-gist
 [13] -
 [14] -
 [15] -
 [18] https://gist.github.com/karpathy
 [19] https://gist.github.com/karpathy
 [20] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
 [22] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/archive/ac46de1ad27f92b28ac95459c782c07f6b8c964a.zip
 [23] https://gist.github.com/login?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
 [24] https://gist.github.com/login?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
 [30] https://docs.github.com/articles/which-remote-url-should-i-use
 [33] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
 [34] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/revisions
 [35] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/stargazers
 [36] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/forks
 [42] https://docs.github.com/articles/which-remote-url-should-i-use
 [45] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/archive/ac46de1ad27f92b28ac95459c782c07f6b8c964a.zip
 [46] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f/raw/ac46de1ad27f92b28ac95459c782c07f6b8c964a/llm-wiki.md
 [47] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#file-llm-wiki-md
 [48] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#llm-wiki
 [49] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#the-core-idea
 [50] https://tolkiengateway.net/wiki/Main_Page
 [51] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#architecture
 [52] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#operations
 [53] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#indexing-and-logging
 [54] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#optional-cli-tools
 [55] https://github.com/tobi/qmd
 [56] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#tips-and-tricks
 [57] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#why-this-works
 [58] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#note
 [63] https://gist.github.com/frankchu91
 [64] https://gist.github.com/frankchu91
 [65] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6263946#gistcomment-6263946
 [66] -
 [67] https://github.com/frankchu91/mindbase
 [68] https://raw.githubusercontent.com/frankchu91/mindbase/main/docs/assets/webui.png
 [71] -
 [72] https://gist.github.com/sturlese
 [73] https://gist.github.com/sturlese
 [74] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6264580#gistcomment-6264580
 [75] https://github.com/sturlese/hippocampus
 [76] https://github.com/sturlese/hippocampus/blob/main/docs/what-happens-when-you-ingest.md
 [79] -
 [80] https://gist.github.com/lucianfialho
 [81] https://gist.github.com/lucianfialho
 [82] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265193#gistcomment-6265193
 [83] https://gist.github.com/lucianfialho/44034e0d02a2bfccca2ad6358bde1dff
 [86] -
 [87] https://gist.github.com/bprice1000
 [88] https://gist.github.com/bprice1000
 [89] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265282#gistcomment-6265282
 [90] https://gist.github.com/bprice1000/f986547dda0a82c5178faa6e237247fe
 [93] -
 [94] https://gist.github.com/umezy
 [95] https://gist.github.com/umezy
 [96] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265520#gistcomment-6265520
 [97] -
 [98] https://github.com/geetansharora
 [99] https://github.com/umezy/team-ai-workflows
 [102] -
 [103] https://gist.github.com/suwonleee
 [104] https://gist.github.com/suwonleee
 [105] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6265997#gistcomment-6265997
 [106] https://github.com/suwonleee/llmwiki
 [107] https://raw.githubusercontent.com/suwonleee/llmwiki/main/assets/social-preview.png
 [110] -
 [111] https://gist.github.com/kytmanov
 [112] https://gist.github.com/kytmanov
 [113] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6266796#gistcomment-6266796
 [114] -
 [115] https://github.com/kytmanov/synto
 [118] -
 [119] https://gist.github.com/Sarthib7
 [120] https://gist.github.com/Sarthib7
 [121] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6266907#gistcomment-6266907
 [122] -
 [123] https://github.com/masumi-network/Citadel-Archive
 [124] https://github.com/geetansharora
 [125] https://github.com/masumi-network/Citadel
 [126] https://citadel-archive-production.up.railway.app/skills/connect
 [127] https://private-user-images.githubusercontent.com/112841873/625046636-60c5bae4-7f06-41bc-97d6-55e086662db9.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xMTI4NDE4NzMvNjI1MDQ2NjM2LTYwYzViYWU0LTdmMDYtNDFiYy05N2Q2LTU1ZTA4NjY2MmRiOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODA0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgwNFQwNTIzMTJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03ZjQ1YTAzNjRhNzc2Y2VjMDU4ODA5ZGFiODhlYjNiN2ZlYjg2YjE1MThlYjQ5MjdlYWE3NTYxMDkzODk3NTA0JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.HRsnT7a_A-CJGo6SGlRV9erRQQtAso6v0ZFPcQrJReQ
 [130] -
 [131] https://gist.github.com/gavischneider
 [132] https://gist.github.com/gavischneider
 [133] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6266938#gistcomment-6266938
 [134] https://github.com/gavischneider/awesome-llm-wiki
 [137] -
 [138] https://gist.github.com/rath-muth
 [139] https://gist.github.com/rath-muth
 [140] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6268995#gistcomment-6268995
 [143] -
 [144] https://gist.github.com/frankchu91
 [145] https://gist.github.com/frankchu91
 [146] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6269557#gistcomment-6269557
 [147] https://github.com/frankchu91/mindbase
 [150] -
 [151] https://gist.github.com/alfadur7
 [152] https://gist.github.com/alfadur7
 [153] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6269698#gistcomment-6269698
 [154] -
 [155] https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236
 [156] https://alfadur7.github.io/llm-wiki-newsroom/knowledge-factory/
 [157] https://private-user-images.githubusercontent.com/6949852/624935308-0e77e371-cba4-4e0d-8e7d-b1e2b9757713.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii82OTQ5ODUyLzYyNDkzNTMwOC0wZTc3ZTM3MS1jYmE0LTRlMGQtOGU3ZC1iMWUyYjk3NTc3MTMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDgwNCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA4MDRUMDUyMzEyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YmMzNzc4Y2UwNjFhMDA0ZDdiZTZkZmM3Mzg2NTFhZTM5YjQyMTc0NjQ5NTkzNDU2ZGRjMGZkZTM2MDcyYjk5NSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.qSUf3gssLHJKQLQXrusUZ7QdAcsL8L3ZQ8Q0nVkLOus
 [160] -
 [161] https://gist.github.com/ErikEvenson
 [162] https://gist.github.com/ErikEvenson
 [163] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6273560#gistcomment-6273560
 [164] -
 [165] https://www.erikevenson.net/building-an-llm-wiki-part-2.html
 [168] -
 [169] https://gist.github.com/ibehnam
 [170] https://gist.github.com/ibehnam
 [171] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6273920#gistcomment-6273920
 [172] https://www.erikevenson.net/building-an-llm-wiki-part-2.html
 [175] -
 [176] https://gist.github.com/denson
 [177] https://gist.github.com/denson
 [178] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6276072#gistcomment-6276072
 [179] https://github.com/OO-LD
 [180] https://github.com/OpenSemanticLab
 [181] https://demo.open-semantic-lab.org/
 [182] https://github.com/OO-LD
 [185] -
 [186] https://gist.github.com/akash07k
 [187] https://gist.github.com/akash07k
 [188] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6276421#gistcomment-6276421
 [189] https://github.com/frankchu91
 [190] https://github.com/frankchu91/mindbase
 [193] -
 [194] https://gist.github.com/bollakarthikeya
 [195] https://gist.github.com/bollakarthikeya
 [196] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6278138#gistcomment-6278138
 [197] -
 [200] -
 [201] https://gist.github.com/gowtham0992
 [202] https://gist.github.com/gowtham0992
 [203] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6281820#gistcomment-6281820
 [204] https://private-user-images.githubusercontent.com/15722259/627599374-f5711fac-cec4-464c-b847-da9bfb077c6a.gif?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82Mjc1OTkzNzQtZjU3MTFmYWMtY2VjNC00NjRjLWI4NDctZGE5YmZiMDc3YzZhLmdpZj9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE2MTg2Mzc5OGNhYmY4Zjk3MmIwMDFmNDhiODllOTk4ZmVkZWU5YTY5OGIzMzM1OGI4YjY3ZTJhNzY2ODBkZTEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRmdpZiJ9.37-hN6kHMCo63WKi1_b42bcCrMhSiX1A1CXkbe4Ogw0
 [205] https://private-user-images.githubusercontent.com/15722259/627599063-7cac41f4-6fbb-4e44-bcd1-7c37221c26dd.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82Mjc1OTkwNjMtN2NhYzQxZjQtNmZiYi00ZTQ0LWJjZDEtN2MzNzIyMWMyNmRkLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQyZTliMzgxZjNmMGZkZjQwMzE3YzY0MGE3ZDgzNDdhMzc1NDY0NDhmMzJjNzNiNjAzNDQyMGUyNTEwMDkwOGQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.2hvJrn4qDA9u_zh9Fy94tPAzY3FUNKoFJwhPsjZozVM
 [206] https://github.com/gowtham0992/link/releases/tag/v2.0.0
 [207] https://github.com/gowtham0992/link
 [208] https://gowtham0992.github.io/link/
 [209] https://pypi.org/project/link-mcp/
 [210] https://registry.modelcontextprotocol.io/?q=io.github.gowtham0992%2Flink
 [213] -
 [214] https://gist.github.com/XBlueSky
 [215] https://gist.github.com/XBlueSky
 [216] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6284110#gistcomment-6284110
 [217] https://github.com/XBlueSky/cortexes
 [218] https://github.com/XBlueSky/cortexes
 [219] https://cortexes.pages.dev/
 [222] -
 [223] https://gist.github.com/GeraldGrootRoessink
 [224] https://gist.github.com/GeraldGrootRoessink
 [225] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6284539#gistcomment-6284539
 [228] -
 [229] https://gist.github.com/suwonleee
 [230] https://gist.github.com/suwonleee
 [231] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6284942#gistcomment-6284942
 [232] https://github.com/suwonleee/llmwiki
 [233] https://raw.githubusercontent.com/suwonleee/llmwiki/main/assets/social-preview.png
 [236] -
 [237] https://gist.github.com/antondziatkovskii
 [238] https://gist.github.com/antondziatkovskii
 [239] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6285217#gistcomment-6285217
 [240] https://github.com/Palo-Alto-AI-Research-Lab/sqlite-graph-memory
 [241] https://github.com/Palo-Alto-AI-Research-Lab/verbatim-citation-gate
 [244] -
 [245] https://gist.github.com/Nikalo71
 [246] https://gist.github.com/Nikalo71
 [247] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6286837#gistcomment-6286837
 [250] -
 [251] https://gist.github.com/JanYork
 [252] https://gist.github.com/JanYork
 [253] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6288782#gistcomment-6288782
 [254] https://github.com/JanYork/llm-wiki-cli
 [257] -
 [258] https://gist.github.com/Nikalo71
 [259] https://gist.github.com/Nikalo71
 [260] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6289081#gistcomment-6289081
 [263] -
 [264] https://gist.github.com/Nikalo71
 [265] https://gist.github.com/Nikalo71
 [266] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6289082#gistcomment-6289082
 [267] https://github.com/JanYork/llm-wiki-cli
 [270] -
 [271] https://gist.github.com/alexadamus77-ui
 [272] https://gist.github.com/alexadamus77-ui
 [273] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6290598#gistcomment-6290598
 [274] https://scholarapi.net/
 [277] -
 [278] https://gist.github.com/gowtham0992
 [279] https://gist.github.com/gowtham0992
 [280] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6294542#gistcomment-6294542
 [281] https://private-user-images.githubusercontent.com/15722259/630686175-a04ed73d-5419-4cd8-aa72-d25357aeec87.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82MzA2ODYxNzUtYTA0ZWQ3M2QtNTQxOS00Y2Q4LWFhNzItZDI1MzU3YWVlYzg3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTlmZTdlMzljYTIzOGIwZmE4YWI0Y2JjZGFmYmE1NDY5MmNjYmNmNjg0ZGQyNzllNjhjYWNlYWU5OWVhMzM4ZTQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.5G2DQYmD0w1iFKy321Nyt-f9fCEvIr31aUZm0lej598
 [282] https://private-user-images.githubusercontent.com/15722259/630686425-35cd9bcd-87e1-4aed-9652-0f80562294f1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODU4MjEyOTIsIm5iZiI6MTc4NTgyMDk5MiwicGF0aCI6Ii8xNTcyMjI1OS82MzA2ODY0MjUtMzVjZDliY2QtODdlMS00YWVkLTk2NTItMGY4MDU2MjI5NGYxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MDQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODA0VDA1MjMxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWRhNzY4NTM3NmM1ODgzMGExMDRkZmJlNWMzZjE5ZDE1ODM0NjIzZjc5ZjAxM2M5NjY0MDk3ZDAzOGUxMTczZWYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.ds9RgsEVPnnzUdsEG-j3kNLkaGtSDEucaPBdxN0m42A
 [283] https://github.com/gowtham0992/link/releases/tag/v2.1.0
 [284] https://github.com/gowtham0992/link
 [285] https://gowtham0992.github.io/link/
 [286] https://pypi.org/project/link-mcp/
 [287] https://registry.modelcontextprotocol.io/?q=io.github.gowtham0992%2Flink
 [288] https://github.com/gowtham0992/link/blob/main/benchmarks/RESULTS.md
 [291] -
 [292] https://gist.github.com/mas213
 [293] https://gist.github.com/mas213
 [294] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6295034#gistcomment-6295034
 [295] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6237886#gistcomment-6237886
 [296] https://github.com/jessicayoung12
 [297] https://orangepro.ai/blog/fable-vs-orangepro
 [298] https://github.com/OrangeproAI/orangepro-mcp
 [301] -
 [302] https://gist.github.com/BackendGameSetMatch
 [303] https://gist.github.com/BackendGameSetMatch
 [304] https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink_comment_id=6295163#gistcomment-6295163
 [305] https://github.com/BackendGameSetMatch/sourcebook
 [308] -
 [309] https://gist.github.com/join?source=comment-gist
 [310] https://gist.github.com/login?return_to=https%3A%2F%2Fgist.github.com%2Fkarpathy%2F442a6bf555914893e9891c11519de94f
 [311] https://github.com/
 [312] https://docs.github.com/site-policy/github-terms/github-terms-of-service
 [313] https://docs.github.com/site-policy/privacy-policies/github-privacy-statement
 [314] https://github.com/security
 [315] https://www.githubstatus.com/
 [316] https://github.community/
 [317] https://docs.github.com/
 [318] https://support.github.com/?tags=dotcom-footer