Yigit Yildiz.

I released loci v0.6.0 on 10 September. The tokenizer, the file walk, the index build, BM25, the char n-gram matrix and the score fusion all moved behind a compiled Rust extension. The base install is now numpy and nothing else. A one-shot loci ask against a single scope went from 5.19s to 0.97s. That is not the number I care about. This one is: A 39-question benchmark recorded against 0.5.0, capturing every routing verdict, scope set, hit ordering and score, replays 39 out of 39 identical against 0.6.0. The eval harness output is byte for byte the same. A rewrite that changes the answers is not a port. It is a different tool wearing the old version number, and you find that out from a bad answer six weeks later. Why touch it at all: loci routes a question to one project, then searches inside that project only. Everything about that design assumes you will ask it things constantly, in the middle of doing something else. Delroy, my agent harness, shells out to loci ask --json mid conversation. Five seconds per question is a tool you stop reaching for. Here is where the five seconds went, measured before I wrote a line of Rust:   0.5.0 0.6.0 loci ask, one scope 5.19s 0.97s ranker load, largest scope 935ms 0.033ms tokenizer, 91k chars 14.6ms 4.4ms file walk, 15 scopes 46.2ms 20.8ms index build 14.4s 9.1s Two of those five are not Rust: I want to say this before anyone quotes the first row at me. The 5.19s included torch loading bge-small. 6.2 seconds of a 7.77 second query, on the run I profiled, was the encoder booting. That is onnxruntime now, loading the ONNX graph BAAI publishes directly. No Rust involved. The deeper reason was not speed anyway: ask fans out across scopes in a thread pool, every thread reached torch, and after three locks closed a diagnosed deadlock, Delroy still measured a segfault. The class of bug was never the check-then-act race. It was native threading, and removing the native threading removed it. The 935ms was joblib.load on 35MB of pickled scipy, paid on every one-shot invocation that touched that scope. The replacement is a file format rather than a language. rankers/<scope>.lex stores the fitted BM25 and char-gram models with sorted string tables that get binary searched where they lie, and CSR columns renumbered into sorted order so a column id is its own position. Opening it is a page fault instead of a deserialization. I would have got most of that win writing the format in Python. Rust earned the tokenizer, the walk, the index build and the fusion. It did not earn the headline. If you take one thing from this post and you are staring at your own slow Python, it is that the profiler tells you which of those two situations you are in, and the answer is very often a pickle or a model load rather than the arithmetic everyone wants to rewrite. What stayed in Python, deliberately: router.py did not move. Neither did any of the fourteen calibrated constants. The constants cross the boundary as function arguments rather than living in the Rust, because evals/ sweeps them and a sweep must not need a cargo build. search() takes its four fusion weights, its length saturation, its score floor and its three gate parameters as plain floats every call. Recency is precomputed on the Python side too, so $LOCI_NOW still works and no date parsing happens in the extension. The whole thing is a Python package with one compiled module inside it, not a Rust package with Python bolted on. About 2,000 lines across two crates, loci-core holding the logic and loci-py holding the pyo3 surface. The fusion releases the GIL for its duration. Holding it would serialise exactly the work the thread pool exists to overlap. The one thing I could not port: TfidfVectorizer(max_features=60000) keeps the 60,000 most frequent character n-grams. I went to reproduce that and found there was nothing to reproduce. The cut lands where corpus counts are 1 to 5, and tens of thousands of n-grams share those counts. sklearn breaks the tie with (-tfs[mask]).argsort(), and numpy’s default sort is not stable. Which n-grams survived was decided by sort internals. On a real corpus: 24,281 of one scope’s 68,418 n-grams tied at a count of 1. Roughly 26% of that scope’s retained vocabulary was arbitrary. You cannot write a specification against that. Breaking the tie deterministically instead, which is the obvious move, shifted char-gram scores by up to 2.6e-02 and reordered the top 5 for 15 of the 39 benchmark questions. So I removed the cap. The terms it was discarding were singletons, which add columns to the matrix and almost no non-zero entries: measured at +5% matrix bytes, with no change in fit time or query time. Verified on one fixed index: routing identical, retrieval identical, 45 of 45 evidence chunks returned, the justifying file first for 29 of 44 and in the top 3 for 36 of 44. That is the only deliberate behaviour change in the release, and it exists because the old behaviour had no definition, not because I found something better. How I knew nothing moved: Before touching anything, I recorded what 0.5.0 answered. parity/record.py invokes the CLI as a subprocess rather than importing loci. That is on purpose. The CLI and the MCP server are the only two surfaces the port had to preserve, Delroy never imports loci, and an oracle should grade the surface rather than the internals behind it. A non-zero exit gets recorded rather than raised, because “0.5.0 fails this way” is part of the contract. parity/check.py diffs the replay under two policies: Exact for the decision. Verdict, scope set, ordering, mode, reasons. A routing answer is a choice, and a choice is either the same choice or a regression. Ordering counts, because an agent reads the first hit. 1e-6 for the score. Floating point reassociates when the code computing it changes, and a difference in the seventh decimal is noise. A difference big enough to move an ordering shows up under the exact policy instead. Presentation fields are ignored by suffix, so dropping torch’s progress bar off stderr does not read as a regression. The failure that file exists to prevent is a comparator that passes everything, which would report a clean port that is not one and let every later phase build on the report. 404 tests pass. scikit-learn, rank-bm25 and joblib are still dev dependencies, kept as the reference the parity tests compare against. Deleting the old implementation would delete the proof. Same reason sentence-transformers stays: tests/test_embed.py checks the ONNX encoder against it, and the nine floors in calibration.json were fitted to torch weights. Which is also why the encoder does not use the model_O1 through model_O4 or the quantised variants sitting in the same repo. An optimised graph drifts from the weights the floors were fitted against, and that is the one thing this module may not do. What shipping it found: The tradition continues. Five commits landed within hours of the tag, and four of them would have reached a user. A base install with vectors on disk crashed. The semantic tier is an optional extra, but a data directory that already has embeddings loads them with numpy and then dies importing the provider. ModuleNotFoundError: No module named 'onnxruntime', exit 1, no answer. 0.5.0 had the identical crash one import earlier, on sentence_transformers, and survived only because nobody had run a base install against a store built with the extras. Vectors without an encoder now degrade to lexical search, and loci doctor names the missing package. Separating the reference tests by pytest marker does not work. importorskip runs at collection, so deselecting by marker still imports scikit-learn into the process. They needed their own file and their own run. The sdist did not contain the LICENSE that the package metadata had been claiming since 0.1.0. The walk parity test was comparing the wrong two things. File contents belong against the Rust, ordering belongs against the Python shim, and one test asserting both against one side proves less than it looks like. Upgrading: A reindex is required. The lexical rankers changed format and one ranking constant is gone, so an older install keeps working but gets slower and answers slightly differently until it rebuilds. pipx upgrade loci-mem loci index --force # writes rankers/<scope>.lex; the old .joblib is ignored loci doctor now says so rather than leaving you to find out. A scope with no usable .lex refits in process on every single question, about 1.5s per scope per invocation, against 0.03ms for a cached one. INDEX_VERSION stays at 3. Nothing about what a token is changed, and text.rules_signature() returns exactly what it did in 0.5.0. The old rankers/*.joblib files are dead once you reindex and can be deleted. Wheels ship for macOS, Linux and Windows, abi3 for Python 3.10 and up. Building from the sdist needs a Rust toolchain, 1.75 or newer. pipx install 'loci-mem[all]' loci setup loci ask "why was the session cookie dropped on localhost?" What has not improved: The limits from the v0.2.0 post are still the limits, and a faster implementation of the same router does not touch any of them. Every constant was fitted against repositories belonging to one person. Me. The parity work proves 0.6.0 agrees with 0.5.0, which is a statement about a rewrite and says nothing about whether 0.5.0 was right. A question derived from a code body still routes at roughly half the rate of one derived from indexed prose. A large prose-heavy project still over-attracts. So the ask is unchanged, and the run is now under a second: loci eval It asks only questions whose correct answer is known by construction, so it needs no labelling and no setup. Tell me what it says about your projects rather than mine. Check out the loci Repository Check out the PyPI Package

