Panel Is a Local Research Workspace Where AI Works Alongside You

Panel is a research workspace where an AI agent works beside the user, with chat, files, PDFs and notebooks in one dock. The repository was published on 15 September 2026. GitHub repository

The interface is organized around multiple configurable windows called Panes. They can display image files, data files, code and chat sessions side by side, rather than forcing research material through a single chat transcript. Specific Pane types cover files, PDFs, markdown and Jupyter notebooks.

Notebooks run against a real kernel, the engine that actually runs the code, and both the user and the agent can edit in it. Execution state is therefore shared instead of being split between human and model.

That shared approach extends to viewing. The agent can create custom viewers and apps when necessary, including writing a new Pane for content a built-in Pane cannot show. Visualization and inspection are not limited to a fixed set of file handlers. If the current Panes cannot render something, the agent is expected to build one that can.

Underneath, Panel is described as a local web app where everything runs on the user's machine. It pairs a Vue plus dockview frontend with a Python FastAPI sidecar, a small helper service that drives agent backends, and the dockable panes themselves are built with dockview. Hacker News discussion Everything runs locally. Dependencies stay explicit.

For agent support, the project currently centers on one harness. Full support requires Claude Code installed and signed in. Codex and other agent harnesses are not yet supported.

There is also an early Module system. Modules have typed inputs, outputs and intermediates, meaning defined entry points, exit points and checkpoints, a structure intended to make multi-step research workflows repeatable rather than ad hoc. The working Module is literature review, with an early version for hypothesis generation. Examples cited in discussion include agent-built custom panes such as a protein structure viewer and an SQLite browser. The project is MIT licensed, which permits free reuse with attribution.

The broader context here is what locality, shared execution and an extendable interface allow in daily research work. A local runtime keeps large datasets, PDFs and notebook state on the machine doing the work, which avoids moving awkward files through a remote service. A kernel writable by both sides avoids the case where the human cannot see or repair what the model ran. Typed Modules point toward prompts hardened into interfaces with inspectable intermediates. In my view, worth flagging is the maintenance cost that comes with that flexibility. Each generated viewer is also code to trust, update and debug, though strict Module inputs and outputs help. Teams adopting this pattern will need to review machine-written interface code with the same care given to machine-written analysis. If that discipline holds, the workspace can grow with the project instead of constraining it.