Dashboards are where most questions about a model get answered. The loss curve, the eval score, the comparison across a sweep: a good Workspace shows you these at a glance. The questions that decide whether a model ships are usually one step past that. Why did this slice regress? Which examples fail, and what do they have in common? Is the pattern causal or an artifact of how the data was collected? Answering them means writing code to slice and visualize the data you're already looking at.
Today we're announcing CoreWeave Notebooks, now available in CoreWeave Forge. A notebook opens from your project, already connected to your experiments, artifacts, and evaluation results, and gives you Python and SQL to shape that data into the analysis the question requires. Notebooks run on marimo, the open source reactive Python notebook, so every output reflects the current code without stale cells. And they're saved to the project and listed alongside your teammates' notebooks, so anyone on the team can copy one, see the analysis with the data attached, and build on it.
Finding what was averaged away
Here's a quick example from our demo notebook. A driving model is trained to stop at red lights, and its aggregate traffic-light loss looks fine. But the training data has attributes the dashboard doesn't chart by default: weather conditions, time of day, whether there's another red object in the frame near the light.
Here's what we uncovered in a notebook.
Every weather condition sits near the floor, except one. In hard rain at night, with a red object near the light, loss is much higher than anywhere else. The next cell sorts the selection by loss and lays out the worst frames.
The worst frames are the same scene: rain, darkness, a traffic light, and a red building or truck beside it. In daylight the model tells them apart without trouble. In the rain at night it can't.
The interesting failure is almost never visible in the aggregate. It shows up when you can slice by an attribute and visualize it in a way nobody thought to put on the dashboard, and sort to the worst cases to see why. That's what a notebook next to your data is for.
Starts connected to your project
Open a notebook from any project in Forge and it's already authenticated and pointed at that project's data. Query training metrics across your experiments, load an evaluation table from an artifact, filter it to the examples you care about, and start analyzing in the first cell. Standard panels cover the common views; the notebook covers the question the panel didn't anticipate.
Reactive, so what you see is what your code produced
CoreWeave Notebooks use marimo, an open source reactive Python notebook. marimo builds a dependency graph from variable references. When a variable changes, dependent cells run automatically, or can be marked stale for expensive computations. Delete a cell and its variables are removed from program memory. This keeps code, program state, and visible outputs aligned.
That behavior matters in debugging. An investigation changes one assumption at a time: the run set, a threshold, a data slice, a time window. Reactive execution updates every dependent view, so an old output never survives beneath new code and sends the investigation in the wrong direction.
It also makes exploration interactive. Add a slider, a dropdown, or a table filter and the notebook responds as you move it. In the driving example, a weather selector re-renders the loss chart and the worst-frames grid together, so testing a hypothesis is a matter of moving a control rather than editing and rerunning cells.
Built to be shared
Notebooks are stored in the project, not in someone's local files. Every project has a listing page where all of the team's notebooks appear together, so anyone can open a colleague's notebook with the data attached, read the investigation, and copy it as a starting point for their own. Forge also lists notebooks across your projects in one view, so prior analysis is discoverable rather than buried on a laptop.
When the next round of experiments comes in, you open the same notebook and rerun it on the new data. A one-time investigation becomes the team's regression check.
Part of the AI Loop
CoreWeave Notebooks are part of CoreWeave Forge, where the questions change as you move through the loop. Before training, it's running exploratory data analysis on your dataset to check for gaps and duplicates. Mid-training, it's diagnosing an experiment that diverged from its baseline. At evaluation, it's finding the failure mode the aggregate score averages away. Notebooks give you one place to answer each of these, with Python, next to the data in your Forge project.
What's next
Notebooks at public preview are built for interactive analysis next to your data. Over the coming months we're extending them in three directions. Publishing a view from a notebook back to your wWorkspace as a persistent panel, so a custom analysis can sit beside the standard ones. Hosting notebooks as data apps, interactive dashboards anyone on the team can use without opening the code, from a labeling tool to a sliceable view of the team's results. Bringing more compute to the notebook sandbox, so data science teams can train the forecasting and classification models they build every day directly in a notebook rather than only analyzing them there. And CoreWeave ARIA, the AI Research and Iteration Agent in Forge, will co-author notebooks with you. Describe the view you need and ARIA writes the cells, so you don't have to be fluent in pandas and plotting libraries to build the chart you need.
Get started
Open Notebooks from any project in Forge, or start from the getting started page. CoreWeave Notebooks are powered by marimo; to learn more about reactive execution, see the marimo documentation.
