Files All the Way Down — Empirical Findings

Research Findings

Empirical results from “Files All the Way Down: A Design Space Analysis of Filesystem-Native LLM Tool Integration.” Live experiments on Claude Code (Linux x86_64). All reproducible via bash research/run-all.sh.

Read the Full Paper →

Token Efficiency Benchmark

Token consumption is a direct proxy for inference cost and latency. We ran identical tasks against LiveFoldersFS and MCP and recorded per-turn token usage via the Anthropic API. LF-native beats MCP by 6–10% on every task, with 100% task completion across all runs.

Key result: LiveFoldersFS's native tool schema approach — Anthropic-format tool definitions synthesized at read time from folder.yaml via anthropic_tools.json — achieves 6–10% lower token consumption than MCP across an 8-task benchmark, with 100% task completion on all tasks and all backends.

Five Backends Compared

Backend How it works Result
livefolders (bash) Original cat/echo invocation, system prompt from system_prompt.md 2.5–5× more expensive than MCP (up to 8× on near-timeout runs). Not production-suitable.
livefolders-manifest Same filesystem; system prompt is the concise per-endpoint listing synthesized by the VFS +2–8% vs MCP (consistently more expensive, but large improvement over bash)
livefolders-native Tool schemas loaded from anthropic_tools.json; model calls structured Anthropic tools −6–10% vs MCP on every task
livefolders-unified anthropic_tools.json schemas collapsed into one tool per namespace with an action enum −5–9% vs MCP (2–5% worse than native due to reduced per-action guidance)
mcp (baseline) Standard MCP server over stdio; tool schemas via list_tools Baseline (0%)

Model: claude-haiku-4-5 (maximises sensitivity to schema overhead). 5 runs per task, results averaged. All 5 backends call the same upstream API (mockapi.io, 50 users). Traces logged to Weights & Biases Weave.

8-Task Suite Results

Task Description LF-native LF-unified MCP LF-native vs MCP
count_users Count total users 1,893 1,915 2,094 −9.6%
count_composed Count via pipe-composed endpoint (server-side) 1,892 1,914 2,093 −9.6%
single_user Look up a user by name 1,962 2,235 2,163 −9.3%
list_users List all users with name and ID 2,917 2,915 3,176 −8.2%
cross_reference Find user's account creation date 3,190 3,231 3,471 −8.1%
count_and_find Count users AND find a specific user's ID 2,102 2,148 2,282 −7.9%
filter_and_count Find users with 'a' in name; count them 2,582 2,622 2,794 −7.6%
list_compact List users as compact id:name pairs (pipe) 2,786 2,805 2,975 −6.4%

5-run averages. With only 5 runs per task, effects below ~3% should be treated as indicative rather than statistically robust.

Why LF-native is cheaper

Compact schemas

Hidden endpoints (marked hidden: true in folder.yaml) are excluded from anthropic_tools.json, while MCP exposes all registered tools unconditionally. For the users API (6 visible, 3 hidden endpoints), the LF schema is ~15% smaller than the equivalent MCP list_tools response.
Server-side composition

Pipe chains, filter endpoints, and get-by-ID handlers move work from model context to tool execution, reducing output tokens. On filter_and_count, adding a server-side filter endpoint dropped output tokens from ~963 to ~386 — the model receives a pre-aggregated answer rather than 50 raw users.
Fewer reasoning turns

The cross_reference task benefits from a get endpoint (fetch-by-ID) that returns exactly the needed fields (name, id, createdAt, avatar) rather than requiring the model to scan a full listing in context.
The bash backend is not suitable for production. The original livefolders backend (plain cat/echo via system prompt) is 155–400% more expensive than MCP on tasks that complete, with runs approaching the 10-turn safety cap pushing toward 8× the token cost. Use anthropic_tools.json (livefolders-native) for production deployments.

How anthropic_tools.json Works

LiveFoldersFS synthesizes a virtual anthropic_tools.json file at read time from folder.yaml. Each invokable endpoint becomes an Anthropic-format native tool definition that can be injected directly into the tools=[] API parameter — enabling structured tool calling without shell access.

Hidden endpoints are excluded from anthropic_tools.json automatically — the model only sees the endpoints it should call, reducing schema tokens. The file is never written to disk; it is synthesized fresh on every read from the current folder.yaml.

7-System Comparison Matrix

All seven systems evaluated across ten criteria using three evidence tiers: T1 = live experiments · T2 = structured assessment (code + install) · T3 = paper-only. Rating: ✓ strong · ~ partial · ✗ weak · — N/A.

Criterion LiveFolders
T1
MCP
T1
ToolFS
T2
AgentFS
T2
llm9p
T2
InferNode
T3
Quine
T3
01 Setup complexity~~~~~
02 LLM compatibility~~~~~~~
03 Discoverability~~~~
04 I/O expressiveness~~~~~~
05 Security~✗ ~
06 Stateful tools~~~~~
07 Composability~~~
08 Observability~~~
09 Hot-reload~~~
10 Publishing~~~
✓ count 8 3 1 1 0 3 2

⚠ ToolFS criterion 05: WASM sandbox was an unimplemented stub (InMemorySandbox) at the time of T2 code inspection (early 2025); subsequent releases may differ. llm9p criterion 05: unauthenticated TCP port accessible to any network process.


Architecture Overview

LiveFoldersFS is os-coupled and posix-invocation: the FUSE kernel layer is the sole entry point, and every tool invocation reduces to a standard file write followed by a file read — no protocol, no SDK.


Three Design Principles

📏 Principle 1

Coupling depth determines ergonomics ceiling.

OS-coupled systems inherit decades of POSIX tooling. The token benchmark adds a quantitative dimension: when LiveFoldersFS exposes tools as Anthropic-native schemas via anthropic_tools.json, it achieves 6–10% lower token consumption than MCP. The advantage compounds on aggregate tasks because server-side composition moves work from model context to tool execution — structurally unavailable to protocol-decoupled systems without equivalent server-side aggregation. Tradeoff: os-coupled systems require shell and filesystem access; MCP operates over HTTP and can serve agents anywhere.

🛡️ Principle 2

Invocation interface determines safety floor.

RPC systems (MCP) enforce input schemas unconditionally before any handler runs. POSIX systems historically concentrated security on handler authors. LiveFoldersFS narrows this gap with opt-in per-endpoint validation (v0.7.0) plus VFS-layer sandboxing via Landlock + seccomp-BPF (v0.11.0). Remaining gap: MCP validation is unconditional; LiveFoldersFS requires explicit opt-in per endpoint. Worst finding in the survey: llm9p's unauthenticated TCP port is accessible to any network process.

📦 Principle 3

Publishing model is underexplored.

LiveFoldersFS is the only surveyed system treating tool distribution as a first-class design concern. livefolders install github.com/you/repo requires no registry, no package upload, no config editing. All other systems require manual configuration or informal community registries. As the ecosystem matures, install friction will determine whether tool ecosystems grow organically or remain fragmented.


Limitations

  • The token efficiency benchmark uses a single model (claude-haiku-4-5) and a single upstream API (mockapi.io, 50 users). Token margins may shift for larger models, denser APIs, or different tool-call-to-output ratios.
  • T2 and T3 assessments capture a point-in-time code and documentation snapshot. Rapidly evolving projects may have addressed noted deficiencies since inspection.
  • With only 5 runs per task, the benchmark does not support formal statistical inference. Effects below ~3% should be treated as indicative.
  • The evaluation host (Claude Code on Linux x86_64 with shell access) may not represent cloud-hosted agent deployments where the LLM has no filesystem access, which would lower LLM compatibility ratings for all os-coupled systems.
Competing interests: The author is the primary developer of LiveFoldersFS, one of the two T1 systems evaluated. Explicit evidence tiers and publicly reproducible experiments are intended to mitigate, though not eliminate, the risk of confirmation bias. All T1 results are reproducible via bash research/run-all.sh from the repository root.