A diagram going around promises "Obsidian + Opus 5.5 + Jev" as a unified cognitive system with 10× faster chat and 80% less time at work. We checked where it comes from, then worked out what each of its layers would look like on our own machine: which parts can run here, which can't, and what we'd pick.
Researched October 2026. Claims about other people's work cite a source (S1 to S19, listed at the end). Hardware figures were read from the machine; the one speed figure was measured on it. Everything under "What we'd build" is a proposal; nothing on this page has been installed.
The image is laid out like a paper: a "Technical Note" header from "Agentic Software Engineering Practice 2026", an abstract, index terms, numbered sections. Its title is "Andrej Karpathy: Obsidian + Opus 5.5 + Jev". It describes three parts: Obsidian as persistent memory and a knowledge graph, Anthropic's Opus 5.5 for deep reasoning, and Jev for "agent orchestration", joined in a plan, act, observe, improve loop. It claims 10× faster chat and up to 80% less time spent on work. A small watermark in the corner reads "made by @polydao".
Karpathy did publish something close to the first layer. On 4 April 2026 he posted a gist called "LLM Wiki": keep raw
sources in a folder, have an LLM agent compile them into an interlinked markdown wiki that it maintains, and steer it
with a schema file such as CLAUDE.md or AGENTS.md. In his words, "Obsidian is the IDE; the LLM is
the programmer; the wiki is the codebase." S1 The agents he names are Claude Code, Codex and OpenCode. He
doesn't mention Opus 5.5 or Jev, doesn't propose a three-part "framework", and makes no speed claims; Jev appears on
that page only in a reader's comment. S1
The diagram is credited to @polydao, an X account that posts promotional threads in the same style, such as "Obsidian + Claude Opus 4.8 = the $6,000 system you are missing" and "Jev + Opus 5.5 is insane for building a company brain". S2 S3 It isn't a paper: we found no publication called "Agentic Software Engineering Practice 2026", no authors, and no method. Karpathy's name is on the title because his gist made the Obsidian idea popular.
Jev is a model from TypeSafe AI, released in September 2026, that TypeSafe calls a "System One" model. You give it state and a typed question (pick one of these branches, score this, is this condition true) and it returns a typed answer with a probability, in roughly 70 to 500 milliseconds. It doesn't write text. S4 S5 S6 Write-ups are explicit that Jev makes the decision while your own code or orchestrator still calls the models, holds the context and runs the tools. S5 S7 So "Jev orchestrates agents and tools" overstates it: Jev is a fast router or gate inside an orchestrator.
It is hosted only. TypeSafe hasn't published weights and offers no on-premises version; it is reached through TypeSafe's API and resellers such as OpenRouter. S6 Independent projects called OpenJev copy its API on top of small open models; one reports a 4B Qwen model at 84.5% on its own test against 88.3% for Jev, a self-reported number nobody has rechecked. S8
The diagram and its text state both numbers three times each and never say what was measured, against what baseline, on which tasks, or by whom. We found no study behind them. Treat them as marketing. If anything, the pieces pull the other way on speed: Opus is the slowest, most expensive tier of its family, so a setup built around it gets faster only by sending less work to it, which is what a router like Jev or a small local model is for.
Verdict. The underlying idea is sound and not new: keep knowledge in plain files an agent can read and update, use a strong model for hard thinking, and put a loop with tools around it. The branding, the Karpathy attribution and the numbers are not to be relied on.
Everything runs on one 2019 laptop; its limits are written up on ruby.im/hardware. S9 The short version, read from the machine on 15 October 2026:
| Part | What it has | What that means here |
|---|---|---|
| Machine | ThinkPad X1 Extreme Gen 2, Ubuntu 26.04 | One box, no cluster. |
| CPU | i9-9880H, 8 cores / 16 threads, AVX2 | Fine for indexing, search and a database; slow for big models. |
| RAM | 32 GB DDR4-2666, about 43 GB/s | Room for a CPU model up to about 20 GB while everything else keeps running. |
| GPU | GTX 1650 Max-Q, 4 GB, no tensor cores | One 3–4B model at 4-bit, or a small vision or embedding model beside it. |
| Disk | 1 TB NVMe, about 850 GB free | Not a constraint for notes, indexes or a few models. |
| Already installed | Ollama 0.40.1 (qwen3:4b, qwen3-vl:2b, qwen2.5vl:3b, moondream);
Claude Code 2.1.295; Codex CLI 0.162.1; Kimi CLI 2.1.1; Grafana and Loki | Three hosted agent harnesses and a local model server are already here. No Postgres, no Obsidian. |
One measurement to anchor the rest: qwen3:4b through Ollama on this laptop generated 27 tokens a
second (200-token answers, two runs, thinking off), with prompts read at about 780 tokens a second once loaded.
Ollama kept 15% of it on the CPU even at a 4,096-token context, which shows how tight 4 GB is.
Read as an architecture, the diagram has five layers, not three: where knowledge lives, how the right piece of it is found, a cheap local model for small jobs, a strong hosted model for hard ones, and the loop that ties them together. Following our own rules, each layer is judged on whether it's open, whether it runs here, and whether it can be swapped without losing data.
| Option | Open? | Runs here? | Strengths | Weaknesses |
|---|---|---|---|---|
| Plain markdown in git | Yes (it's just files) | Yes, nothing to run | Every agent we have already reads and writes it; diffable, backed up, portable forever. | No graph view or backlinks UI by itself. |
| Obsidian over that folder | No: proprietary, free including for work since Feb 2025 S10 | Yes, desktop app | Best reader: graph view, backlinks, web clipper, Dataview. Karpathy's choice. S1 | Closed source. But the vault is still plain markdown, so leaving costs nothing. |
| Logseq over that folder | Yes, AGPL S10 | Yes, desktop app | Open-source alternative with backlinks and a graph. | Outliner: every line is a bullet block, which is awkward for long LLM-written articles. |
| Postgres + pgvector | Yes (PostgreSQL licence) | Yes, not installed | Real queries, permissions, many writers; the right home once this becomes a multi-user app. | Notes stop being files you can read; a daemon to run and back up. Overkill for one person. |
Our pick: a plain markdown folder in git is the store, laid out the way Karpathy describes
(raw/ for sources nobody edits, wiki/ for pages the agent maintains, an index.md and
log.md, and an AGENTS.md as the schema). S1 Obsidian or Logseq is just a window
onto it, so the choice is a matter of taste and can change any day. Postgres comes later, as an index built from the
files, not as the place the knowledge lives.
The question is how an agent gets the five relevant pages out of five hundred without reading all of them. In rough order of effort:
| Option | How it works | Good up to | Runs here? |
|---|---|---|---|
| Index file + grep | The agent reads index.md, then rgs for names. Karpathy's approach: no embeddings, no vector database. S1 S11 |
About 100 long articles (around 400,000 words), the size Karpathy reports; practitioners see it strain near 200 files without per-folder indexes. S11 | Yes, today |
| SQLite full-text (FTS5) | A Ruby script rebuilds a BM25 keyword index from the folder on every commit. | Tens of thousands of pages; milliseconds per query. | Yes; one gem (sqlite3) |
| Local embeddings | A small embedding model in Ollama turns each chunk into a vector, stored with sqlite-vec or pgvector, for search by meaning.
embeddinggemma (300M, about 620 MB) or qwen3-embedding:0.6b (about 640 MB, 32K context, Apache 2.0). S12 |
Large collections where words don't match (synonyms, other languages). | Yes; fits on the GPU beside qwen3:4b |
| Postgres hybrid | Full-text and pgvector in one query, ranked together. | Many users and tenants (our rules require row-level security there). | Yes, needs Postgres |
| Off-the-shelf memory server | Basic Memory: an MCP server that keeps notes as markdown, works with Obsidian, adds search. AGPL. S13 | Getting started without writing code. | Yes (Python) |
Size is not a worry. A 400,000-word wiki is roughly 530,000 tokens; cut into 2,000 chunks with 1,024-number vectors at 4 bytes each, the whole vector index is about 8 MB.
Our pick: start with index + grep, which needs nothing new. Add the SQLite keyword index when the wiki passes about 100 pages, and embeddings only when keyword search visibly misses things. Expose whichever is current to every agent through one small MCP server, so Claude Code, Codex and Kimi all search the same way and the search backend can change behind it.
| Where | Models that fit | Speed here | Good for |
|---|---|---|---|
| GPU, 4 GB | 3–4B models at 4-bit: qwen3:4b (installed), Gemma 3 4B, Qwen3.5 4B; plus a 0.3–0.6B embedding model |
27 tok/s measured | Classifying, tagging, short summaries of new sources, routing, embeddings, anything private that shouldn't leave the box. |
| CPU, 32 GB RAM | Mixture-of-experts models that only touch a few billion weights per token, such as Qwen3 30B-A3B or gpt-oss-20b (roughly 13–19 GB at 4-bit) | not measured | Better local drafting and summarising overnight, when speed doesn't matter. |
| Doesn't fit | Dense 7–8B and up on the GPU; Kimi K2-class models (around a trillion weights) anywhere | These stay hosted. |
An estimate, labelled as one: CPU generation is limited by memory speed, about 43 GB/s here. A 3B-active model at 4-bit reads about 2 GB per token, so the ceiling is near 20 tokens a second and real speed will be well under that. Measure before relying on it.
Our pick: keep qwen3:4b on the GPU as the local workhorse for small, frequent,
private jobs, and add one embedding model when retrieval needs it. None of these replaces a hosted model for real
reasoning or coding.
This is the one layer that can't run on this laptop at a useful level. We already pay for three harnesses, each with its own provider, which is exactly the "at least two swappable providers" our rules ask for:
| Model, via | Role | Notes |
|---|---|---|
| Claude Opus 5.5, via Claude Code | Primary: hard reasoning, long code changes, maintaining the wiki | Strongest here; slowest and dearest per token, so don't spend it on chores. |
OpenAI models, via Codex CLI (codex exec) | Second opinion, review, fallback | A different model family catches different mistakes. |
Kimi, via Kimi CLI (kimi -p) | Third provider, cheaper bulk work | Kimi's model weights are published, so it is the one we could in principle self-host on bigger hardware later. |
Model names and prices change monthly, so this page doesn't quote either; the point is that the choice of model is a config setting, not something wired into the notes or the loop.
| Option | Open? | Fit for us |
|---|---|---|
| Claude Code as the loop (what we have) | No, but it reads our open files and speaks MCP | Already does plan, act, observe: tools, subagents, hooks, MCP, and AGENTS.md as the schema. It can call codex exec and kimi -p as tools for second opinions. Zero new software. |
| A small Ruby dispatcher | Ours | A queue of jobs (ingest this, lint the wiki, answer this) and one adapter per agent CLI and model API. Worth it once jobs run unattended on a timer. The RubyLLM gem covers the API side. |
| OpenCode | Yes, MIT | Open-source agent harness that talks to many providers, including Ollama. The best open fallback if a vendor CLI goes away. |
| Aider | Yes, Apache 2.0 | Git-native pair programmer, many providers. Code-focused rather than a general loop. |
| LangGraph | Yes, MIT | Graph-shaped agent workflows (see our graph engineering note). Python, so it breaks our Ruby-first rule without a clear reason. |
| n8n | Source-available, not open source | Visual workflow builder, self-hostable. Heavier than we need. |
| Jev as a decision step | No, hosted only | Could pick which agent gets a task, approve a tool call, or decide "done". Useful only at a volume where milliseconds and fractions of a cent matter; we're one person. An OpenJev-style clone on qwen3:4b would do the same locally. |
| Laya as a decision step | Yes, Apache 2.0 | An open decision model from Convai Innovations, released three days after Jev with the same choice, score and condition question types. It is a 421M-parameter encoder (ModernBERT-large, 512-token input) rather than a chat model, so it fits easily on our GPU or runs on the CPU; reported latency is tens of milliseconds. S14 S15 The local Jev we'd actually try. |
| Clef-flash / Clef | Open weights, Apache 2.0; training data not public | Cloudflare's decision models (9B and 27B, built on Qwen), API-compatible with Jev. Cloudflare puts local Clef-flash at about 41 GB of VRAM, so neither runs here. S16 |
Our pick: Claude Code stays the loop for interactive work. Routing decisions, when we need
them, go to Laya on this machine, behind an adapter that speaks Jev's question types, so Jev or Clef can be swapped in
if a measurement ever justified it. A qwen3:4b call returning a JSON choice is the fallback for decisions Laya handles badly. A Ruby dispatcher comes only when unattended jobs exist.
A proposal, in steps that each have a check. Section 7 revises this: our own website network can be the vault, so steps 1 and 3 change.
type, section 6) with raw/, wiki/, index.md, log.md and an
AGENTS.md describing ingest, query and lint. Check: drop in three sources, ask Claude Code to ingest them, and the wiki pages, index entry and log line appear in one commit.raw/ with qwen3:4b.
Check: on 20 hand-labelled items, the tags match well enough to be useful, and nothing is sent off the machine.observability/services.yml, and all three agents already send usage to the local collector. Check: tokens, cost and errors per provider show up in Grafana.If this setup saves time, it will show up in numbers we can collect ourselves: minutes from question to usable answer, tokens and money per task by provider, how often an answer cites the right wiki page, and how many hosted calls the local model takes off Opus. Take a baseline before step 1, measure again after step 5, and publish whatever comes out, including if it's nothing.
Added 15 October 2026, after reading the public comments under a repost of the diagram. Commenters are not named here.
The comments agreed with this page on the source: several said the diagram is not Karpathy's, that the 10× and 80% need real tests, and that "framework" is a big word for what many people already do. They also raised four useful technical points.
index.md and SQLite index would grow into. We'd still keep the knowledge itself in markdown, because people
read it too, and generate the JSON from it rather than the other way round. Tools like graphify already do this for code: they parse a
repository into a graph.json plus a readable report and serve it to agents over MCP. S17type is required) and explicit links between concepts, meant
for agents to read without a vector database. S18 That is nearly the vault in section 4, so we'd adopt its front matter from
the start and follow a published standard instead of our own.Two things we couldn't verify: a VS Code extension called "Pacify-x" that one commenter recommended (we found no public repository or listing), and the 155 ms p95 retrieval time another commenter reported for their own system.
Added 15 October 2026. This section changes the plan in section 4.
Looked at with Karpathy's three layers in mind, our own sites are already an LLM wiki, just one that's published.
About 30 pages across five domains, written by coding agents and checked by a person, served from
static_www/sites/ on this laptop:
| LLM wiki piece | What we already have |
|---|---|
| Raw sources | Cited links on every research page (the S-numbers), and facts read from the machine itself, such as the hardware page. |
| The wiki | The pages, split by audience: ruby.im for how we build and run software, jaycorp.us for research and the handoff, aol.pm for security, bada.im for adversarial research, michigan.im for the radio station. |
| Schema | AGENTS.md, published live on ruby.im, plus CLAUDE.md and the handoff README, which is written for AI systems picking up the work. |
index.md | Each site's home page, and a "More sites" footer the server adds to every page so all five sites link to each other. |
log.md | Each site's changelog, written by bin/changelog; ruby.im requires an entry for every change. |
| Lint | Missing. Nothing yet rereads old pages to find stale facts or broken links. |
The harness is Claude Code, Codex and Kimi, each reading AGENTS.md before it works. It does the planning and the acting. A decision model like Laya (or Jev, behind the same adapter) would sit between steps and answer small typed questions quickly and cheaply, each one logged so we can check it later:
It should never be the only guard on whether something is safe to publish. That check stays deterministic (pattern-based secret scanning) followed by a person's review.
We think it's the better design for us, with four conditions:
static_www is now a git repository, so every
page has full history alongside the changelogs.llms.txt (a proposed convention:
a markdown list of a site's pages for language models S19) and a JSON index of each page's title, description, date and links.
This is the "JSON map" from the comments, built from the pages rather than kept by hand.At our size, about 30 pages, an index plus grep is more than enough; Karpathy's approach works up to roughly 100 long articles. So this needs no vector database, no Obsidian and no new service. It needs git, two small Ruby scripts and one private site. Obsidian can still open a folder of exported markdown if anyone wants its graph view, but nothing would depend on it.
Provided as is, for information only, with no warranty and no liability. Not legal or professional advice. Security and radio material is for authorized, lawful use only. Full disclaimer.
Visits are logged on our own server: IP address, browser and device details, and pages viewed. We use them to understand traffic and spot attacks, and never share or sell them.