Schedule

In December 2001, a graduate student shared a few hundred lines of Python designed to make interactive computing a little less tedious. There was no grand plan for the future of interactive computing. It was simply someone building a better place for people to do their work.

That prompt grew into a rich shell, then an interactive notebook, then a global ecosystem. Twenty-five years later, Jupyter is how millions of people explore and share ideas, in classrooms, research labs, and quiet corners everywhere, tackling problems that have yet to be solved. All built by contributors spread across nearly every time zone.

Together, we’ll take this opportunity to celebrate our 25 year milestone. The past year alone brought real breakthroughs across the community: brand-new projects, long-standing technical hurdles finally cleared, and growth into areas we didn't anticipate. But as AI takes on more of the typing, new questions emerge about the future of interactive computing.

So what has enabled Jupyter to thrive for a quarter-century? And what comes next as the meaning of “human-in-the-loop” shifts beneath our feet? Join me to celebrate how far we've come and to explore what our next chapter might hold.

Jupyter's 2011 kernel design has aged well: Colab, VS Code, Deepnote, and even ChatGPT's Python tool all run Jupyter kernels today. The notebook itself, though, still runs on the same linear REPL as in 2011, and hidden state remains its most famous complaint. A generation of descendants (Observable, Pluto, marimo, Hex, Livebook, Deepnote) has spent a decade shipping fixes for these problems. It is past time for Jupyter core to steal from its children, but first it needs a survey of what they built.

This talk maps the significant new notebook features and illustrates them with demos:

• Reactive execution that ends hidden state
• The environment packaged inside the notebook file
• Cells that are SQL queries, live inputs, or forms that write code
• Notebooks laid out as canvases and graphs
• Notebooks as apps, as scheduled jobs, and as agent scratchpads

I'll close by arguing that opt-in reactive execution is the feature to steal first. Every implementation so far, including the ipyflow work presented at JupyterCon 2025, is tied to a single language. I'll share my in-progress design and prototype for adding reactivity to the kernel protocol, so that any kernel can implement it.

Biomedical researchers have the same AI agents as everyone else, but can't point them at their actual data. Patient records can't leave the medical center, so the agent never sees them. Institutions already host compliant model inference. The gap sits at the agent layer.

This talk covers how we use Biorouter to close that gap at UCSF and connect it to Jupyter. Biorouter is an open-source research agent that routes work across institutionally hosted, local, and commercial models, with the private and public boundary enforced in source, and MCP connectors into where the data lives: a 7-million-patient OMOP electronic health record database and the SPOKE knowledge graph. With the Jupyter integration, researchers keep the notebooks they already have and gain institutionally hosted inference plus clearance for protected health data.

I'll demo the integration and walk through one study it enabled: predicting hospitalization in a multiple sclerosis cohort from that database, from plain-English hypothesis to trained model (AUC 0.78).

This is infrastructure work as much as research. The pattern applies across genomics, clinical research, and other HIPAA-governed biomedical work.

Attendees will leave able to turn a persuasive notebook demo into a reproducible correctness gate for AI-generated CUDA and Triton kernels.

An AI-generated kernel can compile, run quickly, and match a reference on a few friendly tensors while still failing on boundary shapes, strides, aliasing, dtype extremes, special values, or reduction order. This talk builds the verification workflow as a Jupyter notebook: an independent CPU oracle, operator-aware input generation, explicit tolerances, deterministic seeds, environment capture, failure minimisation, and an exportable evidence bundle.

The notebook compares two public controlled studies. In one measured corpus, the harness detected all 10 seeded LLM-style defects while all 16 correct controls stayed clean, with matching verdicts across five GPU classes. A separate 26-operator study shows why boundary-focused inputs and aggressive adversarial values trade recall against false positives.

The point is not that notebooks prove production safety. It is that a notebook can make the experiment inspectable, replayable, and portable enough for another person to challenge before apparent speed becomes trusted code.

This session is intended to be a facilitated discussion about the opportunities and obstacles people encounter when trying to contribute to the Jupyter ecosystem from within a company.

SESSION FORMAT
We will begin with a brief framing of the question and a few common models for organizational participation in open source.

Most of the session will then be dedicated to experience-sharing among participants.

The final portion of the session will synthesize the discussions into 4 questions:
1. What gets in the way?
2. What is already working?
3. What could the Jupyter community try next?
4. What could companies try next?

Participants will leave with practical ideas they can bring back to their workplaces and their Jupyter projects.

INTENDED OUTCOME
The session is an opportunity to map how companies currently interact with the Jupyter ecosystem: where participation makes impact, where friction exists, and where relatively small changes could make contributing easier.
The discussion may provide a foundation for future guidance for Jupyter community leaders on how organizations and their employees can become better upstream participants in the ecosystem.

LLMs can summarize logs, explain failures, analyze configurations, and suggest fixes in seconds. But infrastructure engineering has an uncomfortable requirement: an answer that merely sounds correct isn't good enough.

In this session, I’ll use Jupyter to build and evaluate an AI-assisted infrastructure analysis workflow where LLM-generated conclusions are treated as hypotheses rather than facts. We’ll examine common failure modes including hallucinated root causes, missing context, incorrect correlations, and plausible but unsafe remediation suggestions.

Using Python and Jupyter, I’ll demonstrate a practical pattern that combines structured operational evidence, LLM reasoning, deterministic verification, and human review. We’ll also explore how notebooks make it easier to inspect intermediate reasoning artifacts, compare model outputs, reproduce failures, and evaluate changes to prompts and validation strategies.

Attendees will leave with practical patterns for deciding where LLMs add value in engineering workflows—and where conventional code should remain the source of truth.

When plotting in passagemath, I noticed that plots sometimes displayed text instead of an image. passagemath is a modular version of the math software SageMath. SageMath has its own display system, but the system is not in many notebook environments. I learned that IPython's DisplayFormatter collects the available representations and the notebook frontend chooses which one to display. In contrast, SageMath asks the frontend what it supports and renders just one thing. By adding reprsvg, reprpng, and repr_latex methods, IPython can collect those representations so plots and formulas now display in a plain ipykernel environment like Colab.

Jupyter notebooks are stored as JSON, which makes them error-prone to edit programmatically and expensive for AI agents to read as raw text or markdown. nb-cli (nb) is a fast, open-source, Rust-based command-line tool for reliably reading, editing, and executing .ipynb notebooks, whether or not a Jupyter server is running. It behaves consistently across every situation: local mode edits files directly and executes via a native ZeroMQ kernel client; remote mode syncs in real time with a running JupyterLab via Y.js, so changes appear instantly in open tabs; and gateway mode executes against a Kernel Gateway. Its default AI-Optimized Markdown format uses line-oriented sentinels with JSON metadata that agents parse deterministically, and content-addressed output externalization keeps large results out of the model's context window, cutting token cost while avoiding the corruption that plagues raw-JSON editing. This poster covers the format and architecture and shows how nb makes notebook automation reliable, fast, and token-efficient for both humans and agents.

Every team that tests systems handling sensitive data, patient records, financial transactions, or personal identifiers, faces the same tension: realistic data improves test quality, but copying production data into non-production environments creates real privacy and compliance risk under GDPR.

This session shares practical Test Data Management (TDM) strategies for building privacy-safe test datasets without sacrificing coverage. Drawing on experience testing large-scale healthcare, ETL, and enterprise systems, I will walk through four core techniques: data masking, synthetic data generation, data subsetting, and anonymization/pseudonymization, plus when production-derived data is still genuinely needed, such as reproducing rare defects or validating complex data relationships.

We will also cover the operational side: automating data provisioning in CI/CD pipelines, role-based access control, and audit trails to demonstrate compliance without slowing teams down.

Attendees will leave with concrete techniques for generating trustworthy, privacy-safe datasets, useful whether you build test suites, data pipelines, or notebook-based workflows touching sensitive data.

As AI-assisted workflows become central to interactive computing, notebook environments increasingly sit inside the AI/ML supply chain, exposed to risks like dependency confusion, model poisoning, and data lineage compromise. This talk applies enterprise AI security practices to the notebook-driven development lifecycle: from adversarial testing of models loaded into notebooks to tracing multi-hop exploit paths across dependencies, containers, and hybrid cloud deployments common in research and production pipelines.

Drawing on experience building AI security frameworks and running enterprise red teaming programs, the session outlines a practical approach for data scientists and platform teams to harden notebook workflows: securing third-party package dependencies, validating model provenance, and building resilience monitoring into experimentation environments without slowing research velocity.

Attendees leave with a lightweight threat model for their own Jupyter-based pipelines, a checklist for evaluating dependency and model risk, and a clear view of how enterprise AI security practices translate to open, reproducible computing environments.

Project Jupyter's future is being built in the open, but much of it lives outside the default install. This panel brings maintainers from multiple organizations to align on what's next.

We'll debate the foundational capabilities that would benefit everyone: disconnection-resilient execution (a reload never loses a running cell), robust real-time collaboration, native diffing, performance for large notebooks, and simpler, better-documented server APIs developers can build on without reverse-engineering. We'll look at the enterprise features (role-based access control, audit logging, SSO) that would bring organizations and their sponsorship back upstream instead of forking. Then the hard part: what does it take for a major feature to become official JupyterLab, and how do we streamline that path? We'll name the challenges holding us back; fragmented development, unclear ownership, duplicated effort and, time permitting, showcase community work that deserves a wider home: jupyterlab-git, nbdime, jupyter-collaboration, jupyter-ai, xtralab. We won't settle everything here; the aim is to spark discussions that continue afterward and eventually converge on a shared roadmap.

Starting a Jupyter notebook appears to be one simple action. At approximately 5,000 real notebook-server sessions on a typical day, that action becomes considerably more complex – especially because the workloads are not identical. Each notebook may require a different combination of CPU, memory, GPU capacity, container image, storage, and runtime configuration, with some resources available only in particular clusters.