I released loci v0.2.0 today. It is on PyPI as loci-mem and listed in the MCP registry, so an agent can reach it over stdio without me writing a client. It is a memory tool for coding agents, and the thing that makes it different is small enough to state in one sentence: it decides which project your question belongs to before it searches anything. The problem: Every memory tool I had used, including the one I wrote before this, does the same thing. You point it at your code, it builds one index, and every question searches all of it. That works until you have more than one project. Then the largest project wins, regardless of what you asked. I measured this against a merged graph of ten of my own repositories. Same questions, one index: question on-topic nodes returned why was the admin session cookie dropped on localhost? 18% (19 of 31 came from the biggest project) what happens when a user clicks Save as ZIM? 2% (61 of 62 came from the biggest project) how does the reserved landing step work? 98% The third row is the one worth staring at. It scored 98% because the biggest project genuinely was the answer that time. Merged retrieval looks excellent whenever the answer happens to live in the largest corpus, and collapses when it does not. Same failure in both directions, visible in only one, which is the worst property a bug can have. Knowledge graphs hold structure but no prose, so they cannot answer why did the cookie get dropped. Verbatim recall systems hold prose but no call graphs, so they cannot answer what calls run_agent_turn. And both of them make you name the namespace when you write. loci decides the scope when you read. What it actually is: A router in front of two stores. The structure store holds what calls what: symbols, files, references, with file:line citations. The episode store holds what happened and why: READMEs, docs, git commit bodies, docstrings and comment blocks, stored verbatim and redacted before they are written. The router decides which projects a question belongs to. There is no model call in the query path. It is a dict lookup per query token against a token to scope map, which is sub-millisecond and stays flat from 25 projects to 100. Signals, in order of weight: an explicit project name, your working directory, vocabulary evidence, and recency as a tiebreak. Weight is not usefulness. Your working directory is the signal that carries most real questions, because most real questions never name a project at all. Refusing is a feature: The part I am most attached to is that ABSTAIN is a first-class outcome, at both layers. The router can decline to pick a project, and a project it did pick can still hand back nothing. Ask any RAG tool what the airspeed velocity of an unladen swallow is and it will confidently retrieve something. loci says it does not know. Getting there took an actual finding. Questions like “how is this deployed?” or “how do I run the tests?” point at their subject without ever naming it. Before I fixed this, loci abstained on those only 37.5% of the time, which means 56% were confident and wrong. From the outside that is indistinguishable from correct. No lexical statistic rescues it. I checked: per-token evidence for start (2.51) and services (2.56) is indistinguishable from real evidence like session (2.53). The individual words are not generic. The question is. Pointing at your subject is a grammatical property, so I detect it grammatically. A closed class of markers, no tuned threshold. That moved abstention from 37.5% to 87.5% across 80 generated questions, with in-project routing unchanged at 100%. The two bugs v0.2.0 found: This release exists because someone reviewed the tool and asked it a question I had not. Enumerative questions returned one owner of two: loci ask "which of my projects use Cloudflare workers or D1?" -> 3M1RY33T.github.io It dropped urthreads, which is the Cloudflare Worker. Every gate in the router asks the same thing: is there enough evidence for one project? A question about something several projects share splits its evidence across all of them by construction. So the more projects genuinely shared a term, the less likely all of them came back. The mechanism inverted on exactly the question shape that wants a set. Worse, the quickstart example in my own README, which projects use wrangler and D1?, returned both owners only by luck. wrangler happens to live in exactly two projects, which tripped a different code path. The fix follows the same rule as the deixis one. Enumeration is grammatical, so detect it grammatically: a closed class of markers, no threshold, switching selection from “within 0.85 of the top project” to “every project that clears the floor on its own”. The frame nouns (projects, repos) get stripped from the query, because they are scaffolding rather than vocabulary.   before after confusable top-1 50.0% 100.0% confusable gold-coverage 41.7% 66.7% cross gold-coverage 66.7% 83.3% negative (abstains correctly) 66.7% 88.9% The tokenizer was deleting D1: Then, testing that fix, I found the real problem. The tokenizer used [^\W\d_]+, which treats every digit as a separator and throws it away. So D1 became d, and d died on the minimum length floor. Across 53 markdown files in three repositories: 258 distinct alphanumeric terms deleted outright, over 1,246 occurrences. s3 (102 times), n8n (70), d1 (64). Plus base64 collapsing to base and sha256 to sha. d1 appears in this project’s README as a routing example. It could never have worked. It also silently killed aliases. A project named 3M1RY33T tokenized its only alias to an empty list, so the strongest signal in the entire router could never fire for it. Naming that project outright made loci abstain. The new tokenizer emits a superset, so nothing that matched before can stop matching: base64 now yields both base64 and base. And the reason I nearly missed it: I shipped the tokenizer fix and loci index cheerfully reported 12 of 14 projects “unchanged, reused without re-parsing”. The fingerprint is a content signature, and no file had changed. The routing index and the tokenizer now disagreed about what a word is, and nothing said so. The fingerprint is now seeded with a signature of the tokenizing rules, so any future change to them invalidates the cache by construction instead of when I remember to bump a constant. Something I got wrong: While fixing the enumerative case, folding singular and plural at query time looked obviously correct. urthreads holds worker 158 times and workers twice, so a question asking about “workers” should clearly match “worker”. I measured it. It was worse: behavior gold-coverage dropped from 42.9% to 28.6%, and correct negatives from 66.7% to 55.6%. It is recorded as rejected in the changelog rather than quietly dropped, because “obviously right” is exactly the kind of thing that needs a number attached to it. What it cannot do yet: I would rather say this myself than have someone find it. Every constant in the router was fitted against ten repositories belonging to one person. Me. The architecture came from mechanisms and should generalise. The numbers came from one machine and demonstrably do not. Uncontaminated top-1 is 85.7%, which is 6 items out of 7. A single item moves that 14 points. The structure store surfaces the answering symbol in 4 of 7 probes. That is a real miss, not a rounding error. Large prose-heavy projects over-attract. One of mine absorbs questions belonging elsewhere purely by having more words. CI runs on Linux, Windows and macOS across Python 3.10 to 3.13, and standing that up found a Windows bug that reading the code had walked straight past. But no user has actually run loci on Windows yet. Try it: pipx install 'loci-mem[all]' loci setup loci ask "why was the session cookie dropped on localhost?" setup scans, graphs, indexes, embeds and calibrates in one pass, then runs doctor so whatever it could not cover is the last thing you read rather than something you discover from a bad answer a week later. Everything stays on your machine. No LLM in the query path, embeddings run locally when you enable them, and everything collected is redacted before it is written. There is one thing I actually want, and it is not stars: loci eval It asks only questions whose correct answer is known by construction, so it needs no labelling and no setup, and it takes a few seconds. Then tell me what it says about your projects, not mine. Every number in this post was measured by the same person who wrote the router, and that is a limit no amount of additional self-testing can fix. Check out the loci Repository Check out the PyPI Package

I released urthreads v1.2.0 today. The npm page is live, the GitHub release is tagged, and the package is already running on this site. But this one feels different from the earlier releases, and I want to talk about why. What Changed: v1.2.0 fixes the local admin development experience. Until now, wrangler dev alone could not drive the admin dashboard. Two root causes blocked it, and both were the kind of thing where you spend an hour convinced you’re doing something wrong before you realize the code is fighting you. The first: browsers silently drop Secure cookies over plain HTTP. The worker always emitted __Host-urthreads_admin_session with the Secure attribute, so the session cookie set by POST /admin/session on http://localhost:8787 never stuck. You’d log in, get a 200, and then the next request would show unauthenticated because the cookie vanished. I proved the fix works end to end with curl in a previous session, but the fix itself kept getting reverted. The second was worse. getAdminKeyAccess checks isAdminKeyExpired before comparing the key, and verifyAdminSessionToken re-checks key expiry on every request. The expiry value sits in .dev.vars, written by the admin-key CLI. A stale or past ADMIN_API_KEY_EXPIRES_AT makes even the correct key return admin_key_expired, and the dashboard tells you to “deploy again,” which is wrong advice for a local worker. You’d paste the right key, get rejected, and the UI would point you at a deploy you don’t need. v1.2.0 fixes both, and adds the tooling around them so the whole local workflow is one command. Localhost-aware session cookies: http://localhost, http://127.0.0.1, and http://[::1] now get a plain urthreads_admin_session cookie without Secure. Everything else gets the byte-identical __Host-urthreads_admin_session with Secure. The cookie logic detects the origin on every request, so production behavior is untouched. HttpOnly, Path=/, Max-Age, and SameSite stay the same in both paths. No more local key expiry footgun: The new setup:dev script always writes ADMIN_API_KEY_EXPIRES_AT= (empty) to .dev.vars. Empty means never-expires per isAdminKeyExpired, so the local worker can never reject the correct key as expired due to a stale env value. The dashboard also got a localhost-aware error message: instead of telling you to deploy again, it says to run npm run setup:dev and restart npm run dev. Production semantics are unchanged. Unparseable or past dates still fail closed. Key rotation still kills sessions. The fix is strictly local. One-command local setup: npm install npm run setup:dev npm run dev That’s the complete local admin testing workflow now. No Cloudflare account, no CLOUDFLARE_API_TOKEN, no manual secret or schema management. setup:dev reads the D1 database name from wrangler.toml, reuses an existing admin key or generates one, writes .dev.vars with empty expiry, initializes the local D1 schema, prints the key, and copies it to your clipboard. Wrangler is now a devDependency, so npm install alone gives you a runnable dev environment. The admin-key CLI also picked up a local-dev hint in its next-steps output, pointing you at npm run setup:dev instead of the Cloudflare secret flow. Why This Release Matters to Me: I shipped every previous urthreads release by hand. I’d open the repo, make changes, run tests, bump the version, write the release notes, publish to npm, and tag the commit. This is the first one where I handed the keyboard to Delroy. If you read the release notes on GitHub, you’ll notice they don’t read like typical changelog prose. They read like a plan. That’s because they are. Delroy wrote that plan. It diagnosed both root causes from the codebase, drafted the implementation in four phases, identified every file and line number it needed to touch, specified the security constraints (dev-only behavior gated so it cannot leak into production), and then executed it. I reviewed the diff, we fixed the .dev.vars normalization that the previous attempt got wrong, and I published. I’m not going to pretend this was a hands-off experience. I was in the conversation the whole time. I caught a stale expiry path that would have reintroduced the exact bug we were fixing. I made the call to add wrangler as a devDependency so npm install would be enough. But the diagnostic work, the test coverage, the security gating, the dashboard message logic, the setup script itself, the package.json wiring, Delroy did that. I directed and verified. That’s the division of labor I’ve been building toward. This is the first real deployment I made with my own AI agent. Not a demo. Not a proof of concept. A versioned package on npm, running in production on this site, with tests passing and security constraints intact. That’s the milestone. What Comes Next: The README already lists what’s planned: optional MFA in front of the dashboard, widget-style stats, comment approval settings, broader integration tests. I want to keep using Delroy for these. The local dev environment we just built is what makes that practical. Before v1.2.0, testing the admin dashboard locally meant fighting the cookie and the key expiry every time. Now it’s three commands. If you’re running urthreads on your own site, npm install -g urthreads@latest gets you v1.2.0. If you’re developing against it, npm install && npm run setup:dev && npm run dev gets you a working local admin dashboard in under a minute. Check out the urthreads Repository Check out the npm Package