One Prompt, 14 Files, 41 Seconds: Inside FutureX's Multi-File Preview Pipeline

When a developer gives FutureX a single prompt that touches a dozen files, the agent has to read, reason, and render a preview in 41 seconds. That number is not a lucky measurement -- it is the output of a deliberately engineered pipeline. This post breaks down the internal orchestration: how FutureX assembles a lean agent context window across 14 files, reads them concurrently, and streams incremental rendering updates into the preview pane. If you are building your own agentic preview tools, each stage here is an architectural pattern you can steal.

The Problem: Context Windowing Across Many Files#

FutureX receives a prompt asking to change a UI component across a project. The planner produces a file list with 14 targets. The orchestration layer must assemble an agent context window that contains enough of each file to make accurate edits without overflowing the window. Instead of loading entire files, the context manager computes an optimal window per file based on the prompt's dependency graph. Stale code is evicted as new files stream in.

Why 14 Files Matters#

14 files is a threshold where naive approaches collapse. Read each file sequentially and you spend 10-15 seconds just on I/O, before any model token is generated. Read them all fully and the agent context window fills with irrelevant code. FutureX's windowing policy integrates with the planner: every file gets a priority, a line range, and a freshness timestamp. The result is a compact, ordered context that fits a single model turn.

The windowing pass is not a simple head-and-tail cut. FutureX computes a structural outline for each file -- imports, exported symbols, function signatures, JSX roots -- and prunes lines that are neither referenced by the prompt nor needed for syntax validity. This keeps multi-file AI coding from turning into a context-full dump. The planner also annotates cross-file references so the model can reason about how a change to Button.tsx affects Form.tsx without seeing every line of either.

Parallel Reads and the File Fetcher#

The first optimization is obvious in hindsight: stop waiting on disk. FutureX's file fetcher treats all 14 paths as a fan-out job. It dispatches reads on a thread pool sized to the filesystem's I/O queue depth, and each read returns a promise. The orchestrator awaits the batch, not the individual requests. That parallel read phase completes in about 2.1 seconds for typical source files -- a 6x improvement over sequential reads.

The file fetcher also honors an important constraint: it never blocks the model on files that are still being read. The context manager assembles the window incrementally, and the model invocation starts as soon as the highest-priority files are in place. Lower-priority content is appended to the context while the model is already processing, using a streaming context aggregator that the model client consumes transparently.

Batching and Dependency-Aware Ordering#

Not all files are equal. The fetcher sorts paths by their position in the dependency graph before sending the batch. Files that are imported by other files are fetched first because the windowing pass needs their exported symbols to annotate the context. This avoids a second round-trip later. The batch is then passed to the context manager, which fuses overlapping read windows and drops whitespace-heavy regions.

Source: blog.futureim.org

Incremental Rendering: Painting the Preview Early#

The biggest win in the 41 seconds is not fetch speed; it is that FutureX does not wait for the model to finish before showing something. Once the first tokens of a plan are emitted, the renderer starts building an intermediate representation. This is incremental rendering: every structural token (function signature, import block, modified JSX tree) is mapped to a preview mutation immediately.

The preview pane is not a full-page reload. It is a virtual DOM that FutureX patches as new tokens arrive. The first patch typically appears about 8 seconds into the run, which means the user sees a living draft while the remaining files are still being consumed. Perceived code preview latency drops dramatically because the most visible changes (new component names, hooks, layout boundaries) are usually emitted early in the model's response.

Chunked Token Streaming and Event Loop#

FutureX streams model output in 70-token chunks. Each chunk is parsed on a dedicated worker and converted into targeted UI notifications. The main thread only applies diffs to the preview component tree, so the UI never blocks on the full completion. The event loop stays responsive even while the last files are still being digested.

This chunked design has a subtle benefit: the renderer can discard tokens that become irrelevant. If the model first emits a large component block and then, in a later chunk, emits a replacement for that same block, the renderer reconciles the diff rather than rerendering the entire tree. The preview stays smooth, and the browser tab never freezes.

Reordering Updates by Dependency#

The renderer also respects ordering. If the model emits a new hook and then a component that uses it, the preview applies the hook first and the component second, even if the component token arrived in an earlier chunk. A small scheduler maintains a topological order over preview patches, guaranteeing the user never sees a broken intermediate state.

When a patch depends on a file that has not finished streaming, the scheduler holds the patch in a pending queue and applies it as soon as the dependency resolves. This is what makes the 41-second rendering feel coherent: the final preview is exactly what the model intended, and intermediate steps are always consistent snapshots, not random fragments.

Measuring Latency: Why 41 Seconds Is Good#

For a single-file change, FutureX can preview in under 4 seconds. For 14 files, the time balloons because of model inference and reasoning, not I/O. Let's break down the 41-second number to see where the budget goes.

Breakdown of the 41-Second Pipeline#

• Plan and file list: 1.2s
• Parallel reads and context assembly: 2.9s
• Model turn (plan + edits, streamed): 31.4s
• Incremental rendering and final hydration: 5.5s

Total: 41.0s

The model turn dominates. The reason 14 files matter is that the model has to reason about interactions across all of them, which increases the number of tokens generated before the first preview patch appears. The incremental renderer hides this by updating the preview throughout the turn; users see a living draft after about 8 seconds, long before the final file is written.

How This Compares to Naive Agents#

A naive agent that reads files sequentially, stuffs everything into the prompt, and waits for a full completion would take 90+ seconds and frequently lose track of earlier files in the agent context window. FutureX's code preview latency is therefore a design target, not just a benchmark. By keeping the context window lean and the rendering incremental, the agent delivers a smooth experience even as the file count grows.

Building Your Own Agentic Preview Tool#

If you are building a multi-file AI coding tool, copy the three architectural bets FutureX makes.

Treat the Context Window as a Cache#

The agent context window is a cache with a strict size limit. Use LRU semantics, but prioritize files that appear in the prompt's dependency graph. Compute a diff between the current window and the desired window, and only evict lines that are truly dead. This keeps multi-file AI coding from degrading into a context-full dump.

Pipeline the Reads, Then Pipeline the Renders#

Separate the fetch phase from the model phase, and the model phase from the render phase. Each stage should be independently streamable. FutureX uses a promise-based file fetcher and a token-streaming model client; the renderer is just another stream consumer. This makes the whole system a pipeline, not a waterfall.

Emit Structural Tokens Early#

The model's output format matters as much as the model. FutureX instructs the agent to emit structural markers (file paths, symbol names, edit ranges) before the prose. That lets the renderer apply changes out of order and lets you show progress. Without structural tokens, incremental rendering is guesswork.

Conclusion#

FutureX's 41-second, 14-file preview is not magic. It is the sum of three concrete engineering decisions: dependency-aware context windowing, parallel file reads, and incremental rendering that respects a dependency order. The same principles apply to any agentic preview tool you build. Optimize the I/O, keep the context window lean, and let the user see progress before the finish line. AI coding agent performance is measured in perceived latency, and 41 seconds of pipeline can feel like five when the preview is alive from the first token.