Write F#. See it live.

SageFs is a live development environment that eliminates the edit‑build‑run cycle. Tests run as you type — no save needed. Eval code on demand with Alt+Enter. Results stream to the dashboard, editor integrations, and MCP clients from a single shared daemon.

$ sagefs
Get started in 60 seconds
Requires the .NET 10 SDK
01

Install

SageFs is a .NET global tool. One command, no config files.

$ dotnet tool install --global SageFs
02

Run

The daemon starts bare and waits for your editor to connect.

$ sagefs
03

Code

Edit any .fs file — tests run on every change. Hit Alt+Enter to evaluate code on demand. Results stream to your editor.

Full documentation →
What happens when you run it
From keystroke to result in under a second
Here's the path your code takes — from the moment you change it to the moment you see results in your editor.
01 — You write code

Change a line

Edit any .fs or .fsx file. Tests start running on every change — no save needed. Hit Alt+Enter to evaluate code on demand. Both modes, all the time.

0 ms
→
02 — File watcher detects

Change captured

SageFs watches your entire project tree. It sees the change as it happens, classifies it (.fs → reload, .fsproj → soft reset), and routes it to the right handler.

~5 ms
→
03 — Worker evaluates

Code runs in FSI

A dedicated worker process — already warmed up with your project's dependencies loaded — compiles and executes the changed code. No cold start. No full rebuild.

~100 ms
→
04 — Tests re-run

Affected tests only

The live testing engine identifies which tests touch the changed code and re-executes just those. Green checkmarks or red failures stream back instantly.

~300 ms
→
05 — Results everywhere

All editors update

Via Server-Sent Events (SSE), every connected client — the dashboard, VS Code, Neovim, Visual Studio, and MCP agents — sees the results simultaneously. No polling. No refresh.

~500 ms total
Work where you want
Dashboard and editors, one live session
The dashboard and every editor connect to the same running daemon. Switch between them freely — your session, your test results, your eval history all stay in sync.
🧩

Neovim

Lua · 40 modules · 1197 tests

Two eval modes: tree-sitter auto-detects the enclosing scope in .fs files (inferred mode), or use ;; delimiters for explicit cell boundaries (manual mode). Virtual text for inline results, SSE-driven live diagnostics, gutter signs for test pass/fail and code coverage.

  • tree-sitter scope eval
  • live diagnostics
  • coverage gutter
  • test panel
  • type explorer
💻

VS Code

F# via Fable → JavaScript · 21 modules

Select code, hit Alt+Enter, see colored annotations inline. Sidebar panels for hot reload file trees, live test status, type exploration, and session switching. Auto-detects or starts the daemon.

  • inline eval results
  • test gutter icons
  • hot reload tree
  • type explorer
⌨️

Web Dashboard

Browser · Datastar · live SSE

The built-in browser workspace for session creation, code evaluation, output, diagnostics, live tests, and daemon health. Open it at http://localhost:37750/dashboard after starting SageFs.

  • Alt+Enter eval
  • session management
  • live test status
  • diagnostics
🖥️

MCP Clients

Model Context Protocol · agent tools

Give coding agents direct access to the live FSI session. They can evaluate and type-check snippets, inspect session state, discover projects, and run targeted tests against the same daemon used by the dashboard and editor integrations.

  • live compiler
  • structured results
  • test tools
  • session control
🏢

Visual Studio

F# + C# · VS Extensibility · 44 modules

Integration with Visual Studio's tool windows. Eval, CodeLens, and session management — embedded in the IDE enterprise teams already use. Daemon auto-management included. Live testing UI is still in progress.

  • tool windows
  • daemon management
  • session control
  • CodeLens eval
