DEV TOOLS Signal 142
Tithon enables VSCode notebooks to keep kernels alive across disconnects
Tithon adds a host-side daemon and VSCode extension that let Jupyter kernels continue running and streaming output even after the client is closed.
Engineers can start long-running notebook jobs on remote machines and safely close their editor or lose network connectivity without losing kernel state or output. The persisted output journal also keeps notebook diffs clean and makes replay of results straightforward.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
A host-side daemon owns the Jupyter kernel, so the kernel survives client shutdowns, network drops, and daemon restarts.
The VSCode extension treats a plain .py file as a notebook, streaming live rich output while journaling all messages to an SQLite log for later replay.
It requires Python 3.11+, a Unix-like OS, and works via VSCode Remote-SSH or Tunnel; native Windows is not supported.
THE READ
What the cluster adds up to.
The core problem addressed is that traditional Jupyter setups tie kernel lifetime to the client process, causing kernels to die when the editor is closed or the network drops. Tithon moves the source of truth for the session to a daemon running on the host, decoupling kernel execution from the VSCode extension host. This change lets users start a notebook on a remote GPU box, close their laptop, and later reconnect to the same live session with all prior output intact.
Installation involves installing the Tithon daemon from PyPI (e.g., `pip install tithon`) and adding the VSCode extension from the Marketplace. The daemon and extension must run on the same Unix-like host, which can be a remote machine accessed via VSCode Tunnel or Remote-SSH. On Windows, the recommended approach is to run Tithon inside WSL, as native Windows support is not provided.
When the daemon starts, it launches the Jupyter kernel in a detached process (using `setsid`) so the kernel outlives the daemon itself. Every iopub and shell message is written verbatim to an append-only SQLite journal, and a snapshot of the display state is kept for fast reconnection. Clients attach by sending the last sequence number they saw, receiving a snapshot plus a gapless delta stream, which restores the notebook view exactly as it was before disconnect.
The project is marked as alpha, meaning users will encounter rough edges and should file bug reports. Limitations include the requirement for Python 3.11+, a Unix-like environment, and the need for the daemon and extension to share the same `TITHON_HOME`. Native Windows is not currently supported, and remote setups require forwarding the Unix socket if the extension runs on a different machine.
For engineers, this persistence model reduces the risk of losing long-running computations and their rich outputs, simplifies debugging of remote jobs, and keeps version control clean by storing outputs outside the source file. The ability to replay exact output streams also aids in reproducibility and integration with AI agents that can consume real image files instead of base64 JSON payloads.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER