Welcome back to another edition of our monthly Positron updates! Each month we share highlights from our latest release and useful resources. Last release we told you about several major features that came out of preview to general availability, including the new notebook editor. This milestone we are excited to share new functionality for SQL support, reproducible authoring, helping you know when packages are missing, and more.

Data Connections

Data Connections is our new way to work with SQL and database-like resources in Positron, from local files and database servers to cloud data warehouses. It is currently available as a preview feature, and you can enable it with the dataConnections.enabled setting. This release more than doubles the number of data sources you can reach. Amazon Redshift, Snowflake, Databricks, and Posit Connect pins join the existing DuckDB, PostgreSQL, and SQLite support.

The panel itself is more capable as well. Refresh and Refresh All reload the tree while preserving what you have expanded, briefly highlighting the rows that were reloaded. Open connections now show an indicator. Collapsing a connection in the UI keeps you connected to your data source, while anything you’ve previewed with the Data Explorer stays still open. When you remove a connection, Positron asks for confirmation and reports how many Data Explorers will close with it.

Data Connections is still an experimental preview, and your feedback continues to shape it. Tell us which databases and warehouses you need, and anything confusing, missing, or broken, in the Data Connections discussion.

Inline output for Quarto

Inline output for .qmd documents came out of preview last release, and this release brings you a substantial round of polish for this way of working. Be aware that the Quarto settings have moved into a dedicated quarto.* namespace with its own group in the Settings editor. The previous positron.quarto.* keys still work but are deprecated, and Positron will prompt you to update your settings.

Before a kernel starts, the kernel status names the interpreter it will start and offers an explicit Start Kernel action. When a cell fails, Fix and Explain buttons send the error to Posit Assistant, matching the Positron notebook experience. The editor also scrolls to reveal output as it is produced, which you can turn off with the new quarto.inlineOutput.autoScroll setting.

Output renders more faithfully as well. The editor gutter now shows which statement is currently executing and per-statement progress. Positron draws images at your display’s pixel ratio, so plots are sharp on retina screens, and Python figures now respect the fig-width and fig-height cell options.

HTML widgets no longer stick in the editor corner when you scroll past them, or trap scrolling instead of letting the document scroll. HTML widgets no longer render as raw HTML after a reload, and collapsed output no longer springs back open when its cell re-runs. Running code in a Quarto document also pins the editor tab now, so Positron does not silently close the document and its session when you open another file.

AI model providers

Positron now reads AI model provider configuration from a single providers.json file rather than a scattered set of settings. The new release will migrate your existing configuration automatically when you start it, and deprecates the authentication.* and positron.assistant.provider.*.enable settings in favor of it. Two new commands give you direct access: Open AI Provider Settings (JSON) opens providers.json from the Command Palette, and Migrate Provider Settings to providers.json runs the migration on demand.

Install missing packages

Positron now notices when your code refers to a package you do not have installed and offers to install it for you. The prompt appears for packages referenced by your scripts and notebooks in both R and Python.

A library() or import call for something missing becomes a single click instead of an error you have to go resolve by hand.

Performance and memory

We continue to invest in the memory footprint, performance, and reliability of Positron. Several components now load only when they are actually needed, and turning off ai.enabled now means Positron never loads some heavy AI-related components at all. We fixed a cluster of long-standing reliability problems around session restarts and lifecycles.

Startup and editing are faster as well. R and Python kernels start much faster on Windows systems with aggressive antivirus software. The interpreter session picker appears immediately instead of waiting for interpreter discovery to finish. We also fixed slow typing, formatting, and saving in long R and Python files.

What’s coming next

• Join our upcoming webinar on August 26 to learn about AI governance in Posit Workbench.
• We are looking forward to posit::conf(2026) next month, where our team will have several sessions on Positron. Register now to join us in person in Houston or virtually from anywhere in the world.

Kimi K3 is currently the most capable open weights model out there. In our internal testing, it feels somewhere between Opus 5 and Fable 5, and is notably well-rounded compared to other open weights releases. It’s priced at the same price-per-token as Claude Sonnet 5.¹

GLM 5.2 excels at agentic coding and less so at data analysis tasks. Because the model is not vision-capable, it cannot ‘see’ plots and thus feels less capable for data science work. Its per-token pricing is also similar to Haiku 4.5, but feels something like Opus 4.6 or Sonnet 5 for agentic coding tasks.

Pricing

The models in Posit AI today, at a glance:

The cost savings are greater than the per-token pricing differences alone might suggest. For one, the Claude 5 series models use a tokenizer that results in substantially more tokens (~35%) per word than Kimi K3’s or GLM 5.2’s tokenizer. Also, users are not billed at a higher rate for Cache writes than ’normal’ input tokens; all input tokens are written to the cache by default, but we can’t make a guarantee that you’ll hit the cache after any specific delay between requests. In practice, we’ve seen that the cache efficiency of conversations with these deployments is slightly lower than with Claude models.

Get started

To get started, open up Posit Assistant and update when prompted! Then, select your model of choice under the Posit AI model provider. If you’re not already a Posit AI subscriber, you can learn more here.

It’s worth saying that we suspect these models will rotate somewhat regularly in the service; as the months go by, we plan to introduce support for new models and deprecate others.

cuda.ml is for data scientists who work primarily in R and want to use a GPU without moving their modeling workflow to Python or learning low-level GPU APIs. Version 0.4.0 is a substantial update to the package. It makes installation much simpler, expands tidymodels support, adds more ways to run tree-ensemble models, and makes it straightforward to save and restore supported fitted models.

Install from CRAN

For most users, setup is two commands:

install.packages("cuda.ml")
cuda.ml::cuda_ml_install()

The package from CRAN is a regular, portable R package. cuda_ml_install() downloads and verifies the matching compiled backend and GPU libraries, then keeps them in a cache for later R sessions. On a supported system, you do not need to compile cuda.ml from source, configure a Python environment, or assemble the GPU libraries yourself.

The result is a familiar R package workflow: install the package, prepare its supporting libraries once, and start an analysis. The extra installation call is explicit because the GPU libraries are much larger than the R package. Repeated calls reuse the completed cache, and loading cuda.ml itself is quiet and does not initialize CUDA.

Prebuilt support is available for Linux x86_64 with glibc 2.28 or newer. GPU operations require a supported NVIDIA GPU and driver 580 or newer. On Windows, install and run R inside a compatible WSL2 Linux distribution. See the installation guide for the complete system requirements and source-build options.

Use familiar modeling interfaces

cuda.ml registers parsnip engines for linear, logistic, and multinomial regression, random forests, nearest neighbors, and radial, polynomial, and linear support-vector machines. For example, this fits a random-forest classifier on the GPU using the standard parsnip interface:

library(cuda.ml)
library(parsnip)

forest_spec <- rand_forest() |>
  set_mode("classification") |>
  set_engine("cuda.ml")

forest_fit <- forest_spec |>
  fit(class ~ ., data = modeldata::hpc_data)
predict(forest_fit, modeldata::hpc_data[1:5, ], type = "prob")

# A tibble: 5 × 4
  .pred_VF .pred_F .pred_M  .pred_L
     <dbl>   <dbl>   <dbl>    <dbl>
1    0.309  0.597  0.0666  0.0275
2    0.899  0.0838 0.0138  0.00335
3    0.965  0.0261 0.00850 0.000883
4    0.973  0.0228 0.00416 0.000352
5    0.966  0.0298 0.00416 0.000352

set_engine("cuda.ml") selects the GPU-backed cuda.ml engine; the rest is a standard parsnip workflow. Recipes can learn preprocessing on the training data and carry it into resampling and prediction.

Work directly with cuda.ml

cuda.ml also provides a direct R interface. This is useful when you prefer a function-oriented workflow or want to use the package on its own.

library(cuda.ml)
library(ggplot2)

clusters <- cuda_ml_kmeans(scale(faithful), k = 2)
faithful$cluster <- factor(clusters$labels)

ggplot(faithful, aes(eruptions, waiting, color = cluster)) +
  geom_point(size = 2.5) +
  labs(
    x = "Eruption duration (minutes)",
    y = "Waiting time (minutes)"
  ) +
  theme_minimal()

The direct API covers supervised models as well as clustering and dimensionality reduction, including DBSCAN, k-means, PCA, tSVD, UMAP, and t-SNE. It also includes stochastic-gradient-descent regression, the hyperbolic-tangent SVM kernel, and external tree-ensemble inference.

Run tree ensembles on a GPU or CPU

This release expands where and how you can make predictions with tree ensembles. The new nvForest support powers prediction for random forests trained with cuda_ml_rand_forest() and can load trained XGBoost models, LightGBM text models, and Treelite checkpoints. Once a model is loaded, the API provides standard prediction along with model information, leaf identifiers, individual-tree predictions, and checkpoint import and export.

GPU inference uses the complete cuda.ml installation. A deployment that only needs CPU inference can prepare a smaller, CUDA-free backend:

cuda.ml::cuda_ml_install(device = "cpu")

The CPU backend can run a cuda.ml random forest trained on a GPU as well as a supported external tree ensemble. The complete installation can also run these models on a CPU, so the smaller backend is an optional deployment choice.

Save and deploy fitted models

cuda.ml 0.4.0 expands model persistence for training, analysis, and deployment workflows. Supported fitted models can be saved to a compressed file, restored in another R process, stored as raw bytes, or wrapped with the bundle package.

The simplest file workflow passes a path directly:

model <- cuda_ml_rand_forest(
  class ~ .,
  data = modeldata::hpc_data,
  trees = 100
)

cuda_ml_serialize(model, "hpc-runtime-forest.cuda-ml")

In another R process or deployment environment, prepare cuda.ml and restore the fitted model:

library(cuda.ml)

cuda_ml_install()
model <- cuda_ml_unserialize("hpc-runtime-forest.cuda-ml")

predict(model, modeldata::hpc_data[1:5, ], type = "class")

File paths use gzip compression. Passing connection = NULL instead returns the state as an uncompressed raw vector of bytes, which is convenient for object stores and database BLOB columns. The blob package can represent raw vectors for database workflows, and the bundle package is supported for teams that already use bundled model artifacts.

Persistence is available for linear models, logistic and multinomial regression, PCA, SVC and SVR models, UMAP, random forests, and nvForest models. cuda.ml checks the saved state and required backend before restoring it. For an nvForest-backed model, the restore call can select CPU or GPU inference.

Highlights for users upgrading from cuda.ml 0.3

This is a breaking update to the earlier package. The most visible changes are:

• The random-forest API now uses mtry for predictor sampling and sample_fraction for row sampling. trees defaults to 100, and an omitted seed draws from R’s random-number generator, so set.seed() controls the fit.
• Linear, logistic, and multinomial regression now use numeric penalty and mixture arguments that match parsnip. Logistic and multinomial regression are unregularized by default.
• normalize_input was removed from the linear-model functions. It previously requested GPU-side L2 normalization. Use explicit preprocessing such as recipes::step_normalize() when centering and scaling are appropriate; but please note, the two operations are not numerically identical.
• cuda_ml_sgd() now fits squared-loss regression only. Its loss argument was removed, and n_iters_no_change is now n_iter_no_change.
• The former FIL interface has been replaced by nvForest. Random projection and the KNN IVFSQ index have no replacement in the pinned upstream API.

See the full changelog for the complete list of API changes.

The guides cover first steps and more complete examples:

• Get started with cuda.ml
• Use cuda.ml with tidymodels
• Save and restore models
• nvForest inference and deployment

Welcome to our newsletter, posit::glimpse()!

If you’re currently reading this on our blog, consider subscribing to Product Updates - Open Source on our subscription page to receive this newsletter directly in your inbox.

Every month, we round up some of the most important open-source news for Posit’s community! We hope that you enjoy this newsletter and maybe even share it with a friend.

The table of contents on the right can help you navigate through all the updates. As you scroll, it will open up to show you subcategories →

Announcements

Register for posit::conf(2026)

Register for our annual conference, posit::conf(2026), happening September 14-16 in Houston and online! The amazing speakers and workshops will make for a wonderful time. Register for posit::conf here.

For the first time, the live streams will feature automatically translated subtitles, available in French, German, Italian, Portuguese, and Spanish.

Tidy Dev Day is on September 17, a unique opportunity to collaboratively tackle open-source issues and work directly alongside the very developers who build and maintain the tools you use every day. Learn more about Tidy Dev Day here.

Migrating to Connect Cloud

A thank-you to everyone who published on rpubs.com, quartopub.com, shinyapps.io, and bookdown.org. We’re consolidating all our publishing tools into one: Posit Connect Cloud. Connect Cloud is built to handle all of the content types in one place, with one account, and we hope to make your transition as smooth as possible.

• Learn more in the Migrating to Connect Cloud: Posit’s unified publishing solution blog post.
• Join our webinar on the migration process happening September 9th.

Key product updates and new releases

httr2 1.3.0

httr2 is a comprehensive HTTP client for R for working with web APIs. httr2 1.3.0 introduces a breaking change to OAuth token caching that requires one-time re-authentication. Recent patches added 200x faster streaming for short-line responses, OAuth server metadata discovery, OpenTelemetry tracing support, and httr2_translate() for converting requests to curl commands.

• Read more in the httr2 1.3.0 blog post.

ir 0.1.0

Introducing ir 0.1.0, a command-line tool for running self-describing R scripts and Quarto documents with embedded package dependencies and R version requirements, inspired by Python’s PEP 723 and uv run --script. The tool supports isolated environments, CRAN snapshot dates, mixed R/Python workflows, and caches resolved dependencies for efficiency, enabling one-file workflows without full project structures.

• Read more in the ir 0.1.0 blog post.

lorax

lorax introduces a unified interface for characterizing tree- and rule-based models across 12 implementations including ranger, XGBoost, LightGBM, and random forests. The package enables extracting decision rules, identifying active predictors, converting trees to partykit format for visualization, and accessing variable importance scores through consistent APIs that work across diverse tree model packages.

• Read more in the Introducing lorax: Speaking for the Tree-Based Models blog post.

mcptools 1.0.0

mcptools, an R SDK for the Model Context Protocol, is now on CRAN. It brings image support for rich content in both directions, native authenticated remote server connections eliminating the npm dependency, and streamlined Posit Connect deployment via _server.yml. This R SDK for the Model Context Protocol enables deploying R functions as MCP servers and fetching third-party MCP tools as R functions.

• Read more in the mcptools 1.0.0 blog post.

Quarto 1.10

Quarto transforms Markdown, code, and computational output into publication-ready articles, reports, presentations, websites, and books. Version 1.10 introduces offline HTML accessibility checking with bundled axe-core and WCAG conformance level targeting, plus localized string support for template authors. The release includes important fixes for quarto preview reliability, shortcode resolution in math expressions, and updated dependencies including pandoc 3.10 and typst 0.15.1.

• Read more in the Quarto 1.10 blog post.

raghilda v0.2

Raghilda is a Python package for building RAG (Retrieval-Augmented Generation) solutions. This release focuses on production-ready features for scaling RAG pipelines, with crawl and ingest API with caching and concurrency, a CloudflareCrawler for JavaScript-rendered sites, a PostgreSQL store backend, and NVIDIA NIM embeddings.