The secret sauce
One daemon. Every client. Always in sync.
SageFs runs a single background daemon that owns all sessions, workers, and state. The dashboard, every editor, and every AI agent connect through the same daemon contracts. Crash-proof supervision means it auto-restarts on failure.
Clients — where people and agents work
Neovim
Cell eval, gutter signs, live diagnostics
VS Code
Inline annotations, sidebar panels
Dashboard
Browser workspace, sessions, tests, diagnostics
Visual Studio
Tool windows, daemon auto-start
AI Agents
Claude, Copilot, any MCP client
↕ SSE push (real-time) + HTTP requests ↕
Daemon — the single process that owns everything
SageFs Daemon
Elm-style state machine. All sessions, all test results, all editor state lives here. Broadcasts every change to every client via SSE. Exposes MCP tools for AI agents. One process, one source of truth.
↕ HTTP to isolated worker processes ↕
Workers — where your code actually runs
Active Worker
Running your FSI session — evals, completions, type checks
Standby Worker
Pre-warmed with your project. Swaps in instantly on reset.
Standby Worker
Another warm spare. Pool auto-heats when .fsproj changes.
Under the hood
What makes it fast, reliable, and smart
Each piece of SageFs exists to solve a specific problem you'd hit building a live F# environment. Here's why each one matters.
⚡

Hot Reload

"I saved a file. Why do I have to rebuild everything?"
When you save, SageFs patches method pointers at runtime — no IL instrumentation, no restart. Changed functions are live in ~100ms. The browser auto-refreshes via SSE. Only the changed file recompiles; everything else stays warm.
HotReloading.fs HotReloadState.fs FileWatcher.fs
🧪

Live Testing

"I want to know if my change broke something — before I even save."
Three-speed pipeline: Tree-sitter finds tests in broken code (~50ms), the F# Compiler Service builds a dependency graph (~350ms), then only affected tests execute. Green/red gutter markers in your editor. Tests run on every change by default — no save needed. Configurable per category: unit on every keystroke, integration on save, browser on demand.
LiveTestingExecutors.fs TestTreeSitter.fs LiveTestingTypes.fs
🧠

Code Completions

"What methods does this type have? What namespace is that in?"
Type-aware completions powered by the F# Compiler Services, with fuzzy matching. Available everywhere — the dashboard and editor plugins receive them from the daemon, and AI agents access them through the MCP get_completions tool. Explore any loaded .NET API interactively. Diagnostics (type errors, warnings) stream inline as you type.
AutoCompletion.fs Diagnostics.fs Editor.fs
🔄

Session Management

"I need multiple contexts — one for my app, one for experiments."
Create, switch, reset, and destroy isolated F# sessions on the fly. Each gets its own FSI worker process with your full project loaded. Sessions persist across daemon restarts. Soft reset clears definitions; hard reset rebuilds from scratch.
SessionManager.fs SessionLifecycle.fs SessionOperations.fs
🏊

Standby Pool

"Restarting a session takes forever while it reloads my project."
In the background, SageFs pre-warms spare worker processes with your project already compiled and loaded. When you reset, the standby swaps in instantly — no cold start. The pool auto-heats when project files change.
StandbyPool.fs WorkerProtocol.fs HttpWorkerClient.fs
🎨

Live Dashboard

"How do I see every session, test, and diagnostic in one place?"
The daemon serves a browser dashboard and pushes state changes over SSE. Create and switch sessions, evaluate F#, inspect output, and track live tests and diagnostics without a separate desktop frontend.
Dashboard.fs DashboardFragments.fs DashboardTypes.fs
🔁

Elm Architecture

"How does everything stay in sync without race conditions?"
All state lives in a single immutable model. Every event — keystrokes, file changes, test results, SSE messages — dispatches through a pure update function. No shared mutable state. No locks. Side effects execute after the model updates. The UI is always a pure function of the current model.
ElmLoop.fs SageFsApp.fs ElmDaemon.fs AppState.fs
🛡️

Crash Recovery

