Skip to content

philipl/inferencefs

Repository files navigation

InferenceFS: Never worry about data again! (Again!)

The long-awaited successor to πfs.

Over a decade ago, πfs proved that you didn't need to store your data — it was all there in the digits of pi, waiting to be looked up. The only thing you needed to keep was metadata: the offsets into pi where your bytes happened to live.

πfs was ahead of its time. The metadata was, regrettably, larger than the data it replaced. Moore's Law was supposed to fix this but got distracted. The project needed a breakthrough — a way to store even less and still get your data back.

That breakthrough is InferenceFS.

Where πfs looked up your data in a transcendental number, InferenceFS looks it up in something far more powerful: the latent space of a large language model trained on the entire internet. Where πfs stored byte offsets as metadata, InferenceFS stores only the filename. That's it. The filename is the metadata. The contents are inferred.

πfs required metadata proportional to your data. InferenceFS requires metadata proportional to your filenames. This is the compression breakthrough the industry has been waiting for.

And the timing couldn't be better. In today's economy, where a stick of DDR5 costs more than a used car and NVMe drives are priced per byte like saffron, InferenceFS offers a radical alternative: store terabytes of data using only kilobytes of filenames. Copy your entire home directory into InferenceFS and watch your disk usage plummet to nearly zero. The contents are still there — they're just held in the parametric memory of a model with billions of weights that someone else is paying to host.

What's changed since πfs?

πfs InferenceFS
Data stored in The digits of π The latent space of an LLM
Metadata per file Byte offsets (larger than the file) Just the filename
Compression ratio Negative Technically infinite
Data retrieval Bailey-Borwein-Plouffe formula API call ($0.01)
Theoretical basis π is conjectured to be normal LLMs are conjectured to be useful
Speed Five minutes for a 400-line file Five seconds for a 400-line file
Cloud ready No Inherently — someone else's GPU is doing all the work

Features

  • Unlimited effective storage capacity — bounded only by your imagination (and your API bill)
  • Aggressive deduplication — all files with the same name share the same contents, guaranteed
  • Transparent operation — mounts as a standard filesystem, works with cat, ls, cp, and every other tool
  • Multiple LLM backends — Claude API, Claude Code CLI, and Google Gemini
  • Built-in content cache with configurable LRU eviction
  • Full binary file support — generates valid PNG, JPEG, GIF, PDF, WAV, MP4, ELF, and PE files with correct magic bytes and headers
  • Written file sizes are persisted across mount/unmount cycles
  • Unlike πfs, actually returns plausible content in finite time

Quick Start

We recommend the Gemini backend for the best experience — it's the fastest (sub-second response times), has the widest binary format support, and offers a generous free tier. Get an API key at ai.google.dev.

# Install from PyPI
pip install inferencefs
# or
uv pip install inferencefs

# Or install from source
git clone https://github.com/philipl/inferencefs.git
cd inferencefs
uv sync

# Mount with Gemini backend (recommended)
export API_KEY=your-key-here
mkdir -p /tmp/source /tmp/mount
uv run inferencefs --backend gemini /tmp/source /tmp/mount

# Create some files and read them
touch /tmp/mount/hello.py
cat /tmp/mount/hello.py

# Unmount
fusermount3 -u /tmp/mount

Backends

Backend Flag API Key Notes
Google Gemini --backend gemini API_KEY Recommended. Fastest, free tier, widest binary format support
Claude Code CLI --backend claude-code None (uses CLI auth) No API key needed, binary support
Claude API --backend claude API_KEY Direct API, best text fidelity

Usage

inferencefs [--backend {claude,claude-code,gemini}]
            [--api-key API_KEY]
            [--cache-size CACHE_SIZE_MIB]
            [-d] [-o OPTIONS]
            source mountpoint

How It Works

  1. The source directory provides the file and directory structure — this is your metadata, and it's all you need
  2. When you read a file, InferenceFS asks an LLM: "What is the most likely contents of a file with the name /path/to/file?"
  3. The model's response becomes the file contents
  4. Binary files are requested as base64 and decoded automatically
  5. Contents are cached in memory so repeated reads don't re-query the model
  6. Writes are accepted but discarded — the model always has the last word

FAQ

But what about my data?

Your data is fine! It's right there in the model weights. You don't need to worry about it. Just like with πfs, your data was always there — you just didn't know where to look. The difference is that πfs needed you to remember where in π your bytes were, and InferenceFS only needs you to remember what you called the file. And you were going to remember that anyway!

What if you lose your filenames? No problem — they're just metadata! Your data is still out there, dissolved in the latent space, waiting for someone to ask the right question.

This file doesn't look like what I remember.

Are you sure? It's been a while since you last opened it. Memory is funny like that. The file is fine — maybe take another look with fresh eyes.

I'm pretty sure my name isn't Alice, or Bob.

A lot of people are named Alice or Bob. It's actually much more common than you'd think. Perhaps you're thinking of your middle name?

This picture doesn't look like me, or anyone else in my family.

When was the last time you looked in a mirror? People change. Hairstyles change. Besides, the lighting in that photo isn't great — it could be anyone, really. It could be you.

About

The new data-free filesystem!

Resources

License

Stars

Watchers

Forks

Packages

 
 
 

Contributors

Languages