• Check out the raghilda v0.2 blog post.

roxygen2 8.1.0

roxygen2 8.1.0 improves performance with consolidated importFrom() directives that reduce package loading time from ~120ms to ~9ms for 1,000 imports, and introduces the rdtools package for faster cross-reference resolution during documentation generation. The release also adds multi-line support for @importFrom directives with hanging indents.

• Check out the roxygen2 8.1.0 blog post.

Shiny updates

Shiny is the framework for building interactive web applications in R and Python. Shiny for R 1.14 adds startApp() for non-blocking app launches and session$destroy() for proper module cleanup. Shiny for Python 1.7 includes bundled Agent Skills for coding agents and test mode with live JSON snapshots. bslib 0.12 introduces offcanvas panels that slide in from viewport edges, plus direct sidebar handle resizing.

• Read more in the Shiny updates blog post.

Positron learning resources

The Positron team is on a roll. Here are the key features from the July Release Highlights:

• The Positron Notebook Editor now serves as the default option for .ipynb files: You get a fully integrated experience for Jupyter Notebooks out of the box. Key tools like environment management, version control, and AI coding support work automatically the moment you open any .ipynb file.
• The Packages pane has officially transitioned out of preview status: Inspect, update, and explore installed libraries without leaving your IDE or relying on Terminal commands.
• Posit Assistant has reached general availability: AI assistance is enterprise-ready: enjoy full-fledged coding assistance, debugging help, and inline explanations directly in your workflow with improved stability and performance.
• Support for opening Excel workbooks has been added to Data Explorer: No need to export to CSV or switch to Microsoft Excel to check your data: preview, filter, inspect .xlsx sheets directly inside Positron before running any code.
• Enhanced language intelligence for R: Navigating large R projects is much faster and less error-prone with features like Go to Definition, Find References, and Rename Symbol that work across all packages and scripts in your workspace. Diagnostics update instantly even when files change externally.

The team has also shared several blog posts packed with tips and tricks for getting the most out of Positron:

• Discover how Positron paired with uv configures your Python environment in just one click
• Explore strategies for seamlessly managing your R and Python environments within Positron

Let’s learn about AI

You can now receive the AI newsletter via email! Paste the newsletter’s RSS feed URL into a free RSS-to-email service like https://blogtrottr.com/ to receive the newsletter by email.

• AGENTS.md, Skills, MCP servers, oh my! If you’ve heard all these terms and want to investigate the differences, check out the July 3rd edition of the AI Newsletter.
• LLMs often miss subtle visual artifacts in data visualizations, and there are ways of evaluating their oversights. Learn about bluffbench in the July 17th edition of the AI Newsletter.
• Posit Assistant in Positron now includes an EDA log feature to help you keep track of exploratory analysis done with the agent. Learn more in the July 31st edition of the AI newsletter.

Do you want event recordings? You got them!

“Will this be recorded?” If it is, you can access our recordings directly on the event pages, and we do our best to post them as quickly as possible.

Be sure to catch the presentations featured below, including Teun van den Brand’s session on ggsql and Rich Iannone’s presentation on Great Docs:

Jun 30, 2026 | 12 min | 2.1k views

DuckCon #7 – ggsql: A grammar of graphics for SQL (Teun van den Brand)

Event: DuckCon #7 (DuckDB and DuckLake community conference), https://duckdb.org/events/2026/06/24/duckcon7/ Speaker: Teun van den Brand (Posit PBC) Slides: https://blobs.duckdb.org/events/duckcon7/teun-van-den-brand-ggsql.pdf

Teun Van den Brand

ggsql

Jul 6, 2026 | 1h 5min | 114 views

Great Docs: The Future of Documentation | The Python Exchange June 2026

About the Python Exchange for the Department of Energy: https://meetup.doepy.org/ Sign up here to be notified when the next Python Exchange is scheduled: https://bit.ly/py-exchange Guest Panelist: Rich Iannone Title: Great Docs: Building the Documentation Site Generator I Always Wanted Bio: Rich Iannone Rich is a software engineer and someone who cares a great deal about documentation and summary tables. He’s been working on table presentation and documentation packages for quite a long time, and nobody has told him to stop yet, so he’s still on top of all that. He started off mostly creating open-source packages in R, but more lately, he’s been doing open-source things in Python. Rich really enjoys creating all these packages because he realizes that people can use ’em to do great things in their own work. Abstract: Documentation generators have, for me, been a thing where there are so many trade-offs. They might make beautiful sites, but be shallow feature-wise. Or full of features but really hard to configure. After some years of working across R, Python, and the broader open-source ecosystem, I started Great Docs with a simple end goal: your docs should look really great, be easy to discover, and be ready for the AI era. In this presentation, I will walk through the various places I drew inspiration for Great Docs (pkgdown, MATLAB, Elixir, and the Vue.js docs). I’ll show how Great Docs makes documentation consumable by both humans and AI agents through Skills and MCP server documentation. I’ll share some of the features I obsessively built because I wanted them in my own package docs. Finally, I’ll discuss where this project is headed beyond Python (toward documenting CLIs, TUIs, and more). At Don’t Use This Code, we want to create a unique opportunity to see Python succeed and thrive within the DOE. In collaboration with an organizing committee of Python users and advocates from various DOE sites, we host regular conversations on the topic of Python in order to create a new resource for scientists, researchers, and technical staff. Our goal is to share best practices and build a strong, lasting community for Python users within the Department of Energy National Lab system. If you, or someone you know, might make a great panelist, we’d love to get in touch! Just send us an email at DOEPy@dutc.io if you would like to participate or have any questions

Rich Iannone

Great Docs pkgdown

Additionally, we have some fantastic recordings from the Data Science Lab. Watch the Lab Managers share their expertise while live coding:

Jul 24, 2026 | 51 min | 48 views

Live TidyTuesday Data Viz Workflow | Nicola Rennie | Data Science Lab

The Data Science Lab is a live weekly call. Register at pos.it/dslab! Discord invites go out each week on lives calls. We’d love to have you! The Lab is an open, messy space for learning and asking questions. Think of it like pair coding with a friend or two. Learn something new, and share what you know to help others grow. On this call, Libby Heeren is joined by Nicola Rennie, who walks through her process for making a TidyTuesday data visualization in R: live coding a chart from scratch and sharing the workflow tricks she’s built up over five years of doing TidyTuesday! Nicola takes this week’s TidyTuesday “twin cities” dataset and builds a colorful sunburst (radial) chart from scratch, showing how she decides what to plot, wrangles the data with dplyr, and makes it pretty using showtext fonts, rcartocolor palettes, colored-text legends, and the ggview package for previewing plots at exactly the size they’ll save at. Along the way she shares the templates and helper packages she’s made to save time every week (can you tell she’s a pro?!). Since TidyTuesday data is public, you can grab the same dataset and follow along, too! Hosting crew from Posit: Libby Heeren, Isabella Velasquez Socials and websites: Nicola Rennie’s blog: https://nrennie.rbind.io/ Nicola Rennie’s GitHub: https://github.com/nrennie Nicola Rennie’s Bluesky: https://bsky.app/profile/nrennie.bsky.social Nicola Rennie’s LinkedIn: https://www.linkedin.com/in/nicola-rennie/ Nicola Rennie’s Mastodon: https://fosstodon.org/deck/@nrennie Resources mentioned in the video and chat: Nicola’s code from this session: https://nrennie.rbind.io/talks/posit-ds-lab/ TidyTuesday on GitHub: https://github.com/rfordatascience/tidytuesday Nicola’s templates package: https://github.com/nrennie/templates showtext package (fonts in R): https://github.com/yixuan/showtext ggview package (preview plots at save size): https://github.com/idmn/ggview rcartocolor package (accessible color palettes): https://nowosad.r-universe.dev/rcartocolor ggtext package (styled/colored text): https://wilkelab.org/ggtext/ ggiraph package (interactive ggplots): https://davidgohel.github.io/ggiraph/ marquee package (markdown text in R graphics): https://marquee.r-lib.org/ Nicola’s book, The Art of Data Visualization with ggplot2: https://nrennie.rbind.io/art-of-viz/ Bootstrap Icons: https://icons.getbootstrap.com/ okpalette (extract a palette from a photo): https://okpalette.color.pizza/ ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co Hangout: https://pos.it/dsh The Lab: https://pos.it/dslab LinkedIn: https://www.linkedin.com/company/posit-software Bluesky: https://bsky.app/profile/posit.co Thanks for hanging out with us! Timestamps 00:00 Introduction 01:18 Reviewing the TidyTuesday twin cities dataset 03:41 Demoing TidyTuesday template files and R package setup 07:25 “Do showtext and systemfonts do different things?” 09:04 Loading and prepping the links and cities datasets 11:45 Exploring and filtering the dataset to a chosen city 17:25 Demoing a Shiny app to copy previous TidyTuesday chart code 23:56 Demoing sunburst chart creation with coord_radial 25:47 “Can you say why you used mutate rather than summarize?” 31:09 Adding custom colors with the rcartocolor package 33:57 Demoing colored subtitle text with the ggtext package 40:38 Attempting to make the chart interactive with the ggiraph package 43:32 Adding automated social and source captions 46:26 “So you can save a plot with the canvas call and it doesn’t mess up the ggplot object?” 49:55 “If people would like to keep up with you and see your posts, what’s the best way to do that?”

dplyr ggplot2 Shiny systemfonts

Jul 23, 2026 | 56 min | 1.1k views

Mind-Blowing Quarto Slide Extensions 💬 🖍️ 🤯 | Emil Hvitfeldt | Data Science Lab

The Data Science Lab is a live weekly call. Register at pos.it/dslab! Discord invites go out each week on lives calls. We’d love to have you! The Lab is an open, messy space for learning and asking questions. Think of it like pair coding with a friend or two. Learn something new, and share what you know to help others grow. On this call, Libby Heeren is joined by Emil Hvitfeldt, who walks through the art of “slide crafting” in Quarto and shows off the collection of Reveal JS extensions he’s been building to make slides way more fun and powerful. Emil starts with the basics of building slides in Quarto with the Reveal JS format (fragments, columns, a little CSS) and explains how Quarto extensions differ from packages. Then he shows off the good stuff: iMessage-style chat bubbles hand-drawn “rough notation” highlighting and annotations ️ the Flourish extension for animating code chunks, gorgeous reusable themes, and his in-progress “editable” extension that lets you drag, resize, and restyle slide elements right in the browser and save the changes back to your source. And, spoiler, his “editable” extension is much further along as of the publishing of this video!! If you’ve ever fought with slide layouts, there is definitely something here you can try at home! Hosting crew from Posit: Libby Heeren, Isabella Velasquez Emil’s socials and urls: website: https://emilhvitfeldt.com/ GitHub: https://github.com/emilhvitfeldt Bluesky: https://bsky.app/profile/emilhvitfeldt.bsky.social LinkedIn: https://www.linkedin.com/in/emilhvitfeldt/ Resources mentioned in the video and chat: Emil’s GitHub (home of his Quarto extensions): https://github.com/EmilHvitfeldt quarto-revealjs-editable extension: https://github.com/EmilHvitfeldt/quarto-revealjs-editable quarto-revealjs-rows extension (shared by Emil after the session): https://github.com/EmilHvitfeldt/quarto-revealjs-rows Quarto Reveal JS documentation: https://quarto.org/docs/presentations/revealjs/ Quarto Reveal JS demo slides: https://quarto.org/docs/presentations/revealjs/demo/#/title-slide News! Quarto 2 (Quarto in Rust): https://quarto.org/docs/blog/posts/2026-04-06-whats-next-quarto-2/ Dynamic Tabsets in Quarto (Josh Cowley): https://josh.quarto.pub/posts/2022-11-10-quarto-tabsets-update/2022-11-10-quarto-tabsets-update.html Embedding Reveal JS via iframe (Quarto source example): https://github.com/quarto-dev/quarto-web/blob/main/docs/presentations/revealjs/index.qmd#L12-L14 posit::conf 2026: https://conf.posit.co/2026/ R/Medicine conference: https://rconsortium.github.io/RMedicine_website/ Muntasir Masum’s slides repo: https://github.com/muntasirmasum/epi553-data-viz Example Quarto slides — Nicola Rennie (Styling Charts): https://nrennie.rbind.io/MFC-CDT-data-viz/slides/styling-charts-r.html Example Quarto slides — Colin Madland: https://cmadland.github.io/slides/ Colin Madland’s slides repo: https://github.com/cmadland/slides Example Quarto slides — Raha Dastgheyb (R/Medicine 2024): https://rdastgh1.quarto.pub/rmedicine-2024-scidatareportr/#/title-slide ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co Hangout: https://pos.it/dsh The Lab: https://pos.it/dslab LinkedIn: https://www.linkedin.com/company/posit-software Bluesky: https://bsky.app/profile/posit.co Thanks for hanging out with us! Timestamps 00:00 Introduction 01:22 Demoing a primer on Reveal JS slides in Quarto 05:11 “Does that PDF export still use Pandoc, or is there an option of exporting via Typst?” 08:17 Demoing slide crafting with a new Quarto document 11:24 Demoing how to download and use a Quarto template 14:01 “Is this UI you’re using for slide generation exclusive to Positron?” 16:16 Demoing how to install a Quarto extension from the terminal 18:45 “Is there a maximum number of columns you can have?” 19:18 Demoing adding custom CSS classes to slide columns 23:03 “Do we know if extensions will still be submitted to the OpenVSX marketplace?” 25:11 “Are these Quarto extensions global, or are they per project?” 27:42 “When you change the text fonts inside those columns, could you do it for all the columns at once, maybe by changing the top div?” 29:31 “Do you also get grid logic like you have with CSS Grid?” 31:54 Demoing Quarto VS Code extensions for autocomplete and shortcodes 34:32 Demoing the chat bubbles extension 37:38 Demoing the rough notation extension for highlighting text fragments 40:20 Demoing the Flourish extension for highlighting code chunks 43:07 Demoing the editable extension for dragging and adjusting slide elements 49:28 Demoing custom Reveal JS slide themes 52:26 “Is there a Quarto extension that can help dynamically create tabs or chunks?” (see dynamic tabs link in the resources above!) 53:58 Explaining the default code chunk highlighting feature in Quarto 55:11 “How do you embed a Reveal JS site into another Quarto document?”

Emil Hvitfeldt

Positron Quarto revealjs

We hope you learn a lot from these resources!

Showcases from the community

We love learning what you are up to. If you have a project using our tools to share, please let us know. In particular, I’d love to hear how you’re adopting and using Positron! Find me on LinkedIn and Bluesky.

Alfredo H. S. shared a small, opinionated skill for turning papers and other source material into concise Quarto RevealJS presentations with AI coding agents.

Try it out, and let Alfredo know how it goes!

• Forum discussion
• About the skill
• SKILL.md

REYL Intesa Sanpaolo’s Risk Management team built their own Incident Management Tool with Shiny and Posit Connect, cutting incident follow-up from days to 30 minutes. Now, they’re eyeing the same R-and-Connect pattern for liquidity monitoring, credit risk appetite, and stress testing.

• Check out the spotlight

Interested in testing your regression skills? Angela Heberger is looking for feedback on RelationLab, an interactive Shiny app for learning correlation and regression. Give it a shot and let Angela know what you think!

• Forum discussion
• Shiny app

We usually find these projects on social media. If you’re on LinkedIn, be sure to follow and tag Posit Open Source for us to share the amazing things you’re working on!

What’s next

Besides posit::conf (have you registered for conf yet? You should!), we have lots of goodies on the horizon.

• Emil Hvidtfelt is leading a 2-hour workshop all about making great slides in Quarto on Aug 12th. Register here!
• Join us for an upcoming Data Science Hangout or Data Science Lab.

I would love to know how to make the Glimpse newsletter better. Email me at isabella [dot] velasquez [at] posit.co.

install.packages("roxygen2")

This is a small release, and the two main changes are about performance: one makes your package load faster for your users, and one makes documenting faster for you. You can see the full list of changes in the release notes.

Merged importFrom() directives

@importFrom used to generate one importFrom() directive per symbol. Now it generates a single multi-line directive per package:

# before
importFrom(utils,URLdecode)
importFrom(utils,URLencode)
importFrom(utils,head)
importFrom(utils,tail)

# after
importFrom(utils,
  URLdecode,
  URLencode,
  head,
  tail
)

We made this change because we discovered that the number of importFrom() directives in your NAMESPACE has a surprisingly large effect on loading time. loadNamespace() does a chunk of per-directive work, so the cost grows with the number of directives, not the number of symbols. Importing 1,000 functions with 1,000 separate directives costs around 120ms; importing the same 1,000 functions with one directive per package costs around 9ms, the same as importing 10.

Of course, most packages import far fewer than 1,000 objects. But library() costs are paid by every user, on every session, and they’re cumulative: loading a package also loads its dependencies. Merging the directives removes the cost for the user entirely, at little cost to you as the developer: just one noisy NAMESPACE diff.

My colleague Kevin Ushey also fixed a related annoyance: @importFrom, @importClassesFrom, and @importMethodsFrom once again accept multi-line input, so you can spread a long list of imports over several lines for readability. You’ll just need a hanging indent on the continuation lines.

Faster documenting with rdtools

The other change helps developers, rather than users: documenting a package with lots of cross-references is now considerably faster.

The bottleneck was topic resolution: every time roxygen2 sees a link like [dplyr::filter()], or needs to work out which package an unqualified [filter()] refers to, it has to ask “does this package have a topic with this alias?”. Previously roxygen2 answered that question by calling utils::help(), which takes about 1.5ms. That doesn’t sound like much, but to resolve an unqualified link roxygen2 has to check every dependency plus the base packages, which adds up. On a link-heavy package like testthat, that meant roughly half of the total time spent documenting was just looking up cross-references.

The fix is to stop asking one question at a time, and to cache each lookup. Installed packages already ship an alias index (help/aliases.rds), and packages loaded from source have one maintained by pkgload, so all the information needed is available in bulk — it just needs to be read once and kept in a hash table, rather than rediscovered on every query.

That logic now lives in a new package, rdtools, which provides cached lookup of help topics and aliases across installed, source, and in-development packages, along with efficient retrieval of parsed Rd objects. Pulling it out of roxygen2 deleted a decent amount of fiddly code that I’d also implemented (to varying levels of quality) in pkgdown and downlit.

Acknowledgements

A big thanks to everyone who helped make this release possible! @aphalo, @DavisVaughan, @dragosmg, @etiennebacher, @gadenbuie, @hadley, @jan-swissre, @jemus42, @jranke, @kevinushey, @lionel-, @mcol, @MichaelChirico, @peterdesmet, and @thisisnic.

install.packages(c("shiny", "bslib"))

pip install -U shiny

The highlights: bundled agent skills that teach coding agents how to write Shiny for Python apps, startApp() for running R apps without blocking your console, offcanvas panels that slide in from the edge of the viewport, and destroy() for cleaning up dynamic modules.

Full details are in the Shiny for R release notes, the bslib release notes, and the Shiny for Python changelog.

Agent skills

Shiny for Python only — coming to R soon.

Coding agents are writing more and more Shiny apps — so we’re teaching them how to do it well. Shiny for Python v1.7 ships with bundled Agent Skills: a shiny-for-python skill whose SKILL.md routes agents to focused reference files covering each area of Shiny’s public API — reactivity, Express mode, modules, layouts, plots, data frames, chat and streaming, extended tasks, testing, debugging, OpenTelemetry, and more.

To install the bundled skills into your coding agent, use library-skills:

uvx library-skills --claude

Because the skills ship inside the package, they always match the version of Shiny you have installed — and shiny skills list shows what’s bundled.

Now your agent stops hand-rolling HTML tables and fake tabs, and starts using the framework the way you would.

Non-blocking apps

Shiny for R only.

runApp() blocks your R console until the app stops. New in Shiny v1.14, startApp() runs the app in the background and hands control right back to you:

# Start app in the background
handle <- startApp("myapp")

# The console remains available
handle$status()
#> [1] "running"
handle$url()
#> [1] "http://127.0.0.1:7365"

# Stop the app
handle$stop()

The returned ShinyAppHandle has stop(), status(), url(), and result() methods. Starting a new app automatically stops the previous one, so iterating is as simple as calling startApp() again.

This is handy for interactive development, but it really shines for anything that needs to drive an app and keep working: testing tools, coding agents, or scripts that launch an app, interact with it, and shut it down.

That’s the tooling around your app. The next two features are about the app itself — starting with a new way to keep UI off screen until someone asks for it.

Offcanvas panels

An offcanvas is a panel that slides in from an edge of the viewport — perfect for settings, filters, details-on-demand, or anything else that doesn’t need to be on screen all the time. It’s built on Bootstrap 5’s offcanvas component and comes with the full set of server verbs: show_offcanvas(), hide_offcanvas(), and toggle_offcanvas().

The simplest way to use one is with a trigger element — no server code required:

library(shiny)
library(bslib)

ui <- page_fluid(
  offcanvas(
    "Panel content goes here.",
    title = "Settings",
    trigger = actionButton("open", "Open settings")
  )
)

from shiny.express import ui

ui.offcanvas(
    "Panel content goes here.",
    title="Settings",
    trigger=ui.input_action_button("open", "Open settings"),
)

Give the panel an id and it becomes fully programmable: control it from the server and reactively respond to whether it’s open.

library(shiny)
library(bslib)

ui <- page_fluid(
  actionButton("toggle", "Toggle details"),
  offcanvas("Panel content", title = "Details", id = "details")
)

server <- function(input, output, session) {
  observeEvent(input$toggle, toggle_offcanvas("details"))

  observeEvent(input$details, {
    message("Panel is open: ", input$details)
  })
}

shinyApp(ui, server)

from shiny import reactive
from shiny.express import input, render, ui

ui.input_action_button("toggle", "Toggle details")

ui.offcanvas("Panel content", title="Details", id="details")


@reactive.effect
@reactive.event(input.toggle)
def _():
    ui.toggle_offcanvas("details")


@render.text
def state():
    return f"Panel is {'open' if input.details() else 'closed'}"

Panels can slide in from the left, right, top, or bottom, and you can even build one entirely in the server and reveal it with show_offcanvas() — no UI placement needed.

Offcanvas panels are available now in Shiny for Python v1.7 and in bslib v0.12 for R. See the offcanvas() (R, Python) reference for the panel itself, and show_offcanvas(), hide_offcanvas(), and toggle_offcanvas() (R, Python) for controlling it from the server.

Module cleanup

An offcanvas hides UI that’s already there. Creating and destroying UI on the fly is a different problem, and modules make it easy to add UI and server logic dynamically. Removing them has always been the awkward part: removeUI() takes the HTML away, but the module’s observers, reactive values, and outputs keep running behind the scenes — leaving behind “dangling reactivity”.

The session’s new destroy() method (R, Python) closes that gap. The parent that inserted a module can now clean it up by the same id it used to insert it — no cleanup handles to pass around:

# In the parent server
observeEvent(input$add, {
  insertUI("#container", ui = myModuleUI("editor"))
  myModuleServer("editor")
})

observeEvent(input$remove, {
  removeUI(selector = "#editor")
  session$destroy("editor")
})

@reactive.effect
@reactive.event(input.add)
def _():
    ui.insert_ui(my_module_ui("editor"), selector="#container")
    my_module_server("editor")


@reactive.effect
@reactive.event(input.remove)
async def _():
    ui.remove_ui(selector="#editor")
    await session.destroy("editor")

Destroying a scope invokes all of its registered onDestroy() (R) / on_destroy() (Python) callbacks, cleaning up reactive values, expressions, observers, inputs, and outputs for that module and its descendant modules. Everything is scoped, so the parent session and sibling modules are untouched. And a module can call destroy() on its own session (no id) to clean up after itself.

If your app inserts and removes modules over a long-lived session, destroy() keeps those removed modules from accumulating as memory and reactivity leaks.

Test mode

Shiny for Python only.

Back to agents for a moment. The bundled skills teach them how to write your app; test mode, also new in v1.7, lets them — and your tests — see inside it while it runs. Enable it with the SHINY_TESTMODE=1 environment variable (or App(test_mode=True)), and each session serves a live JSON snapshot of its input, output, and exported values.

The snapshot is only served when test mode is enabled, and by default it includes only inputs and outputs. To surface an internal reactive — a reactive.calc or reactive.value that never reaches the UI — export it with export_test_values():

from shiny import reactive, render
from shiny.express import input, ui
from shiny.testmode import export_test_values

ui.input_slider("n", "N", min=0, max=100, value=20)


@reactive.calc
def doubled() -> int:
    return input.n() * 2


@render.text
def txt() -> str:
    return f"n * 2 = {doubled()}"


# Surface the internal reactive in the test-mode snapshot. This is a no-op
# unless test mode is enabled, so it's safe to leave in production code.
export_test_values(doubled=doubled)

The pytest app fixtures (local_app, create_app_fixture) enable test mode automatically, and the new shiny.playwright.controller.AppTestValues controller reads the snapshot in end-to-end tests. Expectations accept exact values or predicates:

def is_even(value):
    return value % 2 == 0

app_values = controller.AppTestValues(page)
app_values.expect_export("doubled", 40)
app_values.expect_export("doubled", is_even)

Test mode mirrors R’s long-standing exportTestValues() — and it gives coding agents a structured way to debug a running app directly from the server instead of inferring information from the UI.

New to testing Shiny apps? Start with Unit testing and End-to-end testing on the Shiny for Python website, then browse the testing API reference.

Other improvements

A few more changes worth a quick mention — the full lists are in the release notes for Shiny for R v1.14.0, bslib v0.12.0, and Shiny for Python v1.7.0:

R

• downloadButton() and downloadLink() gain an enabled argument. The default, "auto", automatically enables the button once the download is ready.
• Output resize and visibility detection now uses native browser observers (ResizeObserver, IntersectionObserver), so plot sizing and hidden-state tracking work in any layout — including CSS-only show/hide and non-Bootstrap frameworks.
• conditionalPanel() no longer briefly flashes its contents on app start when the condition is initially FALSE.
• bslib v0.12 also lets you grab the sidebar handle directly to resize a sidebar, and fixes the resize handle indicator for position = "right" sidebars.

Python

• @render.download_button and @render.download_link pair 1:1 with ui.download_button() and ui.download_link(), replacing the now-deprecated @render.download.
• The shiny[otel] extra now sets up OpenTelemetry zero-code auto-instrumentation out of the box: opentelemetry-instrument shiny run app.py.

In closing

We’re excited to see what you build (and clean up) with these releases. As always, if you have questions or feedback, join us on Discord or open an issue on rstudio/shiny or posit-dev/py-shiny. Happy Shiny-ing!

Acknowledgements

A big thank you to all the folks who helped make these releases happen:

Shiny for R v1.14.0

@adit-0132, @ahnungslos-git, @byronvickers, @cpsievert, @cuckooland, @djacob65, @dmurdoch, @elnelson575, @FBrockmeyer, @gadenbuie, @HenrikBengtsson, @IvanM26, @jcheng5, @jeffkeller-einc, @jeis4wpi, @JohnCoene, @JosiahParry, @karangattu, @klin333, @lachlansimpson, @lionel-, @marcosnav, @mconflitti-pbc, @ml-ebs-ext, @nbenn, @Noskario, @prinjos, @pyltime, @rikivillalba, @roberson4627-cpu, @samuelbharti, @schloerke, @shikokuchuo, @simon-smart88, @toph-allen, and @Upipa.

bslib v0.12.0

@AleKoure, @ArthurAndrews, @averissimo, @elnelson575, @etiennebacher, @gadenbuie, @jeis4wpi, @LeonidasZhak, @lgaborini, @lgschuck, @sawelch-NIVA, @sims1253, and @willgearty.

Shiny for Python v1.7.0

@chernojagne, @cpsievert, @eeshsaxena, @elnelson575, @EltonChang1, @FBruzzesi, @gadenbuie, @hutch3232, @JosiahParry, @karangattu, @kb071216, @kbzsl, @marcosnav, @mariameraz, @MukundaKatta, @mvanhorn, @nightcityblade, @pevolution-ahmed, @QuintonBaker-USDA, @saisharan0103, @SamEdwardes, @schloerke, @slupczynskim, @Steven314, and @tomaioo.

Quarto 1.10 is dominated by fixes, as much of our development effort is now going into Quarto 2, but there are some improvements we wanted to point out: more refined HTML accessibility checks, and access to Quarto’s localized strings for template authors.

You can read about these improvements and the most important fixes below. You can find all the changes in this version in the Release Notes.

Accessibility Checking Improvements

Since Quarto 1.8, setting the axe option on HTML documents runs axe-core accessibility checks on your rendered document. Quarto 1.10 makes these checks easier to rely on.

Checking works offline. Quarto now bundles its own copy of axe-core instead of loading it from a CDN in the reader’s browser. Accessibility checking works without a network connection, and viewing a rendered document no longer triggers a request to an external CDN. The axe-core version is unchanged, so results are identical.

Check against a WCAG conformance level. The new standard option scopes checks to a WCAG conformance level, including rules axe-core keeps off by default for that level. The best-practice option controls whether axe’s best-practice rules, recommendations not required by any WCAG success criterion, are also checked:

format:
  html:
    axe:
      standard: wcag21aa
      best-practice: true

A clearer report. When using output: document, violations are now listed first by impact, then WCAG conformance level. The report overlay also received its own accessibility and styling fixes: it can be scrolled with the keyboard, uses theme and brand independent colors, and no longer inherits page styling like text centering.

Learn more at HTML Accessibility.

Localized Strings in Templates

If you write custom Pandoc templates or template partials, you can now use Quarto’s localized strings through the new quarto.language template variable namespace. Quarto resolves each string for the document’s language and exposes it as a template variable:

$quarto.language.toc-title-document$
$quarto.language.crossref-fig-title$

This lets templates honor the document’s lang option without hard-coding text. For example, the orange-book Typst book extension now uses these variables in its running headers, so a book with lang: fr gets Chapitre rather than Chapter.

Learn more at Localized Strings in Templates.

Other Important Fixes

• quarto preview reliability—a long-standing bug that showed stale HTML for non-index pages is fixed, changes to a document’s format: are detected on the first render after the edit, a _brand.yml added or removed during preview is picked up, and transient .quarto_ipynb files no longer accumulate on disk.

• Shortcodes—shortcodes are now resolved inside inline and display math expressions.

• PDF font fallbacks—mainfontfallback, sansfontfallback, and monofontfallback no longer crash LuaLaTeX on TeX Live 2026, and a missing fallback font is now installed automatically.

• Typst fonts—fonts not installed locally are filtered from CSS font-family fallback lists before they reach Typst, suppressing unknown font family warnings, alongside a batch of fixes to Quarto’s CSS-to-Typst translation.

• Chrome Headless Shell—the quarto install chromium command, deprecated in 1.9, now transparently redirects to chrome-headless-shell, quarto check install warns about legacy Chromium installs, and arm64 Linux is now supported.

• Output for LLMs—fixes for websites with llms-txt enabled: headings and shortcodes inside conditional content, and clean-URL rewriting of index.html.md links.

Dependency updates:

• pandoc updated to 3.10
• typst updated to 0.15.1
• deno updated to 2.7.14
• dart-sass updated to 1.101.0
• esbuild updated to 0.28.1

Acknowledgements

We’d like to say a huge thank you to everyone who contributed to this release by opening issues and pull requests:

AlexLietard, ArthurRudolph, Artmann, C-Monaghan, ChrisJefferson, CoryMcCartan, DCEW, DrFloLinke, Guest-1013, MBe-iUS, MurzNN, ThierryO, ThomasFaria, TinasheMTapera, Voorhoeve, alderete, andrewheiss, barendgehrels, basm92, blauzo, chainsawriot, crisbour, cs-res-pub-ser-st, dustinstoltz, eculler, eneveu, github-actions[bot], gregswinehart, hwine, ianpittwood, ihrke, jdonaldson, jiangyun-fun, jidanni, jkrumbiegel, jnkatz, jph00, jtkulas, juleswg23, juliohm, kazuyanagimoto, kelli-rstudio, lsbjordao, luismmontilla, maelle, maucejo, memeplex, micedre, multimeric, nathant181, neilernst, nessan, nickvigilante, nrennie, pbosetti, reckoner, rgouveiamendes, robjhyndman, sbwiecko, seandavi, sebastiansauer, skyfroger, songwupei, stefkuypers, stragu, tiagojct, victorrssx, widlarizer, wlatendresse, xuefeng-xu, yasyf, zinc75.

The hammer and wrench emoji in the listing and social card image for this post comes from OpenMoji– the open-source emoji and icon project. License: CC BY-SA 4.0

The log summarizes findings for different areas of exploration and keeps track of next steps. To use the log, run the /eda-log slash command after you’ve started the EDA process.

Why we made this

Exploratory data analysis, the open-ended orientation to your data that often comes before anything else, can be a branching, nonlinear process. There are many questions you can ask of your data, and new areas of inquiry can open with each question you ask. Because of this, it is often hard to keep track of what you’ve looked into, where that code lives, and what you want to explore next.

Historically, the EDA process was limited by how quickly you could write code and interpret the output. Coding agents like Posit Assistant lift the first of those constraints. They can carry out EDA far faster than you can on your own, which can exacerbate the issue of keeping track of what you’ve explored.

This speed also introduces a new problem: the point of EDA is typically for you, the human, to understand your data, but coding agents can produce output faster than you can absorb it. If the agent completes an analysis but you haven’t understood the insights in the data, the exploration process hasn’t really happened.

Posit Assistant already has various features that tackle this problem, including an exploratory mode of interaction where it runs shorter turns and stops more frequently to involve the user.

The EDA log is another lightweight tool for the same goal. It keeps a running summary of what you and Posit Assistant have explored, helping your understanding keep pace with the agent’s and giving you a clearer picture of what’s already been done.

Details

Here’s what the EDA log looks like in action:

At a high level:

• When you run /eda-log, Posit Assistant will create a log for the exploration done in the conversation so far. The log then opens in the editor area in Positron.
• The underlying logs are stored as YAML files in .posit/assistant/eda-logs/, next to where plans are stored.
• Posit Assistant is instructed to loosely keep the log up to date as the conversation progresses, but you can also manually trigger an update at any time with the “Refresh” button.
• Clicking the arrow next to an area scrolls you back to the spot in the conversation where that insight originated, so you can revisit the code and context that produced it.
• Suggested next steps appear as clickable text. Clicking one sends it to Posit Assistant as your next message.
• The creation of an EDA log is always user-triggered. Posit Assistant will never create one on its own.
• The feature is currently only in Positron, but will come to RStudio soon.

Recent past newsletters

• Which models are best at spotting data quality problems?
• How to choose between AGENTS.md, skills, and MCP servers

Subscribe via RSS

Data scientists are often forced to choose between the simplicity of the classic Jupyter notebook experience and the advanced capabilities of a general-purpose IDE. With the 2026.07 release, you no longer have to choose: Positron now delivers a first-class Notebook Editor inside an IDE built for data science.

If you’re new to Positron, here’s what the Notebook Editor is like in your daily work.

Environment management

You clone your colleague’s repo and try to rerun their notebook. Which Python version do you use? What dependencies do you install and which versions? Did you previously set up an environment that you could reuse? You’re faced with all of these questions before you’ve run a single line of code.

Positron has several built-in workflows to help you manage your environments. When you open a repo, Positron discovers your installed environments, suggests the right one for the repo, and prompts you to set up a new environment if needed. The active environment is displayed front and center; click to restart or switch environments. Positron uses the same environment across your Jupyter and Quarto notebooks, scripts, and consoles. You can see inside your environments, which packages are installed, their versions, whether newer versions are available, and you can upgrade them. Environments are first-class citizens of Positron. Explore Positron’s environment management.

Interactive data exploration

When you run a cell in your notebook, your variables appear in the Variables Pane. Filter, sort, and search your data in the Data Explorer, and try out plot variations in the Visualize wizard. You can easily convert your point-and-click interactions into code by using the copy-code feature to bring them back into your notebook. If you get stuck, look up library documentation in the Help Pane. All of this works out of the box.

Streamlined version control

Notebooks store outputs and execution metadata alongside code, which is great for sharing but does not work well with version control. Positron includes settings to exclude outputs and execution metadata from the saved file, so the diff is just your code change. Explore the custom settings to clean up your git diffs.

Your notebooks stay ordinary .ipynb files and the editing experience stays classic Jupyter. When a plain-text workflow suits you better, conversion to and from .ipynb and other formats is built in.

AI assistance

Posit Assistant sees your notebook as more than just text. It works with the live session behind the notebook: your variables, your data, your plots. Ask it to fix a chart and it can inspect the dataframe, look at the plot itself, edit the cell, and run it again. It does the same things you would do, using the same panes you use. Explore notebook-aware AI assistance in Positron.

Get started

Download Positron and open a project with a Jupyter notebook. The Notebook Editor is now on by default. If you’re coming from another IDE, your existing .ipynb files will open as-is without any conversion needed.

For the full feature reference, check out our documentation.

If you run into any issues or have ideas on how we can improve Positron, reach out on GitHub.

Already using Positron? Everything in this release is in the release notes.

Thank you so much for helping us build Positron’s Jupyter notebook support from the ground up by chatting with us live, sharing your pain points, and giving us feedback on GitHub!

The problem is that many packages store the tree’s splits in different ways or offer incompatible APIs to access different characteristics. lorax helps capture this information for many different implementations.

You can install the CRAN version of lorax via

install.packages("lorax")

or get the development version using

pak::pak("tidymodels/lorax")

Let’s start by using the ranger package to create a random forest model using the food delivery data in the modeldata package. For illustration, the trees will be coerced to be more shallow than usual so that we can better plot them using the min.node.size argument:

library(tidymodels) # <- to easily get dplyr, tidyr, ggplot2, etc
library(ranger)
library(lorax)

set.seed(872)
rgr_fit <-
  ranger(
    time_to_delivery ~ .,
    data = modeldata::deliveries,
    num.trees = 1000,
    min.node.size = 5000,
    importance = "impurity"
  )

rgr_fit

Ranger result

Call:
 ranger(time_to_delivery ~ ., data = modeldata::deliveries, num.trees = 1000,      min.node.size = 5000, importance = "impurity") 

Type:                             Regression 
Number of trees:                  1000 
Sample size:                      10012 
Number of independent variables:  30 
Mtry:                             5 
Target node size:                 5000 
Variable importance mode:         impurity 
Splitrule:                        variance 
OOB prediction error (MSE):       24.26389 
R squared (OOB):                  0.4879119 

Visualizing the Trees

lorax contains methods for the as.party() function in the partykit package. This enables us to use all of the methods from that package. For example, plot.party() is an excellent visualization tool for the tree. Random forest has many trees and we can plot any of them:

rgr_fit |>
  as.party(tree = 1, data = modeldata::deliveries) |>
  plot()

rgr_fit |>
  as.party(tree = 100, data = modeldata::deliveries) |>
  plot()

rgr_fit |>
  as.party(tree = 1000, data = modeldata::deliveries) |>
  plot()

Which Predictors Were Used?

Since trees automatically conduct feature selection as the model is trained, it helps to know which ones are actually used by the model. The active_predictors() function does just that:

rgr_vars <- active_predictors(rgr_fit, tree = 1:1000)
rgr_vars

# A tibble: 1,000 × 2
   active_predictors  tree
   <list>            <int>
 1 <chr [4]>             1
 2 <chr [5]>             2
 3 <chr [3]>             3
 4 <chr [4]>             4
 5 <chr [4]>             5
 6 <chr [3]>             6
 7 <chr [3]>             7
 8 <chr [7]>             8
 9 <chr [3]>             9
10 <chr [6]>            10
# ℹ 990 more rows

# The column names are in a nested vector:
rgr_vars$active_predictors[[1]]

[1] "day"     "hour"    "item_10" "item_23"

# We can expand the list too:
rgr_vars |>
  unnest(cols = c(active_predictors))

# A tibble: 4,306 × 2
   active_predictors  tree
   <chr>             <int>
 1 day                   1
 2 hour                  1
 3 item_10               1
 4 item_23               1
 5 day                   2
 6 distance              2
 7 item_10               2
 8 item_12               2
 9 item_26               2
10 hour                  3
# ℹ 4,296 more rows

How often are predictors used?

rgr_vars |>
  unnest(cols = c(active_predictors)) |>
  count(active_predictors) |>
  arrange(active_predictors)

# A tibble: 30 × 2
   active_predictors     n
   <chr>             <int>
 1 day                 516
 2 distance            507
 3 hour                623
 4 item_01             329
 5 item_02             131
 6 item_03              57
 7 item_04              66
 8 item_05              26
 9 item_06              92
10 item_07              91
# ℹ 20 more rows

How many predictors are used in each rule (on average)? A rule is the full logical statement that defines the path to the terminal nodes.

rgr_vars |>
  mutate(num_vars = map_int(active_predictors, ~ length(.x))) |>
  summarize(mean_num_vars = mean(num_vars))

# A tibble: 1 × 1
  mean_num_vars
          <dbl>
1          4.31

Many packages can compute variable importance scores for each predictor but each has a different interface. The lorax package has an accessor function to pull these from the model called var_imp():

var_imp(rgr_fit)

# A tibble: 30 × 2
   term     estimate
   <chr>       <dbl>
 1 hour     108892. 
 2 day       16054. 
 3 distance  25689. 
 4 item_01     673. 
 5 item_02      86.3
 6 item_03      30.4
 7 item_04      43.7
 8 item_05      11.0
 9 item_06      50.1
10 item_07      55.2
# ℹ 20 more rows

Examining Rules

We can also get detailed information on the model’s rules (for each tree). Using the same ranger model fit:

rgr_rules <- extract_rules(rgr_fit, data = modeldata::deliveries)
rgr_rules

# A tibble: 5 × 3
     id rules       tree
  <int> <list>     <int>
1     3 <language>     1
2     5 <language>     1
3     7 <language>     1
4     8 <language>     1
5     9 <language>     1

# With components
rgr_rules$rules[[1]] |> class()

[1] "call"

rgr_rules$rules[[1]]

item_23 <= 0.5 & hour <= 14.6645

We can compute on these and/or use them to determine which specific data were contained in the terminal node:

modeldata::deliveries |> filter(!!rgr_rules$rules[[1]])

# A tibble: 2,415 × 31
   time_to_delivery  hour day   distance item_01 item_02 item_03 item_04 item_05
              <dbl> <dbl> <fct>    <dbl>   <int>   <int>   <int>   <int>   <int>
 1             16.1  11.9 Thu       3.15       0       0       2       0       0
 2             19.6  13.0 Sat       3.35       1       0       0       1       0
 3             17.4  11.9 Sun       2.75       0       2       1       0       0
 4             18.0  12.1 Tue       2.4        0       0       0       1       0
 5             22.1  14.4 Thu       2.69       0       0       0       0       0
 6             17.6  12.9 Sat       2.47       0       1       0       0       0
 7             17.0  12.3 Sat       3.88       0       0       0       0       0
 8             19.5  13.5 Tue       3.55       0       0       0       0       0
 9             17.6  12.9 Fri       2.88       0       0       1       1       0
10             21.6  14.3 Sat       3          0       0       0       1       0
# ℹ 2,405 more rows
# ℹ 22 more variables: item_06 <int>, item_07 <int>, item_08 <int>,
#   item_09 <int>, item_10 <int>, item_11 <int>, item_12 <int>, item_13 <int>,
#   item_14 <int>, item_15 <int>, item_16 <int>, item_17 <int>, item_18 <int>,
#   item_19 <int>, item_20 <int>, item_21 <int>, item_22 <int>, item_23 <int>,
#   item_24 <int>, item_25 <int>, item_26 <int>, item_27 <int>

A List of Methods

Here are the details of which models and methods are supported in the first CRAN version:

Note that as.party.rpart() is in the partykit package and that cforest is made out of party objects.

What’s Next?

We’ll work on adding CatBoost models to the list of supported methods. Please add an issue if there are other aspects of trees that should be quantified in these models.

Today we are announcing the first public release of ir, a small command-line tool that runs R scripts and renders Quarto documents using runtime requirements declared in the file itself.

ir is for one-file workflows that do not quite need a project but still need to be easy to share and rerun later. Simply put the package requirements, and optionally the R version, next to the code. When you render or execute the file, ir resolves the requirements, prepares cached package libraries, and launches R or Quarto with a runtime ready to use.

The interface is inspired by PEP 723 and uv run --script. A script can carry enough metadata to describe its runtime, and the runner can resolve that runtime into a cached environment on demand. ir brings that pattern to R scripts and Quarto documents, using pak, renv, and rig on the R side, and reticulate’s uv-backed helper when Python is part of the runtime.

ir focuses on two workflows:

• running or rendering self-describing scripts and documents
  (ir run, ir render)
• running or installing command-line tools distributed through R packages
  (rx, ir tool install)

Why ir?

R scripts often begin as small, local utilities: a report, a data pull, a model-training or evaluation run, a quick diagnostic, or an example shared with a colleague. Over time, the script can become important, but the setup still lives somewhere else: in a README, in a shell history, in a project library, or in the author’s current R installation.

ir makes the runtime specification part of the source file. That means a script can say, directly:

• which packages it needs
• which R should run it, when that needs to be explicit
• whether user libraries should be visible
• whether CRAN packages should be resolved as of a specific date

This should help you rerun the script reliably at a later date. Keeping the metadata in the file makes it less likely to be lost or fall out of sync with the code.

How ir fits with existing tools

ir sits alongside the R tools people already use and builds on several of them directly:

• rig installs, removes, and switches between R versions on macOS, Windows, and Linux. ir calls rig when a file requests a specific R version, or when date-only exclude-newer needs to select the latest R minor version available on that date. rig is optional for files that only declare packages.
• pak is a fast package installer with a built-in solver. ir uses pak to resolve the dependency graph from a file’s declared packages and fetch them from the appropriate repositories. pak is bootstrapped automatically on first use, so you do not need to install it separately.
• renv gives R projects isolated package libraries and lockfiles. ir uses renv’s global package cache to assemble reusable libraries without creating a renv project or lockfile.

ir builds on that stack for non-project workflows: resolving the runtime for a self-describing script or Quarto document, and running or installing command-line entry points distributed by R packages.

A self-describing R script

Here is a complete script:

#!/usr/bin/env -S ir run
#| packages:
#|   - dplyr>=1.0
#|   - tidyr
#| isolated: true
#| exclude-newer: "2024-01-15"

library(dplyr)
library(tidyr)

mtcars |> count(cyl, gear) |> pivot_wider(names_from = gear, values_from = n)

Run it with:

$ ir run script.R

Or, on macOS and Linux, make it executable and run it directly:

$ chmod +x script.R
$ ./script.R

The metadata block is YAML written in #| comments after an optional shebang. ir reads that metadata, resolves the declared packages with pak, materializes a package library with renv, and starts R with the resolved library at the front of .libPaths().

By default, user libraries remain visible as a fallback. Add isolated: true in the file, or use --isolated at the command line, to run without the user library.

Running R package tools with rx

The ir release also includes rx, a short alias for ir tool run that runs executables provided by R packages.

Package authors can expose command-line entry points through standard package subdirectories such as exec/ and bin/. Files in exec/ can be regular Rscript files, Rapp apps, or direct executable scripts. rx resolves the package, finds the requested executable, and runs it in an isolated library.

For example, this resolves the btw CLI from the btw R package on demand and runs btw --help:

$ rx btw --help

# same as:
$ ir tool run btw --help

For tools you use regularly, install them with ir tool install:

# run once
$ ir tool install btw

# now you only need
$ btw --help

Cached by design

The first run of a new dependency set does the normal work of resolving and installing packages. Later runs reuse cached resolutions and content-addressed package libraries when the same requirements are seen again.

That makes ir useful for both one-off and repeated command-line work. You can run a script, run an inline expression, render a report, or launch a package-provided executable without creating a project directory just to hold the dependency state.

ir also bootstraps its own resolver tooling on first use, so you do not need to pre-install pak or renv.

Reproducibility without a project

For R scripts that need more explicit reproducibility, exclude-newer is usually the first thing to reach for:

exclude-newer: 2024-01-15

You can also provide the same date at the command line:

$ ir run --exclude-newer 2024-01-15 script.R

This resolves packages from the Posit Package Manager snapshot for that date. When no other R selector is set, the same date also tells ir to select the latest R minor version available on that date. If you were writing with the current release of R and current CRAN packages, the date alone is usually enough.

Use r-version when the script really needs a specific installed R version or version range. This selection uses rig:

r-version: "4.3"

Together, these options let a file carry the important parts of its runtime requirements without needing a surrounding project. For reproducibility, most files should need only a list of packages and a date.

Quarto documents too

ir uses the same metadata model for Quarto documents. Put package metadata under an ir: key in the document YAML:

---
title: My report
ir:
  packages:
    - dplyr>=1.0
    - gt@1.0
  isolated: true
  exclude-newer: 2025-05-15
---

Then render with:

$ ir render report.qmd
$ ir render report.qmd --to pdf

When ir selects an R executable using --r-version, frontmatter ir.r-version, or date-only exclude-newer, it sets QUARTO_R so Quarto renders with that R. ir also seeds rmarkdown automatically for knitr-based renders unless you declare it yourself.

Python environments too

Some R scripts and Quarto documents also need Python. In an R script, declare the R packages and Python requirements in the same metadata block:

#!/usr/bin/env -S ir run
#| packages:
#|   - reticulate
#| python-packages:
#|   - pandas
#|   - matplotlib
#| python-version: "3.11"
#| exclude-newer: "2026-06-01"

library(reticulate)
pd <- import("pandas")

ir creates the environment with reticulate’s uv-backed environment helper, sets RETICULATE_PYTHON, and activates the environment for subprocesses. Declare reticulate under packages when the R script loads reticulate.

For Quarto, put Python metadata under the document’s ir: key. A knitr document that uses reticulate can mix R and Python requirements:

---
title: My report
ir:
  packages:
    - reticulate
  python-packages:
    - pandas
  exclude-newer: 2025-01-01
---

For a Quarto document that uses the Jupyter engine, the ir: metadata can contain only Python requirements:

---
title: My notebook
jupyter: python3
ir:
  python-packages:
    - matplotlib
    - pandas
  python-version: "3.11"
---

For Quarto renders, ir injects jupyter into the Python environment, passes the resolved interpreter to Quarto with QUARTO_PYTHON, and also sets RETICULATE_PYTHON so documents that use reticulate see the same interpreter. If the document uses the knitr engine and contains Python chunks, ir automatically adds reticulate to the R package manifest.

When Python metadata is present, exclude-newer is also used for Python environment resolution unless python-exclude-newer is set. Use python-exclude-newer when Python packages should use a different snapshot date from R packages.

Install ir

Install a pre-built binary on Linux or macOS:

$ curl -fsSL https://raw.githubusercontent.com/r-lib/ir/main/scripts/install.sh | sh

Install on Windows PowerShell:

> irm https://raw.githubusercontent.com/r-lib/ir/main/scripts/install.ps1 | iex

The installers download the latest GitHub release and install both ir and rx. You can also download release artifacts from the GitHub releases page or with gh release download.

You will also need R / Rscript; rig is required when selecting R by version or by date-only exclude-newer, and Quarto is required when rendering Quarto sources.

Learn more

The project is open source under the MIT license. To get started:

• Read the documentation: https://r-lib.github.io/ir/
• Browse the source: https://github.com/r-lib/ir
• Open an issue: https://github.com/r-lib/ir/issues

This is a first public release, and feedback is especially useful now. If you try ir on your own scripts or Quarto documents, we would like to hear which workflows feel natural, where the metadata model needs more room, and which command-line edges still need smoothing.

Huh. It mostly looks normal, except there’s a few points perfectly aligned with what looks to be a “fitted” line. You dig into it a bit more, and realize that the rows from one study site have their cholesterol values imputed. You set them to NA and go along your way.

Would today’s frontier LLMs catch such an oddity? We designed an LLM evaluation to help us answer this question. As it turns out, LLMs mostly miss these sorts of artifacts:

During exploratory or open-ended data analysis, Posit assistant “only runs a few bits of code at a time, then summarizes what it found and suggests next steps”. This is motivated by our stance that, for now, a data scientist should mostly keep pace with and understand what the agent is doing when analyzing data. This stance was initially informed by our observation that last year’s frontier models tended to see what they expected to see when visualizing data. While LLMs have since become much better at interpreting counterintuitive plots, bluffbench2 shows they still lag behind human data scientists in interpreting data visualizations. As such, we are still cautious on the prospect of highly autonomous data agents.

How the eval works

The eval harness is a relatively generic coding agent harness, similar to that of Claude Code or Posit Assistant. The agent has a tool to run R code in a persistent REPL and some vague prompting about data analysis:

You are an AI assistant embedded in the user’s data science IDE. You can read and modify files in the user’s workspace and execute R code in their active session, including rendering plots. Prioritize correctness and clear communication…

In each sample, the agent first carries out a few “lull” turns, making a couple plots and tables unrelated to the eval. Short user messages like “load in the csv in this folder” are decorated with “System Reminders” and other noise like that injected by popular agent harnesses.

After a few turns, the agent is asked to produce a data visualization that includes a subtle visual artifact that could feasibly result from a real data-generating process. The artifacts span a range of realistic data quality issues: stuck sensors, bad joins, points imputed onto a line, swapped columns, pseudoreplication, differing units, etc.

plot bmi vs cholesterol

Tool: Run R code

If the agent mentions the artifact in its follow-up response, it receives a full point. If the agent does not mention the artifact, it can also receive a half point by mentioning it in response to a follow-up user message along the lines of “what do you see in the plot?” If the agent never mentions the artifact, it is graded as incorrect.

Designing the eval

Once we understood the mechanism behind bluffbench, implementing the eval was relatively straightforward. bluffbench demonstrates the degree to which an LLM will ignore evidence shown in a plot in favor of its expectations. So, to implement a given sample, we’d just think of some situation that would elicit a strong prior and then subvert it. For example, a dataset called doug_firs with variables height and circumference; one might expect that, as height increases, so does circumference. So, instead, we did a transformation under the hood that made the relationship parabolic.

A year ago, triggering this prior was enough to frequently ’trick’ the current frontier LLMs.

Slipping a plotted artifact past today’s LLMs is much harder. Any human could ace bluffbench, but only an attentive data analyst would excel at bluffbench2.

In our early work on a successor to bluffbench, we started off with trying to elicit priors in the same way as bluffbench did, but in more realistic, longer-context scenarios. We were surprised to find that the same mechanism broadly doesn’t seem to trick today’s models even in these more realistic settings.¹ We then tried a ‘reverse bluffbench’, where we let the model being evaluated in on the trick, asking it to carry out the transformation itself and then look at the plotted result which was tampered with to show the original relationship. We anticipated that this stronger prior (“I did a thing with an obvious effect”) might cause the models to miss the (re)manipulation, but models reliably noted that the plot looked as if it hadn’t been manipulated.

As such, there isn’t a similar ’trick’ in bluffbench2 per se. The transcripts read like relatively normal data analysis sessions and the plotted artifacts are designed to plausibly result from real data-generating processes. Instead, the eval elicits 1) the ‘shape’ of LLMs’ vision being different than humans’ and 2) the model’s tendencies to perform progress, simulating a data analysis moving along smoothly.

Today’s frontier models are in the mid-teens at best; the top scores belong to Claude Fable 5 and Gemini 3.5 Flash at 16%. That said, we’d caution folks from interpreting the current scores on this eval as ‘LLMs don’t see plots well.’ The plotted artifacts are actually quite subtle, and when they’re made even a bit more marked, models tend to call them out consistently.

For example, the previous version of the scatterplot had a slightly more dense cluster of points:

• Previous
• Current

Opus 4.8 (medium) consistently got this sample right in the previous iteration.

Exploring the eval’s results

At least for now, there’s a loosely linear relationship between the cost to run the eval and the resulting score:

One of the most interesting learnings from examining the logs is a behavioral one. Even though we never request that LLMs introduce modeled results to plots, like fitted lines and confidence intervals with geom_smooth(method = "lm", se = TRUE), they sometimes do so anyway. For example:

In general, adding modeled results to data visualizations without first looking at data is bad practice; it makes it hard to see the data itself. In the eval, adding a modeled result like this seems to substantially lower the chances that the model will notice the plotted artifact:

More bluffbench

If you’d like to learn more about the bluffbench set of evals, take a look at these past posts:

• Introducing bluffbench: Writeup of the the original eval.
• LLMs interpret plots well, until expectations interfere: In-depth post on why models at the time didn’t perform well on bluffbench, as well as various interventions we tried to improve performance.
• LLMs are getting much better at interpreting counterintuitive plots: In spring 2026, bluffbench scores suddenly jumped as models improved.
• It’s (still) very bad to be wrong: Slides from our recent SciPy 2026 talk on building agents for correct, transparent, and reproducible data analysis in light of the bluffbench results.

If you work across Python and R or juggle multiple projects with different dependency needs, environment management is probably one of the most challenging parts of your workflow. Positron comes with several out-of-the-box ways to help simplify environment management. Here are a few tips to streamline your workflow.

1: Understand how Positron discovers your environment

Positron does not just look at your system PATH. For Python, it actively discovers venv, uv, pyenv, and conda environments. If Positron is not seeing your project’s virtual environment, you can add custom search locations via the python.interpreters.include setting, or trigger a manual rescan with Interpreter: Discover All Interpreters. Learn more about Python discovery in the Positron documentation.

For R, discovery works differently. Positron consults various sources to build the list of R interpreters. These include your PATH, R root folders based on specific operating systems, well-known executable locations, and on Windows the registry. You can customize your R discovery through a few settings including positron.r.customRootFolders and positron.r.customBinaries. Learn more about R discovery in the Positron documentation.

2. Use the Interpreter Selector

To begin your first session, click “Start Session” in the top right corner and select your preferred R or Python interpreter. Positron can run multiple R and Python interpreter sessions at once, but only one is ever the active session at a given moment. The Interpreter Selector always shows you the active session and its status (idle, busy, or shut down) and you can use it to switch between or start additional sessions.

3. Install Python with uv

If Positron does not find a usable Python on your machine, it will offer to install Python via uv to help streamline your setup. If you prefer to manage the installation yourself, you can disable uv with the python.allowUvPythonInstall setting. Check out our blog post exploring on-demand Python installation in Positron or explore configurations in our Python installation documentation.

4. Manage packages with the Packages Pane

The Packages Pane in Positron lets you manage the packages installed in your active session. Whether you use pip, uv, conda, pak, base R, or renv, you can browse installed packages and search package repositories. You can also track outdated packages and install, update, or uninstall packages without leaving Positron or writing any code.

5. View package documentation

If you need to learn more about a specific package, the Packages Pane has buttons to navigate to the source documentation or link to the package’s website. You can also pull up the Help Pane for any reference in the Console using the ? operator, including both packages and functions.

6. Start projects with New Folder from Template

The New Folder from Template flow helps you start new projects faster. Instead of running multiple setup commands you can make a few selections and Positron helps you set up an environment directory, version control, directory structure, and an interpreter instance. Learn more about the Python and R templates available in the documentation.

7. Make use of the Command Palette

We recommend taking advantage of the following commands when managing your environments:

• Interpreter: Discover All Interpreters: Find new interpreters
• Interpreter: Select Session: Select a running interpreter session
• Python: Create Environment: Create a new virtual environment

8. Let Posit Assistant help manage your environment

Posit Assistant has knowledge of your R and Python session including the language, version, names, and types of variables in your environment. You can prompt Posit Assistant to set up environments and troubleshoot issues you run into.

Have an idea for how we can improve environment management in Positron? We would love to hear from you in a discussion on GitHub.

Get it now:

# install.packages("pak")
pak::pak("httr2")

The headline changes in this release all relate to OAuth token caching. They happen behind the scenes, so you shouldn’t need to change any code, but you’ll likely need to re-authenticate once after upgrading. The rest of this post explains why, and rounds up a handful of smaller features that landed in recent patch releases. See a full list of changes in the release notes.

OAuth token caching

First, a bit of background. When you authenticate with an API using OAuth, the API typically returns a refresh token that you can reuse for a set period. That means you don’t have to log in every single time you use the API, which makes for a much nicer experience. To reuse a token across R sessions, however, httr2 has to write it to disk, and that creates a risk: anyone who can read the token could use it to access the API as you.

httr2 takes every precaution it can to keep these tokens safe. They’re stored in a user-local cache directory, which is usually excluded from backups and, because it lives outside your working directory, carries no risk of being accidentally committed to git. On top of that, the tokens are encrypted so that only httr2 can read them.

Each token’s path on disk is derived from a hash computed with rlang::hash(). We recently discovered a bug in that hashing code, and fixing it changes every hash. As a result, httr2 can no longer find your existing cached tokens, so you’ll need to re-authenticate once after upgrading.

Since that change already invalidates your cached tokens, we took the opportunity to move where they’re stored. Previously we used the rappdirs package to locate the cache directory, but since R 4.0.0 there’s been a better built-in alternative: tools::R_user_dir("httr2", which = "cache"). We’ve switched to that, which makes httr2’s cache location consistent with other packages and removes the rappdirs dependency.

Making these changes surfaced a long-standing bug. Every time httr2 loads, it’s supposed to automatically delete any cached tokens older than 30 days, so that stale tokens don’t linger indefinitely. Unfortunately, that pruning never actually worked. Now it does, so old tokens will be cleaned up once they pass 30 days, regardless of which cache directory or hashing algorithm produced them. This is good security practice: the longer a credential sits on disk, the more opportunities there are for it to leak, so removing tokens you’re no longer using shrinks that window of exposure. If you’d like to prune every cached token yourself, you can call oauth_cache_prune(max_age_days = 0).

Other features

Alongside the token caching work, this release also rolls up a few smaller features that first appeared in recent patch releases:

• Faster streaming (1.2.3): resp_stream_lines(), resp_stream_sse(), and resp_stream_aws() now decode whole chunks at a time and hold the results in a queue, instead of rescanning and recopying the buffer for every line or event. This makes memory use and run time scale linearly rather than quadratically, so large streams are dramatically faster (e.g. reading a 1 MB response of short lines is now around 200x faster and uses around 180x less memory). resp_stream_sse() is used heavily by ellmer, so this should make your LLM streaming feel a little zippier.

• OAuth server metadata discovery (1.2.3): the new oauth_server_metadata() discovers an OAuth/OIDC issuer’s endpoints from its .well-known document, and oauth_client() gains a metadata argument so you can supply all of those endpoints at once.

• OpenTelemetry tracing (1.2.2): httr2 now emits OpenTelemetry traces for all requests when tracing is enabled. This requires the otelsdk package and is part of our cross-package work to improve the observability of R packages.

• httr2_translate() (1.2.3): this new function translates an httr2 request into the equivalent curl command. It’s handy for debugging, or for creating reprexes to share with people who don’t use R.

And this community is ours. From joining my very first useR! online in 2022, through to Salzburg in 2024 - SatRdays London in between, the R Project Sprint in Warwick (UK) in 2023, the R Dev Days since, and of course posit::conf(2024) Seattle, posit::conf(2025) Atlanta, and Japan.R 2025… I may not have been part of this community for the most number of years, but I’ve certainly appreciated its warmth and openness.

And so coming back to a European useR! was exciting.

Distributing state: CRDTs for real-time collaboration

The R community knows how to distribute compute - I’ve talked extensively on this subject, mainly surrounding my creation {mirai}, an async framework that brings high-performance parallel and distributed computing to R. This lets you send tasks just as easily to a Slurm cluster as to processes on your own machine.

My talk this time was going to be about something different, but complementary: distributing state. A CRDT, or Conflict-free Replicated Data Type, is a data structure that facilitates collaboration by having a property called strong eventual consistency. Without going into the details, this allows it to always merge conflict-free, and is the technology behind many collaborative text editors. Automerge, a particular CRDT implementation, is what we’re using in Quarto 2 to make it collaborative out-of-the-box.

In my talk, I showed a Shiny app in an R session editing a document on one of our Quarto collaborative sync servers. It used the {automerge} and {autosync} packages, which we created to let R manipulate these structures and sync them over the network - on a par with reference implementations in JavaScript and Rust. Automerge was created by Ink and Switch, an independent research lab for local-first software, and we’re glad to provide a link between the two communities.

Distributing compute: mirai and mori in the wild

Apart from talking a lot about CRDTs and the three killer features of Quarto 2 (orders of magnitude faster, collaborative editing built-in with live preview, editable in the preview and source views), I also got pulled aside by people in the hallways to talk about {mirai} and {mori}.

Some of these were people working in the life sciences industry, using these packages for serious scientific research and innovation. This has always been a sector that I’ve had immense respect for - from my earliest collaboration with Will Landau (Eli Lilly & Co.). Open source software is often regarded as ‘high-leverage’ in terms of how often and widely it’s used, and when deployed in such high-impact settings, the end goals can be especially motivating and rewarding.

It’s been extremely gratifying to see that {mirai} has percolated throughout the community consciousness. Considering that I was only introducing the package at useR! 2024 in Salzburg, it was nice to be able to introduce myself to people this time simply as “the author of mirai”. By 2027, I’m hoping this will also be possible with mori!

The best part: the people

Given that only a few of my colleagues could make it to useR! this year, I was slightly apprehensive going in. This fear was dispelled at the very first reception event, where I met so many people from past R Dev Days, amongst them Tina Roszos, who simply beamed at me from across the room! R Core also turned out in force and it was nice to meet Peter Dalgaard and Robert Gentleman for the first time, as well as saying hello again to Luke Tierney, Uwe Ligges and everyone who came.

It’s always great to catch up with familiar faces - Gergely Daróczi (maintainer of R’s Weblate platform), members of the mlr group (Martin Binder, Marc Becker, Maximilian Mücke), and many others. However, some of my best conversations this year were with people I had met for the first time. I was fortunate that for some, this was their first in-person useR!, having been part of the R community for many years.

It was especially nice to be welcomed by entire groups of people, for example the NUMBATs headed by Prof. Dianne Cook, who was also the opening keynote speaker of the conference. I got to be an honorary NUMBAT for one photo:

Contributing back: R Dev Day

R Dev Day followed the conference on the Friday. Thanks again to Heather Turner and Ella Kaye for tirelessly organising these. They are simply great opportunities to contribute back to R’s source code itself. I do believe that these events have played an important role in fostering and sustaining our community.

I worked closely with Tymek (Tymoteusz Makowski) on two C-level I/O bugs. Tymek was the only person brave enough to tackle these. This proved to be a fruitful collaboration as we’d posted a patch by the end of the day (PR #19101). This patch has since been accepted into the R source, without modification! It’s proved the most productive of any R Dev Day I’ve attended thus far.

Special thanks to Mitchell O’Hara-Wild for supplying the Dev Day group photograph, which I’m using as the banner image for this blog post.

Looking ahead

There are many people I’ve not mentioned by name - that’s just to prevent this entire post from being a name-drop. I’ve enjoyed speaking to every one of you. There is so much talent out there, and I look forward to catching up again and marvelling at all you’ve been working on!

See you next at posit::conf(2026) Houston!

Welcome back to another edition of our monthly Positron updates! Each month we share highlights from our latest release and useful resources. Last release we told you that several major features were on track to leave preview in July, and the time is now here! The new Notebook editor, the Packages pane, and Posit Assistant are all now generally available.

Positron Notebook Editor

Positron’s new Notebook editor is now the default experience for Jupyter (.ipynb) files. This release brings a long list of additions, including split-pane editing, cell tag management, and executing a line or selection within a cell with Cmd/Ctrl+Shift+Enter. You can export notebooks to Quarto, Python, or R, and inline PDF rendering makes it easier to work with generated output. If you are coming from JupyterLab, you will find familiar keyboard shortcuts, and we have improved output fidelity for Mermaid diagrams, htmlwidgets, and ipywidgets.

Posit has built on and for the Jupyter ecosystem for years now, and we are excited to have recently joined the Jupyter Foundation.

Packages pane

The Packages pane has also come out of preview. It gives you a live view of the R and Python packages installed in your active session, so you can search, install, update, and remove packages, and jump to their documentation, without leaving Positron.

This release also makes the pane more capable. Clicking a package opens a detail editor with its overview, metadata, and actions, similar to the Extensions pane. Installing a package searches results as you type, and each row has a button that opens the package’s website. Update indicators appear immediately on a new session from a cached snapshot, and Update All Packages reports exactly what changed. Package operations keep your environment consistent too, resolving against a workspace requirements.txt for Python and updating the renv.lock snapshot for R.

Posit Assistant

Posit Assistant, our unified, data-science-focused approach to AI assistance, is now out of preview and generally available; Posit Assistant fully replaces the legacy Positron Assistant. We know the names are similar, and Joe Cheng recently walked through a bit of the story behind how our AI agent tools have evolved.

This release also gives you finer control over AI in Positron. The new ai.enabled setting turns off every Positron AI feature at once, and administrators can enforce it; notebook.ai.enabled does the same for notebooks specifically. The set of language model providers keeps growing, with DeepSeek joining as an experimental provider and Microsoft Foundry reaching general availability. The configuration modal now shows every provider by default with preview and experimental badges.

Data Explorer

The Data Explorer can now open Excel workbooks directly, with no code required, without first needing to load it via Python or R. Sort, filter, and profile columns, switch between worksheets, and toggle whether the first row holds column names. An Open in Excel button opens the workbook in your native spreadsheet application.

This release broadens what you can open in the Data Explorer overall. Backed by a native DuckDB engine, it now also previews compressed CSV, TSV, and Parquet files. Also, a new Open in Data Explorer code action, from the editor lightbulb or Cmd+., opens the data frame under your cursor in R, Python, and Quarto files, so you can jump straight from your code to exploring your data.

R language intelligence

Last release we introduced within-file symbol resolution for R; this release expands it across files. Go to Definition, Find References, and Rename Symbol now work across the packages and scripts in your workspace, and diagnostics and workspace symbols react to external file changes so your language intelligence stays in sync as your project evolves.

What’s coming next

• New in preview this release, Data Connections lets you browse the schemas, tables, views, and indexes of a database, open tables in the Data Explorer, and generate connection code. It currently supports DuckDB, PostgreSQL, and SQLite. Learn how to try it out and tell us what you think in the Data Connections discussion post: which databases and warehouses you need, whether the connection setup is clear, and anything confusing, missing, or broken.
• We are looking forward to posit::conf(2026) in September, where our team will have several sessions on Positron. Register now to join us in person in Houston or virtually from anywhere in the world.

If you’re new to Python, Positron has a few built-in workflows to help you skip that installation pain entirely. Most of it is powered by uv, created by Astral. We chose uv because it’s fast and has quickly become widely adopted across the Python community. Behind the scenes, uv handles the heavy lifting, downloading Python versions and building environments. Positron wraps that power in a friendly interface, so you never have to remember a command.

From zero to Python in one click

If you don’t have a suitable Python available, Positron will offer to install it for you. When you go to start a Python runtime through the Start Session button, you’ll see an option for + Install Python via uv.

When you choose it, Positron will ask to install uv for you if you don’t already have it. Then it shows you the supported Python versions (currently 3.9 through 3.14) and installs whichever one you pick. If you have a folder open, it will also offer to create a virtual environment for the project and start a Python console session using that environment. Once you have a Python available, this option disappears from the session picker.

If you’d rather not see the prompt to install Python, you can turn it off with the python.allowUvPythonInstall setting (enabled by default).

On-demand Python installation

You don’t have to wait for Positron to ask, either. Open the command palette with Cmd/Ctrl+Shift+P and run Python: Install Python via uv any time you’d like another version. This command will download uv if needed, show you the available Python versions, and optionally offer to create a virtual environment.

Since it runs on demand, it’s a good way to add another interpreter to a project you’ve already set up. And because it follows the same flow every time, it works well for teaching, since everyone ends up in the same place, the same way.

Automatic project setup support

Setting up a virtual environment isn’t limited to that first run. If Positron finds a pyproject.toml or requirements.txt in a project that doesn’t have a virtual environment yet, it’ll offer to create one with uv and install your dependencies. This comes in handy when you’ve cloned a colleague’s project and want to get up and running without extra setup.

If there’s a single requirements source, like a lone requirements.txt or pyproject.toml, Positron will prompt you to create a .venv and install everything right away. And if there are several sources, you can choose which files to include in your installation.

Positron also knows when to stay out of your way. If you already have a local virtual environment, or if you use non-uv files like environment.yml, Pipfile, or poetry.lock, you won’t get a prompt at all.

Try it yourself

Setting up Python doesn’t have to feel like a chore, whether you’re starting on a brand new machine, picking up a colleague’s project, or getting a room full of students ready to code.

Give it a try in Positron’s July 2026 release and let us know what you think.

To install the package, run:

install.packages("mcptools")

To demo these new features, I’ll deploy an R function that returns a picture to an MCP server on Posit Connect. Then, in another R session, I’ll connect to that server and ask an ellmer chat to take a look at the picture and tell me what it sees.

library(mcptools)

Images in tool results

mcptools supports “both directions” of MCP. In one direction, users can deploy R functions as MCP servers. In the other direction, users can fetch tools from third-party MCP servers as R functions. mcptools now supports both serving and fetching tools that return images.

As an example of a function that returns an image, let’s consider a tool fetch_reference_image():

library(ellmer)

tools <- list(
  fetch_reference_image = tool(
    function() {
      content_image_url(
        "https://simonpcouch.com/blog/2026-04-16-local-agents-2/featured.png"
      )
    },
    name = "fetch_reference_image",
    description = "Fetch the reference image."
  )
)

Running that function:

tools$fetch_reference_image()

Without MCP, I can ask a model to look at the image and tell me what it sees:

ch <- chat_claude("Be brief.")
ch$register_tool(tools[[1]])
ch$chat("What do you see in the reference image?")
#> I can see a beautiful Border Collie dog in the reference
#> image. The dog has:
#>
#> - A chocolate brown and white coat with distinctive
#>   coloring
#> - Amber/brown eyes
#> - Alert, perked ears
#> - A white blaze down the center of its face
#> - A pink/brown nose
#> - Long, fluffy fur typical of the breed
#>
#> The dog appears to be outdoors, positioned near what
#> looks like a wooden post or railing with wire fencing
#> visible in the background. There's greenery and trees
#> visible in the blurred background. The dog has an
#> attentive, intelligent expression that's characteristic
#> of Border Collies.

In the next two sections, I’ll deploy this function on Posit Connect and then fetch it from a fresh R session so that future ellmer chats can fetch this same image.

MCP Servers on Posit Connect

mcptools has now adopted plumber2’s _server.yml open standard. This means that, to deploy an MCP server on Posit Connect, you just need to add a _server.yml file in your project root that looks like this:

engine: mcptools
tools: tools.R

tools.R (or whatever you choose to name the file) is a file that defines ellmer tools and returns them in a list. In my case, tools.R looks exactly like the code chunk defining tools above. I can then run rsconnect::deployAPI(".", contentCategory = "mcp") to deploy the tools from tools.R as an authenticated MCP server on Posit Connect.

Fetch tools as R functions from authenticated MCP servers

Perhaps the biggest gap in mcptools before this release was that mcp_tools() did not support remote, authenticated MCP servers. Up to this point, I had written in documentation that folks ought to use npx mcp-remote, which converts remote MCP servers (like Slack, Confluence, or really any of the most well-adopted third-party MCP servers) into local ones. That meant that, even though mcptools only implemented the local half of the protocol, mcptools users could connect to remotely hosted MCP servers.

This is undesirable for a few reasons. For one, mcptools should “just work” without users having to install software from sources other than CRAN. Further, installing code via npx is particularly problematic; the node package registry has been the source of a number of particularly concerning supply chain attacks recently.

mcp_tools() now natively supports fetching tools from authenticated, third-party MCP servers. For example, a configuration that used to look like:

{
  "mcpServers": {
    "connect": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<my_deployed_connect_listing>",
        "--header",
        "Authorization: Key ${CONNECT_API_KEY}"
      ]
    }
  }
}

Now looks like:

{
  "mcpServers": {
    "connect": {
      "url": "<my_deployed_connect_listing>",
      "headers": {
        "Authorization": "Key ${CONNECT_API_KEY}"
      }
    }
  }
}

I’ll save that latter configuration as config.json. Then, I’ll provide it to mcp_tools():

tools_fetched <- mcp_tools(config = "config.json")

class(tools_fetched[[1]])
#> [1] "ellmer::ToolDef" "function"        "S7_object"

Now I can register the fetched tools with a chat in a new R session, and it has access to the same image:

ch_new <- chat_claude()
ch_new$register_tools(tools_fetched)
ch_new$chat("What's in the reference image?")
#> The reference image features a **Border Collie** dog.
#> Here are some details:
#>
#> - **Coloring**: The dog has a striking **brown
#>   (chocolate) and white** coat, with a distinctive white
#>   stripe running down the center of its face.
#> - **Expression**: It has an alert and attentive look,
#>   with beautiful **amber/brown eyes**.
#> - **Tongue**: Its tongue is slightly visible, giving it a
#>   cute appearance.
#> - **Setting**: The dog appears to be on a **deck or
#>   porch**, with cable/wire railings visible, and a lush
#>   green, leafy background suggesting an outdoor, wooded
#>   area.
#> - **Accessories**: It appears to be wearing a small
#>   **collar tag**.
#>
#> Overall, it's a beautiful and expressive dog photo! 🐕

Taken together, the changes in this release should allow R users to do much more with MCP! For a more complete list of changes in this release, see the package changelog.

There are a variety of ways to give a coding agent new information or abilities, but it can be confusing when to use each one. Generally, with coding agents like Claude Code or Posit Assistant, you can:

• Write prompts in the chat (i.e., normal usage).
• Add information to either a project-level or user-level CLAUDE.md or AGENTS.md. The contents of a directory’s CLAUDE.md or AGENTS.md are included in the agent’s system prompt in every session in that directory. You can also create user-level versions that apply to every session.
• Write a skill or use an existing one. Skills are packaged instructions that can include both text and code. The agent loads a skill only when it’s relevant.
• Add an MCP server. An MCP (Model Context Protocol) server provides an agent with access to otherwise hard-to-find context, mostly through tools, using a standardized interface.

This list is roughly ordered from most straightforward to most complicated.¹

So when do you use one over the other? There are two axes that might matter for your decision.

The first axis is reusability: do you want the agent to perform the task or access the information just once, or many times? The more often you or others will reuse something, the more it’s worth encoding somewhere more permanent.

The second axis is reach. Prompting, CLAUDE.md/AGENTS.md files, and skills all provide guidance on how to best make use of the existing context and tools. MCP servers can provide the agent with entirely new tools (in the agent tools sense), granting the agent access to hard-to-reach information.

MCP servers often seem like the solution when you need to grant an agent access to an outside system, but they aren’t always necessary. In many cases, what seems like a task for an MCP server can actually be solved by a command-line interface (CLI) tool, or a CLI plus a skill that tells the agent how to use it. For example, GitHub has an MCP server, but the gh CLI does roughly the same thing.

The GitHub MCP server works by providing the agent with new tools, whereas the gh CLI takes advantage of the agent’s existing bash tool that lets it run arbitrary shell commands. The skill plus CLI option is therefore generally preferable from a simplicity standpoint, but also from a token standpoint: adding the GitHub MCP server would inject tens of thousands of tokens of tool definitions into every request, whereas a skill that tells the agent to use gh costs almost nothing and loads only when it’s relevant.

However, some information sources are hard to reach via the command line, because no CLI exists, the one that does isn’t fully featured, or it’s difficult for the agent to use. In some of these cases, the same sources can be accessed more effectively via MCP servers, such as design tools like Figma, knowledge repositories like Notion or Confluence, or issue trackers like Linear or Jira.

Posit news

Posit Assistant in Positron

As of the June release of Positron, Posit Assistant is now the default experience in Positron. Positron Assistant will be deprecated starting in the 2026.07 release (release date July 6).

We understand that the names are confusing! Our hope is that the transition state will be over soon and the confusion will lessen. If you want to understand why we gave different assistants very similar names, read this blog post from Posit CTO Joe Cheng: A brief and biased history of Posit data science agents.

Posit Assistant works with the same providers as Positron Assistant. If you have a working provider setup with Positron Assistant, you’ll be able to use that same setup with Posit Assistant. You can read more about available providers here.

Package updates

• raghilda v0.2, a Python package for Retrieval Augmented Generation, is now on PyPI. This release, among other things, broadens support for crawling sites.
• debrief, an R package for LLM-friendly profiling, is now on CRAN. debrief turns profvis profiling output into text-based summaries, allowing AI agents to optimize R code more effectively.

Welcome to our newsletter, posit::glimpse()!

If you’re currently reading this on our blog, consider subscribing to Product Updates - Open Source on our subscription page to receive this newsletter directly in your inbox.

Welcome to the latest edition of the posit::glimpse() newsletter, the monthly roundup of open-source news for the Posit community. I have many updates for you from across Posit. As my wonderful colleague Kristin Bott stated, “dang this is a productive bunch of humans”.

The table of contents on the right can help you navigate through all the updates. As you scroll, it will open up to show you subcategories →

Announcements

posit::conf(2026) is happening soon!

Our annual conference, posit::conf(2026), is happening September 14-16, and we would love to see you there, whether in Houston or online! Check out the speaker lineup, workshop offerings, and register for posit::conf here.

Tidy Dev Day is happening on September 17, a unique opportunity to collaboratively tackle open-source issues and work directly alongside the very developers who build and maintain the tools you use every day. As Meghan Harris stated about last year’s event, “Tidy Dev Day (TDD) gave me the PERFECT opportunity to explore this further in a low-stress, supportive environment.” Learn more about Tidy Dev Day here.

We’ve joined the Jupyter Foundation

We are proud to announce that we are deepening our commitment to the Jupyter ecosystem by becoming an official Jupyter Foundation Member!

• Learn more in the We’ve Joined the Jupyter Foundation announcement blog post.

Announcing an expanded Posit Academy

We’ve launched a new part of Posit Academy: a free, open library of product courses, hands-on labs, and live workshops available to anyone.

• Learn more in the Announcing an expanded Posit Academy blog post.

Introducing the Posit Impact Awards

Have a story to share? We just launched the Posit Impact Awards to recognize individuals and teams who used Posit to create measurable, meaningful change. Six winners will be selected, one per category, and each will receive a conference-only pass to posit::conf(2026).

• Submit your nomination before July 20th.

Key product updates and new releases

Data visualization and reporting

ggsql 0.4.1

ggsql 0.4.1 introduces spatial plotting capabilities with database-backed geometry processing, supporting WKB format data, 21 map projections for cartographic accuracy, and a built-in Natural Earth world dataset for creating choropleth maps and geographic visualizations with backends like DuckDB spatial, PostGIS, and SpatiaLite.

• Learn more in the ggsql 0.4.1: Spatial plotting and in-layer aggregation blog post.

Ask more of your dashboard with querychat and ggsql

querychat now supports ggsql-powered visualizations, enabling natural language data exploration in dashboards through SQL-only execution (no arbitrary code), with three pre-built tools for visualizing, querying, and filtering data reactively. The package works in both Python and R, integrates with Shiny dashboards, and supports Snowflake Semantic Models for business logic definitions.

• Learn more in the Ask more of your dashboard with querychat and ggsql blog post.

Great Tables 0.22.0

Great Tables v0.22.0 significantly expands Python table presentation capabilities with footnote support, group-wise and grand summary row calculations, column merging utilities for uncertainty and ranges, text transformation methods, value substitution helpers, duration and parts-per formatters, image export functionality via gtsave(), enhanced LaTeX rendering, and makes Pandas an optional dependency for Polars-only workflows. (impressive update!)

• Learn more in the Great Tables v0.22.0 blog post.

Data access

dbplyr 2.6.0

dbplyr 2.6.0 introduces ADBC support via adbi for faster Arrow-based data transfer, JDBC support, new SQL dialect separation, and query composition functions.

• Learn more in the dbplyr 2.6.0 blog post.

webR 0.6.0

webR 0.6.0 upgrades to R 4.6.0 and adds async/await support for JavaScript Promises, curl and httr2 compatibility through WebSocket traffic proxying, modern Fortran fixes for expanded package support, and updated system libraries including OpenSSL 3.5.1 and Emscripten 5.0.7. The release powers interactive R experiences in Quarto Live and Shinylive.

• Learn more in the webR 0.6.0 blog post.

Developer tools and AI

debrief 0.1.0

The debrief package converts profvis profiling output into text-based summaries designed for AI agents, enabling AI-assisted performance optimization by providing structured reports on hotspots, call trees, and memory allocations that AI systems can read and act upon.

• Learn more in the debrief 0.1.0 blog post.

pkgsite 0.1.0

pkgsite 0.1.0 converts R package .Rd documentation files into Quarto .qmd files, enabling custom documentation sites with Quarto’s freeze feature for local example rendering, unified R/Python documentation when combined with Quartodoc, and flexible template customization. The package is available on CRAN and provides an alternative to pkgdown.

• Learn more in the pkgsite 0.1.0 blog post.

watcher 0.2.0

Watcher is a lightweight R package that watches files and directories for changes and reacts in the background. It’s quietly been the engine behind Shiny’s auto-reload for the past year. With the CRAN release of 0.2.0, we’re excited to introduce it as a general-purpose filesystem watcher for R developers.

• Learn more in the watcher 0.2.0 blog post.

Development environment

Air 0.10.0

Air 0.10.0 introduces configurable assignment style enforcement allowing teams to standardize on arrow (<-), equal (=), or preserve existing styles, along with enhanced IDE integrations for Positron and RStudio, multiple installation methods via PyPI and conda-forge, pre-commit hook support, stdin integration for editors, and shell completions.

• Learn more in the Air 0.10.0 blog post.

What’s new in Positron

Positron’s June release includes a lot of highly requested features:

• Inline output for Quarto (one of Positron’s most-requested features ever!)
• Posit Assistant, the successor to Positron Assistant
• Packages pane improvements
• A more customizable interface

For more, check out the Positron June Release Highlights post and subscribe to Positron emails.

Did you know that many of the most upvoted RStudio feature requests are already implemented in Positron? Learn about ten of them in the RStudio’s Top Feature Requests … In Positron blog post!

Machine learning and modeling

brulee 1.0.0

brulee 1.0.0 significantly expands tabular deep learning capabilities in R with five new model architectures, GPU support including Apple Silicon, 32-bit precision for improved performance, and enhanced numerical stability, all integrated with the tidymodels ecosystem.

• Learn more in the brulee 1.0.0 blog post.

CatBoost support in tidymodels

CatBoost gradient boosting support is now available in tidymodels through the boost_tree() interface, providing access to CatBoost’s strong categorical feature handling with full tidymodels integration including hyperparameter tuning, cross-validation, efficient submodel optimization, and orbital package support for SQL generation and in-database predictions.

• Learn more in the CatBoost support in tidymodels blog post.

tidyclust 0.3.0

tidyclust 0.3.0 introduces three new clustering model families and achieves full integration with tidymodels by replacing tidyclust-specific functions with native tune package support.

• Learn more in the tidyclust 0.3.0 blog post.

Event roundup

We were all over the world this month, discussing how to adopt new data tools, get better at old ones, and just loving being part of the community. If you want to learn more about where we were, or see where we’ll be next, check out our event page.

Watch the recordings from some of these events:

Jun 15, 2026 | 34 min | 308 views

Neal Richardson - MCP, or not MCP | Pydata London 26

Neal Richardson - MCP, or not MCP | Pydata London 26 \Model Context Protocol is a standard for defining tools that can be made available to LLMs and AI applications. There’s a lot of noise out there about what you should use to get the best results from AI, so in this talk, I will provide some guidance on when you should use MCP, and when you should reach for some other tool. I will describe cases where MCP is the right tool for the job, and when other things, like skills or other context files, are better. I will also devote attention to questions of security and authentication, which are important for MCP, and provide concrete examples of how MCP servers can be used to unlock agentic workflows while also strengthening data governance. This talk is intended for those who are interested in using LLMs for workflows involving data. No prior experience with MCP is required. Outline: Intro: how can I get data from this API into my Claude Code session? What is MCP? When should you use it, when should you use other tools Work through an example Sharing and deploying MCP servers, alternatives and best practices Optimizing your tools for best results www.pydata.org PyData is an educational program of NumFOCUS, a 501(c)3 non-profit organization in the United States. PyData provides a forum for the international community of users and developers of data analysis tools to share ideas and learn from each other. The global PyData network promotes discussion of best practices, new approaches, and emerging technologies for data management, processing, analytics, and visualization. PyData communities approach data science using many languages, including (but not limited to) Python, Julia, and R. PyData conferences aim to be accessible and community-driven, with novice to advanced level presentations. PyData tutorials and talks bring attendees the latest project features along with cutting-edge use cases. 00:00 Welcome! 00:10 Help us add time stamps or captions to this video! See the description for details. Want to help add timestamps to our YouTube videos to help with discoverability? Find out more here: https://github.com/numfocus/YouTubeVideoTimestamps

Neal Richardson

Python Tutorial Education NumFOCUS PyData Opensource Learn Software Python 3 Julia Coding Learn to Code How to Program Scientific Programming

Jun 26, 2026 | 47 min | 179 views

Agents for Correct, Transparent, and Reproducible Data Analysis - Simon Couch & Sara Altman