"What if a worker crashes? What if the daemon dies?"
Erlang-style supervision. The watchdog monitors every worker process — if one crashes, it auto-restarts with exponential backoff. The daemon itself is supervised at the OS level. State is persisted to binary manifests, so nothing is lost. A crashed session resumes exactly where it left off.
Watchdog.fs DaemonState.fs EventStore.fs
📡

Observability

"Something is slow. How do I find out what?"
OpenTelemetry tracing across the entire pipeline — from file save to test result. Frame time displayed in the status bar. Pipeline trace tool shows exactly where time is spent: discovery, compilation, execution, rendering.
Instrumentation.fs
Game-project proof: RaylibGame and RaylibHello are application demos showing that SageFs supports live F# game projects. They are user projects, not the deprecated SageFs.Gui frontend.
Built for AI agents
Give Claude (or any AI) a live compiler
SageFs exposes the Model Context Protocol (MCP) — the same protocol that powers Claude Desktop and GitHub Copilot tool use. AI agents don't just generate code. They execute it, type-check it, run tests, and iterate — against your real project. 30 tools. Zero boilerplate.
send_fsharp_code
Execute F# code in a live session with your project's full dependency graph loaded. Each ;; is an isolated transaction.
check_fsharp_code
Type-check a snippet against the current FSI session without executing it. Returns compiler diagnostics. Uses live session context — prior open statements are in scope.
run_tests
Execute tests by name, category, or pattern. Waits for any in-progress hot reload to finish first — results always reflect the latest code. Supports unit, integration, property, browser, and more.
get_completions
Code completions at any cursor position. The agent discovers available APIs from your actual loaded assemblies.
explore_namespace / explore_type
Browse the full .NET type system interactively — namespaces, types, members, constructors. No documentation needed.
get_live_test_status
Query the current state of all tests — passing, failing, stale, running. See what broke and what's green.
load_fsharp_script
Load and execute an .fsx script file. Each statement runs independently — partial progress survives failures.
get_test_trace
Diagnose slow test runs. See enabled providers, run policies, and per-test timing to find bottlenecks.
explain_test_failure
Enriched failure context for a test that just broke. Shows exactly which symbols changed between the last passing and first failing run, plus FsCheck counterexamples.
query_test_coverage
Find every test that transitively covers a given symbol. Know what to run before refactoring — and what you might break.
The complete picture
Every module, every layer
SageFs.Core is the shared engine (94 modules). The daemon serves the dashboard, editor integrations, and MCP clients. Here's the full compilation-order dependency map.
🏗️ Foundation — bootstrapping, configuration, utilities
Args Utils ProjectLoading ShadowCopy WarmUp Instrumentation
↓ depends on ↓
🔌 Worker System — isolated FSI process management
WorkerProtocol HttpWorkerClient StandbyPool Watchdog
↓ depends on ↓
📋 Session Layer — lifecycle, state, operations
SessionManager SessionLifecycle SessionOperations EventStore DaemonState
↓ depends on ↓
✨ Features — the user-facing capabilities
LiveTestingTypes LiveTestingExecutors LiveTestingInstrumentation TestTreeSitter AutoCompletion Diagnostics DiagnosticsStore CoverageInstrumenter Events Replay HotReloading HotReloadState FileWatcher
↓ depends on ↓
🖼️ Rendering — abstract grid → any backend
Editor RenderPipeline CellGrid Draw Screen TerminalUI Theme ThemePresets SyntaxHighlight AnsiEmitter
↓ depends on ↓
🔁 Elm Loop — the heart of state management
ElmLoop SageFsApp ElmDaemon AppState
↓ depends on ↓
🧩 Middleware — FSI compatibility, computation expressions, directives
FsiCompatibility ComputationExpression Directives NonBlockingRun
↓ depends on ↓
🚀 Orchestration — wiring it all together
ActorCreation Mcp DaemonMode Dashboard Program
94
Core modules
~35K
Lines of production F#
3,500+
Tests (SageFs)
5
Primary clients
19
Days to build
938+
Commits