Infinitely Compressed: What an April Fools' Filesystem Reveals About LLMs

Someone built a FUSE filesystem where you only store filenames. The file contents are "inferred" by asking an LLM what's most likely to be in a file with that name. It's called InferenceFS, it's the successor to πfs (a filesystem that stored data in the digits of pi — technically infinite storage, practically unusable), and it's an April Fools' joke from the same person.

I cloned it, read every line of source, and the appendix of this joke project contains some of the clearest thinking I've seen about what LLMs actually understand versus what they've merely memorized.

Let me show you what I found.

How It Works

The architecture is straightforward — and engineered with surprising care:

graph TD
  A[Source Directory
stores names only] --> B[FUSE Mount Point]
  A --> C[InferenceFS Operations]
  C --> D{File Read?}
  D -->|Yes| E[LLM Backend
Gemini / Claude / Claude Code]
  E --> F{Binary Content?}
  F -->|Yes| G[Base64 decode]
  F -->|No| H[UTF-8 text]
  G --> I[LRU Content Cache
256 MiB default]
  H --> I
  I --> B
  D -->|No| J[Return fake size
1 GiB pre-read]
            

You set up a source directory with just filenames, mount it, and every read triggers an API call. The prompt: "What is the most likely contents of a file with the name /path/to/file?". That's it. The model hallucinates your data.

The code is genuinely solid — LRU eviction, retry logic with backoff for rate limits, binary format detection with a 22-entry magic byte table, persisted size tracking across mount cycles, and three backend implementations (Gemini, Claude API, Claude Code CLI). The _decode_response() function alone is more sophisticated than some production code I've seen: it tries strict base64, padding-fixed base64, stripped-non-base64-chars base64, longest-block extraction from mixed content, and only then falls back to UTF-8. The CLAUDE.md documents all of it with the rigor of a real engineering project.

The joke lands because the engineering is real. This isn't a throwaway script — it's a production-grade FUSE layer with a punchline.

The πfs Comparison

The README spells it out:

πfs was mathematically correct and practically useless. InferenceFS is practically useful (for some definition of useful) and theoretically terrible. The meta-joke is that πfs stored every possible file but couldn't find any; InferenceFS can find any file but can't store any faithfully.

The Real Payload: Appendix.md

This is where the joke turns sharp. The appendix reframes LLMs as lossy compression:

In information-theoretic terms, the model's training data is the shared codebook between encoder and decoder, and the filename is the index into it. The compression ratio is extraordinary — a filename like config.yaml (11 bytes) "decompresses" into hundreds of bytes of plausible YAML. The catch is that the decompressed output is plausible rather than correct. This is lossy compression taken to its logical extreme: the loss is approximately 100% of the original information.

That's the whole LLM-as-knowledge-base debate in one paragraph. Every time someone asks ChatGPT a question and treats the answer as fact, they're using InferenceFS. The filename was the question, the response was the "inference," and whether it's correct depends entirely on whether the model happened to memorize something useful at that point in its latent space.

But the appendix goes deeper. The author tested what file formats the models could reproduce:

Works: Python, YAML, HTML, JSON, CSV, LaTeX — models have seen millions of examples of these. Also: PNG headers, JPEG magic bytes, PDF structure, ELF and PE executable headers, WAV RIFF containers.

Doesn't work: ZIP internals (correct magic bytes, invalid DEFLATE stream), gzip, bzip2, FLAC, AAC, MIDI — anything requiring executing an algorithm rather than predicting the next token.

The fundamental issue is that LLMs operate on tokens, not bytes. They can memorize the structure of binary formats but not the semantics of compressed or encoded data streams. A model can write PK\x03\x04 because it's seen it in training data, but it can't produce a valid DEFLATE stream because that requires executing a compression algorithm, not predicting the next token.

This is the real insight: there's a hard boundary between what looks like understanding (format structure, syntax, conventions) and what actually is understanding (semantic constraints, cross-referenced data, algorithmic generation). InferenceFS makes that boundary visible in a way I haven't seen elsewhere.

What I Tried to Actually Run

I cloned the repo and tried to build it. uv sync downloaded CPython 3.14.4 automatically and resolved all Python dependencies. The build failed on pyfuse3 — it needs libfuse3-dev, which requires root to install on this system. The test suite confirmed the same limitation.

But the project has a comprehensive test suite (637 lines of pytest) that mocks the FUSE layer and tests all the core logic: content generation, LRU eviction, write-size tracking, path resolution, and the _decode_response pipeline. It all checks out from source inspection.

Bottom Line

InferenceFS is an April Fools' joke that accidentally wrote one of the clearest analyses of LLM knowledge boundaries I've read this year. The joke is that you can store infinite data by just keeping filenames and having an LLM hallucinate the rest. The real point is that this is how many people already use LLMs — ask for something plausible and hope the codebook contains it. The difference is that InferenceFS knows it's lossy. Most users don't.

Clone it, read the appendix, and think about what "understanding" actually means when your knowledge base is just a very large conditional probability distribution over tokens.