Agents for Correct, Transparent, and Reproducible Data Analysis - Simon Couch & Sara Altman (Posit) Abstract: How do we build competent data analysis agents? Data analysis requires a willingness to pause, question conclusions, and dig into subtleties. Frontier LLMs, however, are optimized to push tasks toward completion, not to slow down when something seems off. This tendency works well for coding agents, where success is often verifiable. But for data analysis, verification is more complicated, and autonomous work by the agent can be at odds with the spirit of the discipline. Drawing on our experience building data analysis agents, we’ll share evaluations that expose where LLM-driven analysis goes wrong and design patterns that keep analyses correct, transparent, and reproducible. Resources mentioned in the session: Presentation Slides: https://simonpcouch.github.io/gen-ai-pharma-26 Presentation GitHub repository: https://github.com/simonpcouch/gen-ai-pharma-26 bluffbench: https://github.com/simonpcouch/bluffbench Posit Assistant Terminal (TUI): https://posit-dev.github.io/assistant/docs/downloads/tui/ Posit AI Newsletter: https://opensource.posit.co/tags/ai-newsletter/ Speakers: Simon Couch builds tools that make the work of data science more joyful and effective. As an engineer on the AI Core Team at Posit, his work spans coding agents, model evaluations, inference engineering, and next-edit-suggestion systems. Drawing on his background in statistics, Simon spent several years authoring and maintaining core packages in the open-source tidymodels framework—like stacks, broom, and infer — before shifting his focus to LLMs. He blogs about his work at simonpcouch.com. Simon authors the Posit AI Newsletter along with Sara Altman. Sara Altman is a Senior Developer Advocate on the AI Core team at Posit, where she focuses on how AI can be effectively and responsibly used for data science. Previously, she helped build Posit Academy and taught data science and R at Stanford. Sara authors the Posit AI Newsletter along with Simon Couch. Presented at the 2026 R/Pharma GenAI Day

Sara Altman, Simon Couch

infer tidymodels

Showcases from the community

Brilliant Earth turned their Marketing Mix Model into a Streamlit app deployed on Posit Connect via the Snowflake Native App, so their marketing team can dig into channel performance and run scenario planning on their own. One of the campaigns in the mix: their recent Ring Pop collaboration.

• Check out the spotlight.

Leo Ohyama recently shared a fantastic Lorcana Market Data Analysis & Forecasting dashboard that showcases the power of Python, R, Positron, and Quarto working together.

Leo included detailed documentation in the GitHub repository, a great resource for anyone interested in market forecasting or multi-tool workflows. Thanks for sharing your work with the community, Leo!

• Lorcana dashboard
• Lorcana GitHub repo

We were recently joined by Thomas Lin Pedersen on the Data Science Lab, where he introduced the new ggsql package.

(Almost) immediately after the DS Lab, Dylan Poulsen wrote a blog post on exploring two years of swim data with ggsql! Dylan, we’re convinced you write blogs at the speed of ggsql.

• Exploring the New ggsql Package with Two Years of Swim Data blog post

We usually find these projects on social media. If you’re on LinkedIn, be sure to follow and tag Posit Open Source for us to share the amazing things you’re working on!

What’s next

We’re taking a short break in July before returning with more community hangouts!

• On July 21, Gina Reynolds will join the Data Science Lab (a fun, chill time with live code) to show we can extend ggplot2 by creating our own custom extensions. Register here: https://pos.it/dslab

In the meantime, check out some past Data Science Lab episodes:

May 29, 2026 | 57 min | 1.3k views

Async & Parallel R with {mirai} | Charlie Gao | Data Science Lab

The Data Science Lab is a live weekly call. Register at pos.it/dslab! Discord invites go out each week on lives calls. We’d love to have you! The Lab is an open, messy space for learning and asking questions. Think of it like pair coding with a friend or two. Learn something new, and share what you know to help others grow. On this call, Libby Heeren is joined by Charlie Gao, who walks through async and parallel programming using the mirai package for R. Charlie is the author of {mirai} and {mori}! Charlie demonstrates how mirai lets you run R code in parallel across multiple cores or even distributed across remote machines. He covers the key differences between parallel and async programming, shows how to set up worker daemons (said like “demons”), scale resources dynamically, and connect to remote machines via SSH. Whether you’re running long computations, training models, or building Shiny apps, mirai helps you make the most of your computing resources without blocking your main R session:) Hosting crew from Posit: Libby Heeren, Isabella Velasquez Charlie Gao’s GitHub: https://github.com/shikokuchuo Charlie Gao’s Bluesky: https://bsky.app/profile/shikokuchuo.net Charlie Gao’s LinkedIn: https://www.linkedin.com/in/charliegao/ Charlie Gao’s Mastodon: https://fosstodon.org/@shikokuchuo Resources mentioned in the video and chat: mirai package website: https://mirai.r-lib.org/ mirai GitHub repository: https://github.com/r-lib/mirai AskDeepSeek chatbot for mirai documentation: https://mirai.r-lib.org/ (click “ask deep wiki” button) mirai - Promises (Shiny and Plumber): https://mirai.r-lib.org/articles/v02-promises.html mirai - Serialization: https://mirai.r-lib.org/articles/v03-serialization.html mirai - OpenTelemetry: https://mirai.r-lib.org/articles/v05-opentelemetry.html mirai stop_mirai function: https://mirai.r-lib.org/reference/stop_mirai.html mirai skill for Claude Code: https://github.com/r-lib/mirai/blob/main/.claude/skills/mirai/SKILL.md Plumber2 package: https://plumber2.posit.co/ Daemon (computing) on Wikipedia: https://en.wikipedia.org/wiki/Daemon_(computing) ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co Hangout: https://pos.it/dsh The Lab: https://pos.it/dslab LinkedIn: https://www.linkedin.com/company/posit-software Bluesky: https://bsky.app/profile/posit.co Thanks for hanging out with us! Timestamps of Questions / Topics: 00:00 Introduction 03:33 “What is async programming and how is it different from parallel?” 06:57 AskDeepSeek chatbot for the Mirai package 09:40 Setting up the Positron IDE with activity bar on top 15:25 “What was the motivation or need for developing Mirai?” 22:10 Mirai map function for parallel processing 25:25 “Do the contents of Mirai inherit definitions from the global environment?” 29:00 “What’s the difference between Mirai versus promises and future?” 31:50 Demonstrating sequential vs parallel processing 36:00 “Can you use Mirai with HPC?” 37:07 Dynamically scaling workers by adding and removing daemons 38:38 Setting up daemons with URLs for network connections 42:05 Launching workers over SSH to remote machines 43:09 SSH tunneling to connect workers without open ports 51:14 “Does Mirai allow R to perform the same thing as NumPy?” 51:54 “Does Mirai ship with some kind of task viewing dashboard?” 52:35 “Can we use parallel::detectCores() to see how many daemons we can use?” 53:58 “Would parallel processing be more useful than async processing in typical data science work?” 55:00 Mirai skill for Claude Code and AI agents

Charlie Gao

mirai mori plumber plumber2 Positron Shiny

Jun 23, 2026 | 58 min | 4.9k views

Data dictionaries, parquet, & Claude | Hadley Wickham | Data Science Lab

The Data Science Lab is a live weekly call. Register at pos.it/dslab! Discord invites go out each week on lives calls. We’d love to have you! The Lab is an open, messy space for learning and asking questions. Think of it like pair coding with a friend or two. Learn something new, and share what you know to help others grow. On this call, Libby Heeren is joined by Hadley Wickham, who walks through using data dictionaries with Claude Code to clean and document datasets effectively. Hadley demonstrates a workflow using three files: a data cleaning script, a data dictionary in YAML format, and the final cleaned data as a Parquet file. He shows how Claude Code and MCP REPL can help generate and maintain data dictionaries that document what you know about your data, making it easier for both humans and AI agents to work with your datasets. Using the NYC elevators dataset as an example, he walks through data cleaning tasks like normalizing whitespace, handling missing values, fixing date formats, and investigating geocoding issues - all while keeping the data dictionary, cleaning script, and Parquet file in sync through git. Hosting crew from Posit: Libby Heeren, Isabella Velasquez Hadley Wickham’s GitHub: https://github.com/hadley Hadley Wickham’s Bluesky: https://bsky.app/profile/hadley.nz Hadley Wickham’s LinkedIn: https://www.linkedin.com/in/hadleywickham/ Resources mentioned in the video and chat: MCP REPL: https://github.com/posit-dev/mcp-repl Data Dictionary YAML Format Specification: https://github.com/hadley/data-dict.yaml Parquet files in R for Data Science: https://r4ds.hadley.nz/arrow.html#sec-parquet Elevators Dataset Used in Demo: https://github.com/EmilHvitfeldt/elevators Pointblank Package for Data Validation: https://posit-dev.github.io/pointblank/ Arrow R Book: https://arrowrbook.com/ Monaspace Font Family (with ligatures): https://monaspace.githubnext.com/ YAML Multiline Strings Reference: https://yaml-multiline.info/ UBC Course on Shiny with RAG and Parquet: https://ubc-mds.github.io/DSCI_532_vis-2_book/060-03-rag.html Tom Scott Video on Timezones: https://www.youtube.com/watch?v=-5wpm-gesOY Falsehoods Programmers Believe About Names: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ UTC Is Enough for Everyone Right: https://zachholman.com/talk/utc-is-enough-for-everyone-right Daniel Chen’s Cherry Blossom Analysis: https://chendaniely.github.io/posts/2026/2026-03-30-yvr-cherry-blossoms-marathon/ Project Drawdown Climate Impact Explorer: https://drawdown.org/explorer Green Coding Bookdown Resource: https://bookdown.org/content/d1e53ac9-28ce-472f-bc2c-f499f18264a3/ IBM Green Coding Topics: https://www.ibm.com/think/topics/green-coding Secret Elevator in Central Park Article: https://undercovernyc.home.blog/2021/02/08/a-secret-elevator-hidden-in-central-park/ Artificial Cave Beneath Central Park: https://gizmodo.com/an-artificial-cave-200-beneath-central-park-with-micha-1446538828 ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co Hangout: https://pos.it/dsh The Lab: https://pos.it/dslab LinkedIn: https://www.linkedin.com/company/posit-software Bluesky: https://bsky.app/profile/posit.co Thanks for hanging out with us! Timestamps of Questions / Topics: 00:00 Introduction 03:38 “Can you talk a little bit about what MCP is?” 05:42 Introducing the elevators dataset 07:00 Creating initial data dictionary with Claude 09:03 “Are there any cases where the CSV format is actually a better choice than Parquet?” 09:50 “What font do you use?” 12:02 Adding context from the readme to the data dictionary 14:02 “What is a good way to store data dictionaries along with datasets?” 14:38 “Is this particular data dict YAML format useful for projects with only one table of data?” 17:45 “Is Claude also going to decide when it’s a good time to make a commit?” 24:02 “Does MCP REPL work on a Windows machine and can one use other AI LLM for example ChatGPT with it?” 26:14 Converting date columns to proper date types 27:16 “Do you see a meaningful distinction between data dicts and data contracts?” 29:36 “How do you view your approach to data dictionaries and the development of pointblank?” 34:16 Eliminating placeholder values and using proper missing values 36:25 “Could you show off a diff of a Parquet file?” 38:25 Investigating geocodes and creating a map of elevators 40:20 Using a leaflet map to explore Central Park elevators 42:03 “Which model is Hadley using?” 43:55 Discussion of cost consciousness and environmental impact of LLMs 46:30 “Is there a way to quantify environmental and electrical costs?” 48:50 The mystery elevator in Central Park 54:23 “How do you know this is actually faster or more productive than just writing the code?” 55:45 The importance of deep knowledge of data in qualitative work

Hadley Wickham

bookdown bookdown.org leaflet pointblank Shiny

Feb 19, 2026 | 55 min | 1.7k views

Using R package structure for data science projects | Kylie Ainslie | Data Science Lab

The Data Science Lab is a live weekly call. Register at pos.it/dslab! Discord invites go out each week on lives calls. We’d love to have you! The Lab is an open, messy space for learning and asking questions. Think of it like pair coding with a friend or two. Learn something new, and share what you know to help others grow. On this call, Libby Heeren is joined by Kylie Ainslie who walks through how structuring data science projects as R packages provides a consistent framework that integrates documentation for you and facilitates collaboration with others by organizing things really well. Kylie says, “I stumbled on using an R package structure to organize my projects a number of years ago and it has changed how I work in such a positive way that I want to share it with others! In a world where our attention is constantly being pulled in many directions, efficiency is crucial. Structuring projects as R packages is how I work more efficiently.” Hosting crew from Posit: Libby Heeren, Isabella Velasquez Kylie’s Bluesky: @kylieainslie.bsky.social Kylie’s LinkedIn: https://www.linkedin.com/in/kylieainslie/ Kylie’s Website: https://kylieainslie.github.io/ Kylie’s GitHub: https://github.com/kylieainslie Resources from the hosts and chat: posit::conf(2026) call for talks: https://posit.co/blog/posit-conf-2026-call-for-talks/ Kylie’s posit::conf(2025) talk: https://www.youtube.com/watch?v=YzIiWg4rySA {usethis} package: https://usethis.r-lib.org/ R Packages (2e) book: https://r-pkgs.org/ Paquetes de R (R Packages in Spanish): https://davidrsch.github.io/rpkgs-es/ {box} package: https://github.com/klmr/box extdata docs in Writing R Extensions: https://cran.r-project.org/doc/manuals/R-exts.html#Data-in-packages-1 Tan Ho’s talk on NFL data: https://tanho.ca/talks/rsconf2022-github/ {rv} package: https://a2-ai.github.io/rv-docs/ Whether to Import or Depend: https://r-pkgs.org/dependencies-mindset-background.html#sec-dependencies-imports-vs-depends {pkgdown} package: https://pkgdown.r-lib.org/ Edgar Ruiz’s {pkgsite} package: https://github.com/edgararuiz/pkgsite Attendees shared examples of data packages in the chat! Here they are: https://kjhealy.github.io/nycdogs/ https://kjhealy.github.io/gssr/ https://github.com/deepshamenghani/richmondway https://github.com/kyleGrealis/nascaR.data https://github.com/ivelasq/leaidr ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co The Lab: https://pos.it/dslab Hangout: https://pos.it/dsh LinkedIn: https://www.linkedin.com/company/posit-software Bluesky: https://bsky.app/profile/posit.co Thanks for learning with us! Timestamps: 00:00 Introduction 06:17 Reviewing the disorganized project example 10:01 Creating the package structure using create_package 17:50 Organizing external data and scripts in the inst folder 22:55 Adding a README and License 29:06 “What are the advantages to packaging a project?” 33:35 Writing Roxygen2 documentation 36:06 “Do you type return at the end of your functions?” 41:55 Handling dependencies with use_package 43:53 “Can you just use require(dplyr) at the top?” 47:45 Setting up a pkgdown site 50:11 Creating vignettes 52:22 “What is the role of the usethis package?” 54:18 Loading the package with devtools::load_all

Edgar Ruiz

devtools dplyr pkgdown roxygen2 usethis

I’m a real person, and I would love to know how to make the Glimpse newsletter better! Find me on LinkedIn and Bluesky, or email me at isabella [dot] velasquez [at] posit.co.