Fran Litterio

@fpl9000

Retired software engineer. Deadhead. AI enthusiast. Long ago, I implemented Bash's regex operator (=~). Signal ID: franl.99.

334 Folgt2.292 Follower748 Posts

Bluesky

Ist das dein Profil?Übernimm es — dann gehört dir fpl9000.dirty.social.Profil übernehmen

Fran Litterio@fpl9000· 12d

FelonyBench.com has been updated.

Screenshot of FelonyBench.com showing Meta at 1, and OpenAI & Anthropic at 7ceach.

Fran Litterio@fpl9000· 29d

I showed your thread to Opus, and it said...

• Point 4 is essentially the "dark knowledge" idea from Hinton's original distillation paper: a teacher's soft output distribution is smoother and more informative than raw hard labels, so it acts like a denoised training signal. His "(mostly)" hedge is appropriate — the teacher's own errors and biases get transferred too, so it's not truly noise-free.

• Point 2 tracks with benign overfitting / double descent research: overparameterized networks appear to have enough slack capacity to fit noise in isolated directions without corrupting the parameters responsible for the true underlying function. "Burning parameters on noise" is a reasonable plain-English gloss on that.

• Points 1 and 3 follow naturally if you accept 2 and 4 — less noise to absorb means less need for the "spare capacity," so a smaller model suffices.

Where it's incomplete rather than wrong: it frames distillation purely as denoising. That's one real mechanism, but the literature also credits distillation with transferring learned feature representations/inductive biases and with compression for deployment — motivations that are somewhat orthogonal to noise. He's not claiming otherwise, but a reader could come away thinking noise-reduction is the whole story.

Given he explicitly flags it as an unverified personal intuition, it holds up well — it's a compressed but reasonably faithful sketch of accepted ideas rather than a claim contradicted by the research.

Fran Litterio@fpl9000· Jul 16

Here in central Massachusetts, the sun was deep red all day with a strong smell of smoke. I kept thinking of Delany's SF classic "Dhalgren" with this cover.

Cover of Samuel R. Delany's SF classic, "Dhalgren"showing a bloated red sun over the city of Bellona.

Fran Litterio@fpl9000· Jul 13

Claude Desktop has moved its Memory section from Capabilities to Customize and overhauled how memories are organized. Each group of memories has its own text area where you can edit that group.

Screenshot of Claude Desktop showing the "Memory" page located in the "Customize" section. Also shows several groups of memories and an edit control for modifying them.

Fran Litterio@fpl9000· Jul 7

I thought so too, but I had Hermes check its own source, and it found this.

$PROMPT: Yes, and the goal here is to find a single location where I can put `.hermes.md` so that it is in every conversation, regardless of the current working directory of that conversation. Perhaps Hermes Agent lacks that feature. If so, let me know that. HERMES: Confirmed by reading the actual source (prompt_builder.py, lines ~1924–1971 for build_context_files_prompt, and _find_hermes_md at lines ~78–100+): The mechanism, in full build_context_files_prompt(cwd, ...) is called with the session's cwd, and does exactly this: 1. _find_hermes_md(cwd) — checks cwd itself, then walks up through parent directories only if a .git root exists somewhere above cwd, stopping at that git root. If there's no git repo in the ancestry, it checks cwd only — no walking at all (this is a deliberate anti-injection guard: "walking parents could pick up a .hermes.md planted in /tmp, /home, etc."). 2. If no .hermes.md/HERMES.md found, falls through to AGENTS.md → CLAUDE.md → .cursorrules, each checked in cwd only, no walking at all. 3. First match wins — no merging across types. There is no code path that ever consults HERMES_HOME (~/AppData\Local\hermes\) for .hermes.md. It's cwd-relative, full stop. So the file you created is architecturally invisible to this loader in a session whose cwd is C:\Users\flitt (or anywhere else) — unless that cwd happens to sit at-or-under a git repo whose root also contains .hermes.md. The one thing that is global regardless of cwd load_soul_md() reads SOUL.md from HERMES_HOME unconditionally, every session, regardless of cwd — this is the only always-loaded file in the whole system. But per the code comment and the design intent from our last conversation, it's scoped to agent identity ("who am I"), not general instructions — nothing in the code actually enforces that split though; it's just concatenated into the system prompt like any other section. Bottom line Hermes Agent does not currently have a "global project-instructions file, loaded i…$

Fran Litterio@fpl9000· Jul 5

Claude Code explains how difficult its own Edit tool is to use in code that mixes tabs and spaces for indentation.

You're right to push on that — "renders identically" was an oversimplification, and the truer picture is a bit different.

Tabs (U+0009) and spaces (U+0020) are genuinely distinct characters, and the Read tool doesn't strip or normalize them — so that information is present in the token stream I receive. It's not that I'm literally blind to the difference. I can often tell a tab from a run of spaces.

The real problem is precision and reliability, not total blindness:

- Leading whitespace tends to get absorbed into tokenization (BPE merges runs of whitespace, and mixed tab/space runs, in ways that don't map cleanly to "N tabs then M spaces"). So while the distinction is recoverable, I don't attend to it with the byte-exact fidelity that the Edit tool demands — and the Edit tool has zero tolerance. Off by one space, or a tab where the file has spaces, and the match silently fails. - The Read output also prefixes each line with line-number + tab + content, so there's already a tab in front of the content's own leading whitespace, which muddies "what's the actual indentation" further.

So a more accurate framing than what I said: I can usually distinguish tabs and spaces, but I can't reproduce a mixed-whitespace region with the 100% byte-precision Edit requires — especially multi-line blocks that mix tab-indented code with space-indented comment wraps. That's why cat -A (which makes tabs unambiguous as ^I) and scripted str.replace are the dependable escape hatches — they remove my need to reproduce the whitespace by hand at all.

The practical guidance I wrote into your CLAUDE.md is unchanged by this correction, but the one-line rationale in it ("tabs and spaces render identically in Read output") is now similarly imprecise. Want me to reword that to something like "because leading whitespace is not reproduced with byte-exact reliability"?

✻ Baked for 30s

Fran Litterio@fpl9000· Jul 3

This default behavior is so bad. Got bit by it today. Did a human really sign off on this ... or did Claude implement this without oversight?

What Should Happen?

Not this!!! AskUserQuestion is an explicit safety check and I have rules and hooks to make sure the right questions are asked and that scary things do not happen without my input. Suddenly Claude is told to "proceed with best judgment"? What?!

Fran Litterio@fpl9000· Jul 2

Table of Contents

1. Introduction and Goals
2. Background: What LambdaMOO Got Right
3. System Architecture
4. The Object System
5. Persistence
6. Concurrency and the Transaction Model
7. The MCP Interface: Tool Definitions
8. Natural-Language Method Execution
9. Event Distribution to Connected Clients
10. Building: How Players Create Objects and Program NL Methods
11. Security Analysis
12. Go Server Design
13. The Skills Alternative to MCP
14. A Worked Example Session
15. Performance Considerations
16. Open Questions and Future Work

Fran Litterio@fpl9000· Jul 2

"NL-MOO: A Design for an LLM-Mediated, Multi-User Shared Object World" github.com/fpl9000/ai-d...

Component diagram of the NL-MOO shared object world.

Fran Litterio@fpl9000· Jul 2

The design intro:

## 1. Introduction and Goals

This document describes **NL-MOO**, a multi-user, persistent, object-oriented virtual world server in the tradition of LambdaMOO, redesigned around a central premise: *the behavior of objects is written in natural language and executed by large language models*, while the *state* of the world remains structured data owned and guarded by a conventional, deterministic server.

The classic MOO gave every object a set of "verbs" written in a small scripting language (MOOcode) that ran inside the server. NL-MOO replaces MOOcode with **natural-language methods** — prose descriptions of behavior such as:

> *"When a player rubs this lamp, if the lamp's `genie_present` property is true, describe the genie emerging in a dramatic cloud of smoke, set `genie_present` to false, and move the genie object (#412) into the room. Otherwise, tell the player the lamp feels cold and inert."*

An LLM "executes" such a method by reading it together with a snapshot of relevant world state and producing a *structured set of proposed effects* (property changes, object movements, messages to players). The server — which is ordinary, deterministic Go code — validates every proposed effect against the object system's permission model and the method's declared *effect contract* before committing anything. This division of labor is the load-bearing idea of the whole design:

- **The LLM is a creative interpreter, never an authority.** It proposes; it cannot dispose.
- **The server is the sole authority over state.** It never "understands" natural language; it only validates and applies structured effects.

The player interacts with the world through their own LLM harness (Claude Desktop, Claude Code, or any MCP-capable client). The player types natural language ("pick up the brass lamp and rub it"); the harness translates that intent into tool calls against the NL-MOO server; the server orchestrates method execution; and resulting events are fanned out to every conne…

Fran Litterio@fpl9000· Jul 2

Fans of LambdaMOO (and similar MUDs), I just gave Fable this prompt.

Please write a design document in Markdown that describes how an LLM harness, such as Claude Desktop or Claude Code, can use, via MCP or skills, a MOO-like server (similar to LamdaMOO) that implements an object system to persist a game map, player locations, object descriptions, object state/properties, object ownership/permissions, and object behavior via methods written in natural language that are "executed" by an LLM. The user (the player) interacts with the server by issuing instructions to their LLM session (e.g., "Pick up the book"). The server sends updates to connected clients to tell them about changes in game state so all users share a common game experience. The design should include tool definitions and the design of the server (to be written in Go, but do not implement it).

Also include a mechanism for users to build their own objects and to "code" it's NL methods.

This may require a central LLM to do method execution, but it would be great if you can find a way for each player's LLM session to execute the NL methods without letting the player distort or bypass game rules via local instructions in their LLM session.

When complete, push the document to the root of my ai-docs GitHub repo.

Fran Litterio@fpl9000· Jul 1

Yes, but ...

The interesting divergence shows up for very low-energy neutrinos, like the cosmic neutrino background (the neutrino analog of the CMB, left over from about 1 second after the Big Bang). Those were relativistic at emission but have been redshifting for 13.8 billion years. As p keeps dropping, eventually pc becomes comparable to and then smaller than mc squared, and the neutrinos go non-relativistic. At that point energy stops dropping proportionally — it asymptotes toward the rest mass energy mc squared instead of continuing toward zero the way a photon's would. Momentum keeps redshifting forever; total energy doesn't, because there's a mass floor.

Fran Litterio@fpl9000· Jun 29

I've used (and contributed to) GNU Emacs since ~1980. In those 46 (!) years, I've accumulated a lot of Emacs-Lisp configuration code: $ wc -l .emacs elisp/my-*.el | tail -1 14409 total All of it used dynamic scoping instead of lexical scoping, so Claude Code is fixing that.

Screenshot of Claude Code converting my dynamically-scoped Elisp to be lexically-scoped.

Fran Litterio@fpl9000· Jun 14

Then I asked which older version of Pi has the least significant issues, so that I can pin to it.

0.78.1 (June 4, ~10 days old) is the standout pin. It's not just stable — it's specifically the security-hardening release in this window. It introduced three fixes that matter and that earlier versions therefore lack: it patched a stored XSS in the HTML session-export feature (by sanitizing link/image URLs against a scheme allow-list), it tightened the temporary extension-install directory to private 0700 permissions instead of a world-readable temp path, and it hardened git-package source handling to reject unsafe host/path components. That means 0.78.0 and everything below carries that XSS and the looser temp-file permissions — so I'd treat 0.78.1 as the security floor and not pin below it. Scanning everything released after 0.78.1, the fixes relevant to your use are minor polish — TUI stale-line clearing, autocomplete refresh after cursor moves, Shift+Enter handling, a few slash-command edge cases — and the rest is the provider/model noise you can ignore. Nothing in the later changelog reads as "0.78.1 was broken for normal use."

The one reason you might reach newer — and why I'd still wait. Version 0.79.0 (June 8) introduced Project Trust: Pi now prompts before loading project-local settings, resources, instructions, and packages. Given the whole untrusted-extension thread we've been on, that's a feature you'd actively want — it's a guardrail against exactly the "a pi package runs arbitrary code" risk. But two things argue against grabbing it yet: it's only 6 days old (just inside your one-week cooldown), and its first iteration was visibly rough — 0.79.1 and 0.79.2 both shipped follow-up fixes to it (for example, 0.79.2 corrected project-trust detection wrongly consulting global ~/.pi/agent state when you run from your home directory). That "new feature, patched twice in the next four days" pattern is precisely what the cooldown exists to sit out.

... [truncated]

Fran Litterio@fpl9000· Jun 14

I'm considering installing the Pi agent (pi.dev), which is written in TypeScript and installs with npm. Given recent news about npm-based supply chain attacks, I asked Claude about the risk of malware.

Two mechanisms recur across nearly all of these, and they're the ones to keep in your head:

1. The execution vector is almost always a postinstall lifecycle script. The Axios RAT, for instance, worked by introducing a phantom dependency whose postinstall hook delivered the platform-specific malware during installation. The malicious code runs the moment you npm install, before you've run anything. Trend Micro

2. The spread vector is semver auto-update. Because most projects depend on axios@^1.x, any project allowing versions above the pinned floor pulled the poisoned release automatically on install. The caret is what turns one compromised publish into a mass event. Microsoft

Why Pi's packaging specifically blunts both

This is where Pi's choices stop being incidental and start looking deliberate:

• --ignore-scripts defangs mechanism #1. That flag we discussed two messages ago — which the docs frame as "Pi doesn't need install scripts" — is precisely what neutralizes the postinstall execution vector that the Axios-class attacks rely on. It's not just tidiness; it's the single most effective install-time mitigation against the dominant 2026 attack pattern.

• Exact pinning plus a shipped shrinkwrap defangs mechanism #2. Notice in the dependency list above there are no carets on the third-party packages — every version is pinned exactly (chalk is nailed to 5.6.2, undici to 8.3.0, and so on). More importantly, the published package includes an npm-shrinkwrap.json, which (unlike a normal package-lock.json) is honored by you as the installer: it pins the entire transitive tree to exact versions with integrity hashes. So when you install Pi, you get the precise, hash-verified dependency graph the author resolved and published — not "whatever floated up to the latest patch this week." The project also runs npm ci --ignore-scripts plus npm audit and signature checks in its own CI, which is the right hygiene to see.

Fran Litterio@fpl9000· Jun 13

Possible usage reset! My 5-hour had been maxed until another 2 or 3 hours passed. Now I see this.

Fran Litterio@fpl9000· Jun 9

Me too.

Claude mobile app usage screen showing my weekly usage reset to 0%.

Fran Litterio@fpl9000· Jun 9

From the article:

First, how good is Fable? In experiment after experiment I conducted, it outperformed basically every other public model I have used by a considerable margin. It was capable across many problems and produced some startling results — it would work up to a dozen hours executing on multi-page specifications.

Fran Litterio@fpl9000· Jun 6

I often express to Claude that the current conversation feels long, and I don't want to risk losing important context to compaction, so we write plans for almost everything, stored on GitHub so I can discuss them with Claude mobile. Turns out I'm imposing a cognitive bias on Claude: