Every data scientist or machine learning engineer has lived through the specific anxiety of the Kernel Disconnected message. You are running a heavy training loop on a remote server, perhaps through a flaky SSH tunnel, and suddenly the connection drops. In a standard Jupyter environment, the kernel might still be churning away in the background, but the bridge to your screen is gone. When you finally reconnect, you are often met with a void where your logs, progress bars, and critical output values should be. The execution happened, but the evidence vanished into the ether of a broken WebSocket.
The Architecture of Tithon
Tithon enters the ecosystem as a REPL notebook tool designed specifically to eliminate this volatility. Rather than relying on the traditional .ipynb format, Tithon operates on pure .py files, executing them in cell-like segments. This shift in file format is supported by a dual-component system consisting of a VS Code extension and a dedicated background daemon. Under the hood, Tithon utilizes the standard ipykernel as its execution engine, ensuring that developers can leverage their existing Python environments and installed libraries without needing to reconfigure their dependency stacks.
To solve the problem of volatile output, Tithon integrates a SQLite database as its primary data store. Every cell output and execution state generated by the kernel is recorded in real-time within this database. This design ensures that execution results are physically persisted on disk rather than existing only as transient messages in a network stream. To deploy Tithon, users require Python 3.11 or higher and a Unix-based host environment. For those operating on Windows, the use of the Windows Subsystem for Linux (WSL) is recommended to maintain compatibility with the daemon's operational requirements.
Installation and environment setup are handled through the following commands:
pip install tithon
code --install-extension rnoro.tithonBreaking the WebSocket Dependency
The fundamental flaw in the traditional Jupyter experience is its reliance on WebSocket-based real-time delivery. In that model, the kernel and the client are tightly coupled via a stream; if the WebSocket connection severs, any output generated during the downtime has no path to reach the user. Even upon reconnection, there is no native mechanism to fetch the missed history, leaving the user to guess what happened during the blackout.
Tithon disrupts this pattern by implementing a three-stage lifecycle separation: VS Code, the Daemon, and the Python Kernel. In this hierarchy, the background daemon acts as an autonomous intermediary. If the VS Code extension crashes or is restarted, the daemon continues to manage the task independently. More importantly, the Python kernel runs as a separate process from the daemon itself. If the daemon needs to be restarted, the kernel process remains alive. By utilizing preserved reconnection metadata, Tithon can re-establish a link to the existing kernel, maintaining all active variables, loaded models, and imported modules without a full reset.
This structural divergence provides a significant advantage over existing workarounds. While running a Jupyter server inside tmux preserves the process, it does nothing to solve the WebSocket output loss problem. Similarly, extensions like jupyter-server-documents attempt server-side recovery but often struggle with HTML-based IPython widget rendering, such as tqdm.notebook, or fail to update repetitive output displays correctly. Tithon bypasses these rendering hurdles by treating SQLite as the single source of truth, reloading the entire output history from the database upon reconnection.
Beyond stability, the move from .ipynb to .py transforms the collaborative workflow. By stripping away the heavy JSON metadata inherent in notebook files, Tithon makes version control seamless. Developers can now use git diff to see actual code changes rather than wading through thousands of lines of JSON noise. This transition also creates a more AI-friendly environment. When coding agents or LLMs read a .py file, they can focus entirely on the logic without having to parse the structural overhead of a notebook format, reducing token waste and improving the accuracy of AI-driven edits.
This tool is particularly critical for deep learning practitioners running experiments that span several hours or days on unstable remote connections. The ability to drop a connection and return to a perfectly preserved state of execution removes the psychological burden of monitoring a remote session in real-time.
Developers who are tired of managing bloated notebook metadata in Git and who require absolute output reliability for long-running remote experiments should migrate from Jupyter to Tithon's daemon-based architecture.
