[FEATURE] Feature request: Live file references between threads ("xrefs" for Claude)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Feature request: Live file references between threads (“xrefs” for Claude)
Summary: Threads and artifacts should be able to hold a live reference to a canonical project file rather than a baked-in copy — the model AutoCAD has used for external references (xrefs) since 1987.
The problem
Every new thread that needs a project document re-ingests it in full. Users iterating on a spreadsheet, codebase, or long document across many short threads cause the same content to be tokenised repeatedly. At scale this is significant wasted compute — and for the user, stale snapshots: the moment the source file changes, every prior output referencing it is silently out of date.
Projects, prompt caching, and memory each solve a slice of this. None provide the missing piece: write-back. A short thread can read a project file, but cannot update the master so subsequent threads inherit the change. Users propagate edits manually — the 1980s drawing-office workflow that xrefs were invented to eliminate.
The proposal (prior art: 40 years of CAD)
The construction industry solved distributed document coordination decades ago, because a hospital cannot be designed by emailing copies of drawings back and forth. The xref model:

1. Attach — a thread/artifact references a canonical project file by ID, not by value. Only changed sections are re-tokenised (delta + cached prefix).
2. Reload — on open, the reference resolves to the current version. No stale snapshots.
3. Write-back — a thread can commit changes to the master file (with versioning; last-write-wins or simple conflict prompt to start).
4. Bind/Detach — user can freeze a reference into a static copy when a snapshot is genuinely wanted (e.g. a dated report).

Why it matters
• Token/compute efficiency: short threads referencing a large master file stop paying full ingestion cost every time. The environmental argument is unusually honest here: it is literally “stop making the machine read the same document forty times.”
• Correctness: outputs stay consistent with the current source.
• Workflow: enables the natural pattern of many small focused threads updating one canonical deliverable — instead of one monster thread or manual copy-paste propagation.
Minimal viable version
A per-project key-value file store with version numbers, a file_read(ref) / file_write(ref, delta) tool pair exposed to threads in that project, and prefix caching keyed on file version. The hard parts are product decisions (permissions, conflicts), not engineering volume.

Proposed Solution

Feature request: Live file references between threads (“xrefs” for Claude)
Summary: Threads and artifacts should be able to hold a live reference to a canonical project file rather than a baked-in copy — the model AutoCAD has used for external references (xrefs) since 1987.
The problem
Every new thread that needs a project document re-ingests it in full. Users iterating on a spreadsheet, codebase, or long document across many short threads cause the same content to be tokenised repeatedly. At scale this is significant wasted compute — and for the user, stale snapshots: the moment the source file changes, every prior output referencing it is silently out of date.
Projects, prompt caching, and memory each solve a slice of this. None provide the missing piece: write-back. A short thread can read a project file, but cannot update the master so subsequent threads inherit the change. Users propagate edits manually — the 1980s drawing-office workflow that xrefs were invented to eliminate.
The proposal (prior art: 40 years of CAD)
The construction industry solved distributed document coordination decades ago, because a hospital cannot be designed by emailing copies of drawings back and forth. The xref model:

1. Attach — a thread/artifact references a canonical project file by ID, not by value. Only changed sections are re-tokenised (delta + cached prefix).
2. Reload — on open, the reference resolves to the current version. No stale snapshots.
3. Write-back — a thread can commit changes to the master file (with versioning; last-write-wins or simple conflict prompt to start).
4. Bind/Detach — user can freeze a reference into a static copy when a snapshot is genuinely wanted (e.g. a dated report).

Why it matters
• Token/compute efficiency: short threads referencing a large master file stop paying full ingestion cost every time. The environmental argument is unusually honest here: it is literally “stop making the machine read the same document forty times.”
• Correctness: outputs stay consistent with the current source.
• Workflow: enables the natural pattern of many small focused threads updating one canonical deliverable — instead of one monster thread or manual copy-paste propagation.
Minimal viable version
A per-project key-value file store with version numbers, a file_read(ref) / file_write(ref, delta) tool pair exposed to threads in that project, and prefix caching keyed on file version. The hard parts are product decisions (permissions, conflicts), not engineering volume.

Submitted by a Fellow of the Royal Institute of the Architects of Ireland — the building kind. We have been coordinating live-referenced documents since before the telegraph was cool. Happy to discuss; the prior art is extensive and mostly drawn in ink.

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_