What happened
Vercel Labs published fx v0.0.15 on October 27, 2026. The release says fx now uses 70% less memory in long conversations. In a local synthetic benchmark containing 96 MiB of saved images, fx v0.0.15 used 116.5 MiB of peak memory, compared with 381.8 MiB for v0.0.14, a reported reduction of 69.5%. Turns completed in 288 milliseconds rather than 939 milliseconds, or 3.3 times faster. The release also reports that text sessions resume about 18% faster in local comparisons with v0.0.14.
The release describes changes to how durable sessions store images and logs. Prompt, steering, and tool images are saved once rather than copied into every checkpoint. The conversation retains its newest 4,096 images, up to 512 MiB, replacing older images with notes. Pasted, dropped, and attached images are saved once per session, and fx tells the model where to find the saved copy. Resuming or forking loads image bytes only when needed. In a separate local WebAssembly benchmark, the updated implementation completed 140 turns; the earlier implementation ran out of memory at turn 102.
Session storage work also reduces redundant reads: in a 40-turn benchmark, starting the next turn required seven serial storage calls rather than 11, a 36% reduction. Durable libfx sessions no longer reread unchanged log entries. The release further says a turn’s result resolves only after the final state is saved for libfx engines that persist state; if saving fails, the result rejects instead of reporting success.
The new /fork command starts a separate session before an earlier prompt and places that prompt back in the composer so it can be edited or resent. The original conversation remains unchanged. The model catalog can refresh in the background without restarting fx; cached models remain available if refresh fails. Other listed changes include /effort for choosing a supported reasoning level without switching models, and updated recovery, MCP, image, and session-management behavior. The supplied release does not state a price or access restriction.
What the archive adds
Our earlier fx v0.0.16 note covered a later release, describing prompt-caching improvements and smaller downloads and binaries. This v0.0.15 release is a distinct earlier event, not a new fact about v0.0.16. The archive also includes a Claude Code release note, but its session fixes are not materially connected to this fx update.
Trend signal
The release supports harness architecture outlives model choice: its work focuses on session persistence, recovery, branching, and tool handling rather than a change to the underlying model. This is one tool release, not evidence that every production agent is converging on the same harness design.
Why now
The release’s stated improvements target long-running sessions that accumulate saved images and tool output. Its new branching command also addresses a practical workflow need: trying a revised prompt without altering the original conversation.
Why it matters
Memory use can determine whether an agent workflow remains usable as a conversation accumulates images and tool results. If the reported improvements hold in a team’s own workload, they could make longer sessions less likely to hit resource limits and reduce the time spent waiting to resume work. The storage design is also relevant beyond raw speed: saving images once and loading them only when needed makes session state more economical to preserve and branch.
/fork adds a low-friction way to explore alternatives while retaining the original work as a reference. That can help builders compare prompts, investigate a failed approach, or continue from an earlier decision without rebuilding the entire context. These are workflow-level changes, not proof that fx produces better answers or that its memory profile will improve for every workload. Teams should treat the release benchmarks as a reason to test, not as a substitute for measuring their own sessions.
What happens next
- Teams using fx for image-heavy agent sessions will test v0.0.15’s memory claims on their own workloads. (3 months, 65%). Watch for: follow-up release notes or reproducible comparisons using varied conversation sizes.
Limits and uncertainty
The performance figures come from local comparisons described by the project, including a synthetic workload with 96 MiB of saved images. The release does not establish results across hardware, operating systems, image distributions, or production workloads, nor does it provide independent verification. The 140-turn WebAssembly comparison is a separate benchmark, so it should not be combined with the peak-memory figures as if they measured the same test. The release excerpt does not specify price, access terms, or broad adoption. It also does not show whether branching or background catalog refresh changes model quality or reliability.
Skill to build now
If your team uses fx, create a small repeatable session test that matches your workload: include representative image attachments, tool calls, and resume points. Compare peak memory, turn time, and resume time before and after upgrading, and record the fx version and environment. Try /fork on a prompt with a meaningful alternative and confirm the original session remains available for review.
Reader takeaway
fx v0.0.15 combines a useful session workflow change with substantial but locally measured memory and speed claims. The practical move is to test it on the long, image-heavy conversations that strain your current setup, rather than assume the benchmark will transfer unchanged.