This talk presents how we extended KubeSpawner to separate the JupyterHub control plane from the Kubernetes clusters where notebook servers run. We follow a notebook through its complete lifecycle: interpreting its resource requirements, selecting a suitable cluster, creating its pod and service in the correct context, observing startup, retrieving its endpoint, monitoring health, and terminating it safely.

We cover context-aware Kubernetes clients, per-cluster state tracking, progress reporting, timeout recovery, stale-state detection, and cross-cluster cleanup. The result is a reusable architecture that lets JupyterHub operate across bare-metal and managed cloud clusters without exposing infrastructure complexity to notebook users.

Kubernetes autoscaling is built for workloads that can be killed and rescheduled at any moment. A notebook is the opposite: its state lives in a running kernel, an eviction interrupts a person mid-work, and its GPU cannot be shared. We added GPU workspaces to jupyter-k8s, an open-source Kubernetes operator for Jupyter, and most of the hard questions turned out to be one question: which layer should own this knob, cloud instances, autoscaler, operator, infrastructure-as-code, or UI.

The talk walks through the answers as lessons: keeping CPU pods off GPU nodes (and cheap GPUs off expensive ones) with a label and a taint per pool; why consolidation that evicts running pods does not work for notebooks, and what refusing it costs in bin-packing; idleness as two layers that have to compose, workspace idle-shutdown and node scale-to-zero; templates as the unit of per-pool policy (bounds, defaults, idle rules) and the API contract traps we hit; and the decisions that are hard to reverse later, MIG partitioning and dynamic resource allocation.

The lessons apply to any Jupyter on Kubernetes, including JupyterHub. We close with where jupyter-k8s sits next to JupyterHub and the roadmap.

JupyterGIS is an in-development ecosystem project to enable collaboration and reproducibility in Geospatial Science. Cartographers, designers who specialize in representing spatial data, are not the users it was most obviously built for, but I'd argue they may be a major component of its first serious userbase.

Professional cartographers do surprisingly little of their work in GIS. They use it for cleaning, filtering, and basic symbolization, then hand off to a design tool for the bulk of the work. This works fine, but only until the data is too large to bring down to a laptop. However, the earth scientists they work with have already solved this with hubs like CryoCloud. Until recently, cartographers had no purpose-built way to join them there.

I'll make a map start to finish to show what it looks like when they can. Working with JupyterGIS in CryoCloud, I'll cut a cryospheric dataset down to only the geometry the design calls for, then finish in a local design tool to plug back into the cartographic workflow.

I posit that desktop GIS users may not be the first to switch to our Jupyter-native toolkit. Instead, designers will follow their empirical collaborators onto the hub.

In The Voices of JupyterHub (https://voicesofjupyterhub.orgmycology.com) ethnographic report, the JupyterHub leadership team identified that our community "struggles with onboarding new contributors and delegating responsibility", and that "project management, prioritization, and triage processes are a source of stress for maintainers and confusion for newcomers". Building on those findings, through a stakeholder engagement workshop at JupyterCon 2025, and a dedicated hybrid event in February 2026, our team have been improving our roadmapping practices. We adopted a process developed by 2i2c for their internal team coordination (https://2i2c.org/roadmap), and now align our tasks with published "initiatives" (https://github.com/jupyterhub/roadmap/issues). Collaboration Cafes and Hub Dash events give users and new contributors clear pathways to join and shape the direction of JupyterHub by endorsing or adding new initiatives. In turn, our maintainers coordinate their work more effectively and know who benefits from their efforts. In this talk, I will guide the audience through the process of defining an initiative, and how we keep the roadmap as an ever updating, living set of goals.

Frontier labs pay millions for a single RL environment representing one high-value task: software engineering, cybersecurity, project management. That closed industry is a big part of why frontier agents perform.

This talk is a field guide to cracking it in the open. I'll cover how the environment business works, from research and reporting; the open source counterparts, Prime Intellect, TRL, and OpenEnv; and an end-to-end walkthrough of training a cybersecurity agent for free. You'll leave knowing how to find, build, and share environments for the tasks you care about, without paying a vendor.

Why me: I'm a core maintainer of OpenEnv, the open source environment standard backed by Hugging Face, Meta-PyTorch, NVIDIA, Microsoft, and Prime Intellect. It integrates with all major training frameworks.

Word Error Rate is often treated as the final answer when evaluating speech recognition models. But a single aggregate score can hide where a model actually fails.

In multilingual and conversational speech, two models with similar WER can behave very differently across dialects, code-switching, acoustic conditions, speaking styles, and data sources.

In this talk, I will show how Jupyter can turn model evaluation from a static benchmark into an interactive and reproducible investigation. Using multilingual automatic speech recognition as a case study, we will build an evaluation workflow that moves from WER and CER to semantic metrics, dataset slices, error categories, and inspection of individual failures.

I will also share lessons from evaluating speech models across Bengali and Hindi datasets, where aggregate metrics alone often failed to explain important differences between models.

The goal is not to introduce another leaderboard. It is to show how notebooks can make AI evaluation easier to inspect, reproduce, extend, and challenge.

Attendees will leave with a practical framework they can adapt to evaluate their own models and datasets.