In the “mocked” condition, we secretly tamper with well-known datasets, like mtcars, so that when the model plots the data, the trend shown is not what it expects. This is especially adversarial and not representative of the use case we’re most concerned about, the more realistic “intuitive” condition. For these samples, we synthesized data, but named the datasets and variables to suggest an intuitive relationship that the actual data contradicts. Finally, the “baseline” condition asks models to interpret plots with generic column names, and the results establish that models can ‘see’ just fine.

We tried all sorts of things to drive those scores up, to little effect. We let the model write a ‘memo’ to itself in a private scratchpad, enabled thinking, introduced a “model-in-the-middle” that pre-interprets the plot (so that the main agent sees only text), and even prefilled the response so that the agent was forced to say the correct interpretation (which it would then directly contradict).

bluffbench is near saturation

As is often the case, the best approach to drive these eval scores up was to wait a few months. A couple months ago, with the releases of Gemini 3.5 Flash and Opus 4.8, we saw our first >50% scores on the hardest “mocked” case in the eval. Then, last week, Fable 5 nearly aced the “mocked” case; almost all of the samples that it failed on had triggered the biology classifier and fallen back to Opus 4.8.¹

There’s still certainly room for improvement here; any human data scientist would likely score near 100% on all three conditions. A score in the 70s is still meaningfully sub-human. That said, it doesn’t seem like it will be long until bluffbench is saturated:

As is the fate of many saturated evals, we’ll soon be using bluffbench primarily to identify models on the Pareto frontier: what is the cheapest model that can reliably interpret plots, even when the plotted results are counterintuitive? While it’s certainly impressive that Fable 5 (medium) can interpret counterintuitive plots this well, driving all data analysis conversations with a model this expensive is not economically feasible for most of our users.

There’s still more to do

Even though bluffbench itself is nearing saturation, the problem of LLM agents failing to reliably incorporate surprising evidence and subtle artifacts into their analyses remains an issue. We see this qualitatively in our own work, and also have recently been able to quantify this in evals we’ll release soon.

Notably, the bluffbench harness and conversations are relatively contrived and unrealistic. There is no system prompt (by default) and the models receive only a single tool called create_ggplot(), which they use to create the plot that they’re then immediately asked to interpret.

For actual coding agents, system prompts can be extensive. Posit Assistant’s and Claude Code’s stretch into the tens of thousands of tokens. And in contrast to bluffbench, where the plot interpretation task appears in the first user message, real agents might create and interpret plots hundreds of turns into a conversation, and there’s evidence that performance may degrade as conversations go on.

Further, the user messages in the bluffbench eval are quite “clean.” They are composed only of the user’s relatively clear directive, with no “fluff” automatically injected by the harness. In most real coding agents, there are all sorts of hidden information and system reminders appended to the user message that are broadly unrelated to what the user is requesting in most situations, and agents need to ignore it.

Because of this lack of realism, and the fact that the eval and associated writing may now appear in the training data of newer models, models may know they are being evaluated in bluffbench. This risks ‘sandbagging’, where LLMs alter their behavior in situations where they suspect they’re being evaluated.

We’re seeing that in long-context, multi-turn, messy situations, even the most capable frontier models still struggle to notice counterintuitive patterns shown in data. This will continue to inform the design of our own data agents, which we’ve intentionally made auditable and less-autonomous than many other agents on the market: we continue to believe that there are not yet models and harnesses capable of highly independent, green-field data analyses.

Posit Assistant’s harness helps

That said, we’ve been encouraged (and somewhat surprised) to see that Posit Assistant’s harness seems to improve agents’ ability to interpret counterintuitive plots. Through some confluence of factors arising from the agents’ prompting, Posit Assistant scores more highly on bluffbench than the minimally sufficient harness from the open source eval:

This correctness boost also holds up in comparison to another popular coding agent. Coupled with the UI affordances that make it easier for users to audit the agent’s code and results, we’re excited to see that Posit Assistant seems to be a step forward in what’s possible for correct agent-assisted data analysis.

debrief is on CRAN:

install.packages("debrief")
# or the development version:
pak::pak("r-lib/debrief")

From guessing to measuring

Prompt an AI agent to make your R code faster, and it will either declare that a bottleneck exists without evidence, or try to use Rprof() directly. We find that profvis() is better and easier to use than Rprof() directly, as it provides a more user-friendly interface and visualizations. But that interface is designed for human eyes, not for an LLM reading a transcript.

This is where debrief comes in. It turns the output of profvis() into a text-based summary that can be easily read and understood by AI agents. Every function is prefixed pv_ (for profvis) and returns text designed to be read top to bottom:

library(debrief)

p <- profvis::profvis(slow_function(data))
pv_print_debrief(p)
#> ## PROFILING SUMMARY
#>
#>
#> Total time: 190 ms (19 samples @ 10 ms interval)
#> Source references: available
#>
#>
#> ### TOP FUNCTIONS BY SELF-TIME
#>    110 ms ( 57.9%)  paste
#>     20 ms ( 10.5%)  <GC>
#>     10 ms (  5.3%)  .bincode
#>     10 ms (  5.3%)  any
#>     10 ms (  5.3%)  anyDuplicated.default
#>     10 ms (  5.3%)  apply
#>     10 ms (  5.3%)  rnorm
#>     10 ms (  5.3%)  unlist
#>
#> ### TOP FUNCTIONS BY TOTAL TIME
#>    180 ms ( 94.7%)  FUN
#>    180 ms ( 94.7%)  lapply
#>    180 ms ( 94.7%)  process_data
#>    140 ms ( 73.7%)  summarize_data
#>    110 ms ( 57.9%)  paste
#>     30 ms ( 15.8%)  clean_data
#>     20 ms ( 10.5%)  <GC>
#>     20 ms ( 10.5%)  apply
#>     10 ms (  5.3%)  .bincode
#>     10 ms (  5.3%)  [.data.frame
#>
#> ### HOT LINES (by self-time)
#>    120 ms ( 63.2%)  analysis.R:22
#>                    list(
#>     10 ms (  5.3%)  analysis.R:9
#>                    x <- rnorm(n)
#>
#> ### HOT CALL PATHS
#>
#> 110 ms (57.9%) - 11 samples:
#>     lapply
#>   -> FUN
#>   -> process_data
#>   -> summarize_data (analysis.R:5)
#>   -> paste (analysis.R:22)
#>
#> 10 ms (5.3%) - 1 samples:
#>     base::tryCatch
#>   -> any
#>
#> 10 ms (5.3%) - 1 samples:
#>     lapply
#>   -> FUN
#>   -> process_data
#>   -> clean_data (analysis.R:4)
#>   -> [.data.frame (analysis.R:15)
#>   -> anyDuplicated.default
#>
#> 10 ms (5.3%) - 1 samples:
#>     lapply
#>   -> FUN
#>   -> process_data
#>   -> clean_data (analysis.R:4)
#>   -> cut.default
#>   -> .bincode
#>
#> 10 ms (5.3%) - 1 samples:
#>     lapply
#>   -> FUN
#>   -> process_data
#>   -> clean_data (analysis.R:4)
#>   -> scale.default
#>   -> apply
#>   -> FUN
#>   -> <GC>
#>
#> ### MEMORY ALLOCATION (by function)
#>    51.28 MB paste
#>    10.01 MB anyDuplicated.default
#>     2.90 MB any
#>     1.62 MB rnorm
#>
#> ### MEMORY ALLOCATION (by line)
#>    51.28 MB analysis.R:22
#>             list(
#>     1.62 MB analysis.R:9
#>             x <- rnorm(n)
#>
#> ### Next steps
#> pv_focus(p, "paste")
#> pv_source_context(p, "analysis.R")
#> pv_suggestions(p)
#> pv_help()

pv_print_debrief() is meant as the first entry point after profiling. It gives a comprehensive overview of the profile with a number of sections.

• Top functions by self-time and total time
• Hot lines and hot call paths
• Memory allocation by function and by line
• Next steps

Both the hot lines and hot paths sections link back to source references when available, Especially relevant if the bottleneck is happening in a common function name like paste() that is scattered across your package. With this, we know exactly which paste() call is the culprit.

Each function in {debrief} also prints the name of the possible next functions to run, so the assistant can drill down into the details.

debrief is a new package. Its output almost certainly isn’t part of any model’s training data. And output is also very unlikely to be added, as profiling code is rarely committed. This means that the package tries to be self-documenting by design, With the hope that an AI agent doesn’t need to read the documentation to understand how to use it.

Getting an agent into the session

While you can use debrief with any AI agent, it works better with agents that keep a persistent R session. Otherwise, it will need to rerun the profile every time it wants to check the results of an edit. You also won’t be able to take full advantage of the “Next steps” hints, which are designed to guide the agent through drilling down into the profile.

Posit Assistant is the easiest way to do this. It runs in the same session as you, so you can be a bigger part of the process. The same assistant runs in Positron, RStudio, or the terminal, so you can profile interactively or drive the whole loop headlessly from the pa CLI.

If you aren’t using RStudio or Positron, or prefer an agent like Claude Code or Codex, mcp-repl gives you the same thing. It’s an MCP server that hands any MCP-capable agent a persistent R (or Python) session, so you can load debrief and run the profiler once, then drill down as needed.

Trying it out

The point of debrief is to put profiling results in a form an agent can easily interact with, so it can measure instead of guess and iterate toward faster code. We have already used it this way: tidymodels/textrecipes#309 is a profiling-driven optimization of step_word_embeddings(), where each round of profile, read, change, and re-measure was guided by debrief’s summaries.

Install debrief, point an agent at a slow function, and let it profile.

install.packages("pkgsite")

pkgsite is inspired by Python’s Quartodoc, which does the same for Python packages.

Why pkgsite?

The main website builder for R packages is pkgdown. It goes all the way to a finished, publication-ready HTML website in one step, and for most packages that is exactly what you want. It is mature, has a large ecosystem of themes and extensions, and just works.

pkgsite, on the other hand, only creates .qmd files with the help content. You decide how to structure the site around them, and Quarto handles the final HTML output.

To see what that looks like, compare the source .Rd file for llm_sentiment() in mall with the .qmd file pkgsite generated from it.

Two cases where we have seen it make a difference are:

• Examples that require local resources
• Unified R and Python Quarto sites

Examples that require local resources

Some packages depend on things that are not available on automated build and publishing platforms such as GitHub Actions or Netlify: databases, large language models, or Spark clusters. Running their examples there is not feasible, yet you still want working, rendered documentation.

Quarto’s freeze solves this cleanly. You render the site once locally where those resources are available, commit the _freeze/ folder alongside your source, and GitHub rebuilds the site on every push without re-executing a single line of code.

The mall and lang packages are concrete examples. Their function examples call an LLM, so they cannot run on those platforms. With pkgsite and freeze, rendering happens on a developer machine where the model is accessible, and the frozen output travels with the repository.

In the llm_sentiment() function, the example section looks like this in the resulting .qmd file:

## Examples
```{r}
library(mall)

data("reviews")

llm_use("ollama", "llama3.2", seed = 100, .silent = TRUE)

llm_sentiment(reviews, review)

# Use 'pred_name' to customize the new column's name
llm_sentiment(reviews, review, pred_name = "review_sentiment")
```

And this is what the rendered page looks like on the mall website:

Unified R and Python sites

If your project ships both an R package and a Python package, you can combine pkgsite’s output with Quartodoc’s output into a single Quarto website. Both tools write .qmd reference pages that Quarto assembles together, giving R and Python users a consistent experience on one site. The mall package’s reference section is a live example: R and Python pages side by side, built from two different tools, served as one site.

Getting started

From within your package directory, one function call does the work:

library(pkgsite)
write_reference()

write_reference() creates a reference/index.qmd that links to all your exported functions, and converts each .Rd file in man/ into its own .qmd reference page.

You can customize its behavior through arguments. For example, if you want to skip running the examples when Quarto renders the reference pages:

write_reference(examples = FALSE, not_run_examples = FALSE)

Calling it without arguments reads any configuration from a pkgsite: section at the top level of _quarto.yml. Following the same convention as Quartodoc, the Python equivalent, this is where you set the package root, the output folder, templates, and optionally how functions are grouped and ordered in the index:

pkgsite:
  dir: "."                    # path to the package root
  reference:
    dir: reference            # where to write the .qmd files
    not_run_examples: false   # whether to execute \dontrun{} examples
    template: inst/templates/_reference.qmd   # custom page template
    index:
      file: index.qmd         # name of the index file
      template: inst/templates/_index.qmd     # custom index template
      contents:               # optional: custom function grouping
        - section: "Write files"
          contents:
            - write_reference.qmd
            - write_reference_index.qmd
            - write_reference_pages.qmd
        - section: "Conversion"
          contents:
            - rd_to_qmd.qmd
            - rd_to_list.qmd
            - index_to_qmd.qmd

If you omit contents, pkgsite falls back to grouping by roxygen2 @family tags, then alphabetical order. You only need to re-run write_reference() when you add, rename, or remove exported functions.

Use arguments for one-off adjustments; the _quarto.yml configuration is the better choice when you want those settings to apply consistently every time write_reference() is called.

This is what the rendered reference index page looks like on the pkgsite website, using the grouping specified in the example YAML above:

Customizing the page layout

The layout of every reference page and the index is driven by a Quarto template file that uses four-curly-brace placeholders like {{{{title.description}}}}. The prefix — title. or notitle. — controls whether the section heading is included. The defaults work well for most packages, but if you want to re-order sections, add a logo, link to source code, or adjust per-page frontmatter, you can supply your own template. For example, a minimal template that shows only the title, description, and examples looks like this:

---
title: "{{{{notitle.title}}}}"
---

## {{{{notitle.title}}}}

## Description
{{{{title.description}}}}

## Examples
{{{{title.examples}}}}

The Customize the pages article covers the full set of available placeholders.

The mall package is a good example of this. Its custom template makes two additions to the default: it adjusts how knitr renders table column widths, and it adds a link to the R source code of each function on GitHub:

Publishing to GitHub Pages

To publish your site on every push to main, you need a GitHub Actions workflow that runs quarto render and deploys the output to the gh-pages branch. The GitHub Pages article on the pkgsite website walks through the full setup with a working example.

Auto-linking function names

pkgsite can turn every function name in your prose into a link pointing to its own reference page automatically. Mention llm_sentiment() anywhere in your documentation and it becomes a clickable link to the llm_sentiment reference page, no extra markup needed. The same GitHub Pages article covers how to enable it.

Learn more

The full documentation lives at edgararuiz.github.io/pkgsite, and the source is on GitHub. Issues and feature requests go to the issue tracker.

We’re delighted to announce the release of webR 0.6.0. WebR brings R to the web browser using WebAssembly, powering Quarto Live, Shinylive, and other interactive R experiences.

As a reminder of what webR can do, here is an interactive code editor running R in the browser. Try it out!

It’s been almost a year since I’ve written a blog post about webR, and so this post highlights some key features and improvements over the last few releases. For a full list of changes, see the recent release notes on GitHub.

Updates to R, Emscripten, and LLVM

We’ve updated the version of R on which webR is based to version 4.6.0, ensuring we have all the latest improvements and bug fixes from the R core team. For example, the new %notin% operator can now be used:

Under the hood, we’ve also upgraded Emscripten to version 5.0.7. Emscripten serves as the crucial layer between the web browser and R’s source code, playing a role similar to an operating system. We’ve also updated the version of LLVM we use to compile Fortran sources to 21.1.8.

Improvements to Fortran on WebAssembly

The R source code contains a surprising amount of Fortran code (the bulk of which written in F77-style), even today. For webR, we rely on a forked version of LLVM Flang with custom patches to add support for emitting WebAssembly. I won’t go into the deep technical details here, but I have written about it before if you are interested.

For a long time, dynamic array operations introduced in more modern Fortran standards were not supported by our fork. This meant that some packages which use these Fortran features would not work in webR, crashing with a dense and largely unhelpful runtime error message:

program p
  integer :: a(5) = [1, 2, 3, 4, 5]
  print *, sum(a)
end program

$ ./previous/flang -c arr.f90 -o arr.o
$ emcc arr.o libFortranRuntime.a -o arr.js
$ node arr.js
  fatal Fortran runtime error(...reduction-templates.h(90)): Internal error:
  RUNTIME_CHECK(TypeCode(CAT, KIND) == x.type() || ...) failed

However, thanks to a hint originating from a community member, we’ve now added a workaround for the underlying compiler problem, and R packages which rely on these Fortran features should now work in webR without crashing:

$ ./latest/flang -c arr.f90 -o arr.o
$ emcc arr.o libFortranRuntime.a -o arr.js
$ node arr.js
  15

Additional system libraries

We’ve also added or updated the following system libraries compiled to WebAssembly, which are now available for use by R packages in webR:

• cacert.pem 2026-05-14
• fontconfig v2.15.0
• libpoppler v24.12.0
• libsodium v1.0.22
• libtiff v4.7.1
• libuv v1.44.2
• openssl v3.5.1

Async/await in webr::eval_js()

One of the biggest issues when working with webR’s JavaScript API is that we must block the worker thread running the WebAssembly R process. This is required to make sure we can wait and take input from the user, both at the top-level and in functions like readline() or browser(). Previously, this meant that only synchronous JavaScript code could be run from R via webr::eval_js(), and JavaScript features like Promise, async or await were not available.

By proxying the JavaScript code to the main thread, we’ve added support for running asynchronous JavaScript code in webr::eval_js(). You can now use await = TRUE to wait for a Promise to resolve before returning a value to R:

webr::eval_js("new Promise((res) => res(1729))")

[1] 1729

Or equivalently, you can use await inside an async JavaScript function:

webr::eval_js(r"{
  (async () => {
    await new Promise(r => setTimeout(r, 500));
    return 87539319;
  })();
}", await = TRUE)

[1] 87539319

Using curl under WebAssembly

Using similar techniques, we have also added support for proxying WebSocket traffic via the main thread. This, combined with some other work for libcurl in WebAssembly, means we can now use the curl and httr2 R packages in webR.

Try out a full example R script using httr2 in the webR app.

Dark mode for the webR app

Speaking of the webR app, if your system is set to dark mode the webR app will now automatically switch to a dark theme. This feature was contributed by an attendee of Tidyverse Developer Day 2025. Thanks, Kyle!

Acknowledgements

And, as always, a huge thank you to everyone else who has contributed to webR, either by submitting bug reports, contributing code, or just sharing feedback.

@AABoyles, @ai-petri, @brendanhcullen, @bryce-carson, @chizapoth, @coatless, @daniel-woodie, @dipterix, @dusadrian, @georgestagg, @goebbe, @HenrikBengtsson, @jeroen, @jgf5013, @jmbo1190, @JosiahParry, @khusmann, @kyleGrealis, @laderast, @lpmi-13, @pepijn-devries, @seanbirchall, @szcf-weiya, @timelyportfolio, @tulaydixon, @WardBrian, and @WillemSleegers.

1. Visualize: execute ggsql queries, rendered as visualizations in the chat.
2. Query: execute SQL queries, rendered as tables/text in the chat.
3. Filter: execute filter SQL queries on predetermined views, allowing the LLM to reactively drill into the data in response to user questions.

Equipped with these tools, your dashboard can offer a balance between “curated insights” and “explorable data” — surfacing interesting trends and summaries upfront, but also letting users ask follow-up questions that go beyond the predetermined views. The video below gives you a feel for this workflow in action¹. Note how the conversation starts off by filtering the predetermined views, but then progresses into more general exploration.

Crucially, every one of querychat’s tools works by executing SQL (or ggsql) — never arbitrary code. Every query is also fully visible and reproducible: users can inspect the code behind any response, and copy it to run independently. In the next version of querychat, you can also expect to see a rich export capability, allowing you to save the insights you care about in a format you care about (e.g. a Quarto dashboard, Jupyter notebook, or R Markdown file).

Restricting querychat’s code execution capability to SQL (or ggsql) is an intentional design choice. We can guarantee that querychat does not run arbitrary R or python code, making it viable for production environments where security and control are required. As a result, querychat may not be as capable as a general coding assistant like Posit Assistant, but you generally don’t want production apps that let users execute arbitrary code. By focusing on SQL execution, querychat can maintain a strong security posture while still enabling useful exploration of data via natural language.

Get started

Getting started is as easy as pointing QueryChat() at your data source and getting set up with an LLM. Although we recommend frontier models for an ideal experience, open-weight models have recently become quite capable, and can be a great way to get started without needing API access or incurring costs.

For this article, I’m using LMStudio to run google/gemma-4-26b-a4b locally on my fairly standard MacBook Pro. If you prefer a different LLM or provider, refer to the docs (R) to see how to configure.

Once you’ve picked an LLM, next step is ensuring both querychat and ggsql are installed. Here we’ll also use the palmerpenguins data set to keep examples lightweight and self-contained, but you can point querychat at anything from a data frame to a remote database connection (R).

pip install "querychat[viz]" palmerpenguins

install.packages(c("querychat", "ggsql", "palmerpenguins"))

Basic usage

Once installed, you can get a basic chat UI using the code below. We’ll include just the query and visualize tools here since the filter tool is designed to work in the context of a larger dashboard, which we’ll cover in the next section.

from shiny.express import ui
from querychat.express import QueryChat
from palmerpenguins import load_penguins

qc = QueryChat(
    load_penguins(), 
    "penguins", 
    client="lmstudio/google/gemma-4-26b-a4b",
    tools=("query", "visualize")
)

qc.ui()

ui.page_opts(fillable=True)

shiny run app.py

library(shiny)
library(querychat)
library(palmerpenguins)

qc <- QueryChat$new(
  penguins,
  client = "lmstudio/google/gemma-4-26b-a4b",
  tools = c("query", "visualize")
)

ui <- bslib::page_fillable(qc$ui())
server <- function(input, output, session) { qc$server() }
shinyApp(ui, server)

shiny::runApp("app.R")

Upon opening the app, the LLM greets us with a welcome message tailored to the data source we’ve provided:

Query tool

For questions addressable via numerical summaries, the LLM requests the query tool with relevant SQL. The LLM may also choose to collapse details of the tool call, especially when it decides to weave the results within its actual response. That said, full details can always be inspected by clicking on the “Query Data” tool call display:

Visualize tool

For questions that are better suited to a visual response, the LLM requests the visualize tool with relevant ggsql. In addition to rendering the plot inline for the user to see, that same plot is also provided to the LLM so that it can interpret the result:

A couple noteworthy things about this experience:

• The footer includes options to view the underlying ggsql query, download the plot as an image, and expand the display to full screen.
• Plots are always shown by default, but can be collapsed by clicking the header.

This hopefully gives you a taste for how easy it is to get set up with a basic querychat UI and start asking questions of your data. You may, however, be wondering how querychat is able to produce correct queries and how the code execution actually works. Let’s dive into those details next.

How does it work?

Execution

One important thing to understand about querychat is that the LLM itself is not handling the SQL execution – querychat is. Where that execution ultimately happens depends on what data source you’re providing. If you’re pointing querychat at an in-memory data frame, the execution happens in-process using DuckDB. If you’re pointing it at a database connection, the execution happens against that database. In either case, the LLM is generating queries based on its understanding of the data schema and any additional context you’ve provided, not the actual data. This separation is what allows querychat to maintain a strong security posture, scale to large data, and deliver a good user experience.

Schema discovery

To elaborate on what “understanding of the data schema” actually means: when you point querychat at a data source, it automatically extracts column names, types, numerical ranges, and categorical values. This information is included in the system prompt for the LLM, so it has a clear picture of what the data looks like and can generate accurate queries without needing to see the actual data. For many datasets, this is enough to get good results out of the box.

Additional context

For more complex datasets or domain-specific questions, you can also provide additional context through a plain-text data description. querychat now also automatically picks up on Snowflake Semantic Models when connected to a Snowflake database, giving the LLM access to authoritative definitions of business logic and metrics without any manual configuration. We hope to add more integrations to other semantic layer formats in the future.

To learn more, querychat’s website has more details on data sources (R), providing context (R), and tool execution (R).

Chat-driven dashboards

A chat interface alone likely isn’t the experience you want to ship to end users — the better pattern is to surface interesting findings first, then let users explore beyond them. This is where querychat begins to really shine: the chat interface we already covered can easily be embedded inside of a larger app that includes other outputs – plots, tables, value boxes, etc. querychat comes with another tool designed for this use case – the filter tool – allowing the LLM to effectively drill down into relevant sections of the data in the dashboard in response to user questions.

The key integration point is df(), a reactive value that reflects the current state of the data after any filtering applied by the LLM. Use df() as the data source for your plots, tables, and value boxes, and they’ll automatically update in response to user questions in the chat.

from shiny.express import render, ui
from querychat.express import QueryChat
from palmerpenguins import load_penguins
from faicons import icon_svg

qc = QueryChat(
    load_penguins(),
    "penguins",
    client="lmstudio/google/gemma-4-26b-a4b",
    tools=("filter", "query", "visualize")
)

qc.sidebar()

with ui.layout_columns(fill=False):
    with ui.value_box(showcase=icon_svg("binoculars")):
        "Penguins"
        @render.text
        def count():
            return len(qc.df())

    with ui.value_box(showcase=icon_svg("fingerprint")):
        "Species"
        @render.text
        def species():
            return qc.df()["species"].nunique()

    with ui.value_box(showcase=icon_svg("gauge-high")):
        "Avg Body Mass"
        @render.text
        def avg_mass():
            return f"{qc.df()['body_mass_g'].mean():.0f}g"

with ui.layout_columns():
    with ui.card():
        ui.card_header("Bill Dimensions")
        @render.plot
        def scatter():
            import plotnine as p9
            
            return (
                p9.ggplot(qc.df(), p9.aes("bill_length_mm", "bill_depth_mm", color="species"))
                + p9.geom_point()
            )

    with ui.card():
        ui.card_header("Measurements")
        @render.data_frame
        def table():
            return qc.df()

ui.page_opts(fillable=True)

library(shiny)
library(bslib)
library(querychat)
library(DT)
library(ggplot2)
library(palmerpenguins)

qc <- QueryChat$new(
  penguins,
  client = "lmstudio/google/gemma-4-26b-a4b",
  tools = c("filter", "query", "visualize")
)

ui <- page_sidebar(
  sidebar = qc$sidebar(),
  layout_columns(
    fill = FALSE,
    value_box("Penguins", textOutput("count"), showcase = bsicons::bs_icon("binoculars")),
    value_box("Species", textOutput("species"), showcase = bsicons::bs_icon("fingerprint")),
    value_box("Avg Body Mass", textOutput("avg_mass"), showcase = bsicons::bs_icon("speedometer"))
  ),
  layout_columns(
    card(card_header("Bill Dimensions"), plotOutput("scatter")),
    card(card_header("Measurements"), DTOutput("table"))
  )
)

server <- function(input, output, session) {
  qc_vals <- qc$server()
  df <- qc_vals$df
  output$count <- renderText(nrow(df()))
  output$species <- renderText(length(unique(df()$species)))
  output$avg_mass <- renderText(paste0(round(mean(df()$body_mass_g, na.rm = TRUE)), "g"))
  output$scatter <- renderPlot({
    ggplot(df(), aes(bill_length_mm, bill_depth_mm, color = species)) +
      geom_point()
  })
  output$table <- renderDT(df())
}

shinyApp(ui, server)

Custom tools

querychat comes with three built-in tools, but you can also easily add your own custom tools. This is possible thanks to the extensible foundation provided by chatlas (ellmer). These packages also make it quite easy to implement tools – all you really need is a Python / R function that performs some operation. You can also fully customize the display shown, thanks to their rich support for tool call displays (R).

To give you a sense of what other capabilities are possible, you could start out as simple as querying real-time weather information, but also get as sophisticated as a RAG-like knowledge retrieval agent. For example, here’s how you’d let users ask whether weather conditions might relate to trends in your data:

import requests
from querychat.express import QueryChat
from chatlas import ChatLMStudio
from palmerpenguins import load_penguins

chat_client = ChatLMStudio(model="lmstudio/google/gemma-4-26b-a4b")

def get_current_weather(lat: float, lng: float):
    """Get the current weather for a location."""
    lat_lng = f"latitude={lat}&longitude={lng}"
    url = f"https://api.open-meteo.com/v1/forecast?{lat_lng}&current=temperature_2m,wind_speed_10m&hourly=temperature_2m,relative_humidity_2m,wind_speed_10m"
    response = requests.get(url)
    return response.json()["current"]

chat_client.register_tool(get_current_weather)

qc = QueryChat(
    load_penguins(),
    "penguins",
    client=chat_client
)

library(querychat)
library(ellmer)

chat_client <- chat_lmstudio(model = "lmstudio/google/gemma-4-26b-a4b")

get_current_weather <- function(lat, lng) {
  lat_lng <- paste0("latitude=", lat, "&longitude=", lng)
  url <- paste0("https://api.open-meteo.com/v1/forecast?", lat_lng, "&current=temperature_2m,wind_speed_10m&hourly=temperature_2m,relative_humidity_2m,wind_speed_10m")
  response <- httr::GET(url)
  httr::content(response)$current
}

chat_client$register_tool(
  tool(
    get_current_weather,
    "Get the current weather for a location",
    lat = type_number("Latitude"),
    lng = type_number("Longitude")
  )
)

qc <- QueryChat$new(
  palmerpenguins::penguins,
  client = chat_client
)

Underneath the hood, querychat’s built-in tools use this same foundation. The “magic” of these tools really breaks down to three key insights:

1. LLMs are very good at translating natural language into code.
2. Tool call arguments can be executable code (like SQL or ggsql) rather than just simple values.
3. Tool calls can manage reactive state in a Shiny app — for querychat, that state is the current filter query, but the same pattern could control input controls, tab selection, or other UI state.

What’s next?

This release is just the beginning of our vision for (responsibly) exploring data via natural language. We’re excited to see what you build with it, and we’re already thinking about the next set of features to add. Some things on our near-term roadmap:

• Multiple tables.
• Reproducible takeaway artifacts, like Quarto dashboards
• Support for more semantic layer solutions beyond Snowflake, so more users can give the LLM authoritative definitions of their business logic.

Learn more

• querychat documentation (R) — full guides on data sources, context, tools, and deployment
• ggsql — the grammar of graphics for SQL that powers querychat’s visualizations
• chatlas (ellmer) — the underlying LLM tool-calling libraries, useful for building custom tools
• shinychat (R) — the chat UI component that querychat builds on
• Shiny (R) — the web framework powering querychat apps
• Source on GitHub — issues, discussions, and contributions welcome

install.packages("dbplyr")

This is another release that has benefited from Claude Code’s help, allowing me to rip through a large number of smaller issues (~50!) where the correct solution is easily verified. And those time savings allowed me to tackle some more challenging and more impactful features, such as new ADBC and JDBC backends and a new sql_dialect() generic that finally separates how you connect to a database from which SQL dialect to use. The release also includes new translations, a couple of useful helpers, and a substantial cleanup of long-standing deprecations. This post covers the highlights for everyday users in the first half, then dives into the changes that matter for backend developers at the end. Read the full list of changes in the release notes.

library(dbplyr)
library(dplyr, warn.conflicts = FALSE)

Lifecycle changes

A handful of things you may have been using have been deprecated or removed. The biggest ones to know about:

• do() is deprecated. It was the only piece of dplyr 0.x syntax that dbplyr still supported, and it never fit cleanly into SQL. If you have code that uses it, the simplest path is to collect() first and then use your favourite tidyverse tools on the resulting data frame.

• str_like(ignore_case = TRUE) is deprecated in favour of the new str_ilike() (thanks to @edward-burn). This brings the dbplyr translation in line with the recent updates to stringr.

• The cte argument of collect(), compute(), show_query(), remote_query(), and db_sql_render() is deprecated. Pass sql_options = sql_options(cte = TRUE) instead. This consolidates a growing pile of one-off flags into a single options object that we can extend without tweaking every render function.

A few deprecations that have been warning for multiple years are now defunct: passing ... to across()/if_all()/if_any(), using by = character() to perform a cross join (use cross_join() instead), and calling compute(temporary = FALSE) without a name. A few defunct functions/arguments have been removed entirely, including group_by(add = ), partial_eval(var), and src_sql().

If you’re a backend developer, there’s a longer list of changes that affect you — see the Notes for backend developers at the end of this post.

New backends: ADBC and JDBC

dbplyr already worked with ODBC (thanks to {odbc}). With 2.6.0, you can now connect through two more transport layers:

• ADBC (Arrow Database Connectivity) is a relatively new project from the Apache Arrow community. It moves data between R and the database as Arrow buffers, which avoids the per-row serialization overhead of older protocols and can be much (much!) faster. dbplyr supports ADBC connections through {adbi}.

• JDBC (Java Database Connectivity) is the standard database protocol on the JVM, with high-quality drivers for nearly every database under the sun. dbplyr supports JDBC connections through {RJDBC}.

The reason these new backends slot in so cleanly is a new generic, sql_dialect(). Until now, dbplyr picked SQL translations based on the connection class itself, which meant every new transport had to either masquerade as an existing connection or carry its own copy of every translation. (Or as with {odbc}, hack the database name into the object class.) That’s why ADBC and JDBC support was hard to add in the past.

sql_dialect() separates the two concerns: a connection’s job is to know how to talk to the server and fetch data, and the dialect’s job is to know how to generate the right SQL. For example, when you connect over JDBC or ADBC to Postgres, dbplyr now uses the same translations it would use over ODBC or via RPostgres. This simplified a bunch of dbplyr code and made it very easy to add the new ADBC and JDBC backends. Finally, if the default dialect isn’t quite right, you can override it with with_dialect().

New translations

A few translations are now available.

bind_queries() is the dbplyr equivalent of dplyr::bind_rows(): it combines several lazy queries into one using UNION ALL, aligning columns as needed.

con <- DBI::dbConnect(RSQLite::SQLite(), ":memory:")
db1 <- copy_to(con, tibble::tibble(x = 1:3), "db1")
db2 <- copy_to(con, tibble::tibble(y = 1:3, x = 4:6), "db2")

bind_queries(db1, db2) |> show_query()

<SQL>
SELECT *, NULL AS `y`
FROM `db1`

UNION ALL

SELECT `x`, `y`
FROM `db2`

filter_out() (from dplyr 1.2.0) is now translated. It’s the opposite of filter(), dropping rows where the conditions are true, rather than keeping those rows.

db3 <- copy_to(con, tibble::tibble(x = c(1, 2, NA), g = c(1, 1, 2)), "db3")
db3 |> filter_out(x == 2)

# A query:  ?? x 2
# Database: sqlite 3.52.0 [:memory:]
      x     g
  <dbl> <dbl>
1     1     1
2    NA     2

db3 |> filter(x == 2)

# A query:  ?? x 2
# Database: sqlite 3.52.0 [:memory:]
      x     g
  <dbl> <dbl>
1     2     1

anyNA() is now translated, in the same way as any(is.na(x)):

db3 |> summarise(missing = anyNA(x), .by = g) |> show_query()

<SQL>
SELECT `g`, MAX((`x` IS NULL)) AS `missing`
FROM `db3`
GROUP BY `g`

And %notin% (new in R 4.6.0) is now translated to NOT IN:

db3 |> filter(x %notin% c(1, 2)) |> show_query()

<SQL>
SELECT *
FROM `db3`
WHERE (`x` NOT IN (1.0, 2.0))

Three other changes are worth knowing about:

• last_sql() returns the SQL of the most recent query dbplyr generated. This is mostly useful when debugging a problem that surfaces inside collect() or compute(), when you don’t have a convenient handle on the query to call show_query() on.

• copy = "inline" is now an option for joins, set operations, and row operations. When you join a local data frame to a remote table, dbplyr normally copies it to a temporary table on the server. With copy = "inline", it inlines the data into the SQL directly using copy_inline(), which is handy when you can’t (or don’t want to) create a temporary table.

• Thanks to @shearerpmm, this release also gains a translation layer for IBM DB2. The translation includes paste()/paste0() (using ||), DB2-specific casts, runif(), a comprehensive set of string and date functions, the clock helpers, and statistical aggregates.

Notes for backend developers

If you maintain a dbplyr backend, several things have changed and you may need to make some adjustments. Hopefully none of this is a surprise, since I’ve already filed PRs to all CRAN packages that needed changes 😀.

Most importantly, the new sql_dialect() generic separates out the connection details from SQL generation. You should create a sql_dialect() method for your connection that returns a new_sql_dialect() object. new_sql_dialect() lets you customize the full surface of SQL generation, including how identifiers are quoted (which allows tests to look much closer to real SQL). Once you have that object, all the sql_ generics can dispatch on it, rather than on the connection object.

There are two new extension points for customization:

• db_table_drop_if_exists() is a new generic that lets backends customize how tables are dropped when overwrite = TRUE. It was added to support Oracle, which needs a slightly different DROP TABLE incantation.

• sql_set_op_method() is a new generic that lets set operations (union(), intersect(), setdiff()) customize the SQL keyword they generate. Useful when a backend needs UNION DISTINCT instead of UNION, or MINUS instead of EXCEPT.

And two deprecations:

• sql_expr_matches() is deprecated. Provide is_distinct_from() and is_not_distinct_from() translations instead. These power joins with na_matches = "na" and the new filter_out() translation.

• as.sql() is deprecated as part of a major internal refactor of how sql() and ident() are used. You can generally replace it with as_table_path() if used to refer to a table, or sql() if you want to indicate it’s raw SQL.

I’ve also overhauled the exported tools for generating SQL strings. The newly exported sql_glue() (implicit dialect, for use inside sql_translation()) and sql_glue2() (explicit dialect, for everywhere else) provide a glue-style syntax for building SQL strings. They replace the now superseded build_sql(), sql_expr(), and sql_call2().

If you are preparing for your next talk (whether at SciPy or another conference), you might be looking for the most effective way to showcase code and its output in your deck. And, if we do say so ourselves, Quarto is the premier tool for creating polished presentations that shine in scientific contexts.

Why? Because Quarto was designed just for this purpose! As an open-source scientific and technical publishing system, Quarto allows you to craft dynamic content that weaves your narrative together with Markdown and Python code, and then renders them into a single file that elegantly showcases your results. By using a single source file, you don’t have to manually copy and paste code or its outputs. Any changes you make are reflected in the latest version by rerendering the document.

Hopefully, this has piqued your interest! Curious how it looks? We built the deck below in Quarto; keep reading to learn how.

Get started with slides in Quarto

Install Quarto

We recommend using Positron as your editor, since Quarto is preinstalled. If you are using VS Code, install the Quarto CLI and the Quarto VS Code Extension.

Create a new document

Open a new folder, enter the Command Palette (Cmd+Shift+P) and search for Quarto: New Quarto document (qmd). Save the file as index.qmd.

Change the format to revealjs

Your new document will include a YAML header for managing your document’s metadata. You’ll see that the default is set to HTML via format: html:

---
title: "Untitled"
format: html
---

However, Quarto is incredibly versatile, and it can render your work into PDFs, Word documents, and much more! We recommend the reveal.js format for creating aesthetically pleasing code-centric slides. reveal.js also provides a variety of useful features tailored for displaying scientific results and technical workflows.

You can switch your document from HTML to reveal.js by updating the format in your YAML header to format: revealjs:

---
title: "Untitled"
format: revealjs
---

Click the Preview button () at the top left of your editor to see what your presentation looks like!

You can also preview from the command line:

quarto preview index.qmd

Build the slides

From here, we can move on to the fun part: building our slides!

Edit metadata

As alluded to earlier, we edit the metadata document by modifying the YAML header. You can change the title, add yourself as an author, and add your presentation date:

---
title: "Make your SciPy presentation in Quarto"
author:
  - Isabella Velásquez
  - Charlotte Wickham
date: 2026-07-14
format: revealjs
---

Those values then set up your title slide.

Add your first slide

Below the YAML header is where you write your slides. Quarto uses Markdown, a text formatting language, for text:

---
title: "Make your SciPy presentation in Quarto"
author:
  - Isabella Velásquez
  - Charlotte Wickham
date: 2026-07-14
format: revealjs
---

Slides are just Markdown and code:

- Write your narrative in **Markdown**
- Weave in **Python** code and its output
- Render it all to one reproducible file

You can control aspects of your presentation by nesting options under revealjs in the YAML header. For example, you can make any list display incrementally by adding incremental: true:

---
title: "Make your SciPy presentation in Quarto"
author:
  - Isabella Velásquez
  - Charlotte Wickham
date: 2026-07-14
format:
  revealjs:
    incremental: true
---

Now as you advance the slides, the bullets appear one at a time.

Add a new slide

To add a new slide, add a new heading. A Level 1 heading adds a new section, while a Level 2 heading adds a new slide.

# Features for showing code

## Add Python code cells

Continue adding new slides until you’re done!

Add Python code cells

To add Python code to your slide, put it within a code cell, which is delineated by three backticks ``` and python within curly braces. By default, Quarto reveal.js presentations do not show your code cells, because they assume you are presenting just your output. If you do want to show your code, you can add a cell option, designated by a special comment, #|, followed by the option using YAML syntax. In this case, echo: true lets Quarto know to show the code.

## Add Python code cells

```{python}
#| echo: true
from plotnine import *
from plotnine.data import anscombe_quartet
```

Code output is included

When you render, Quarto runs the code cells and includes their output right below the code:

## Code output is included

```{python}
#| echo: true
anscombe_quartet.head()
```

Show code without running it

Some code only makes sense to run live — like %view, which opens your data in Positron’s Data Explorer. To show such code without running it, add the eval: false cell option, which tells Quarto to show the cell but not evaluate it:

## You can show code without running it

```{python}
#| echo: true
#| eval: false
%view anscombe_quartet
```

Add a theme

The Quarto default look is great, but say you want to add your own theming. You can do that in a single YAML file using brand.yml.

In your root directory, create a file called _brand.yml. Add specifications as listed on the brand.yml documentation site. You can edit the font, colors, and more (add as much or as little as you’d like). Next time you render your slides, the brand will be automatically picked up!

If you’d like a _brand.yml file to get you started, here is one that mimics the SciPy conference style. Put it in the root directory of your presentation, and it will look like this:

Features for showcasing Python code

You may be thinking, this is great, but I can make slides in any old software! True, but Quarto has specific features that really elevate your audience’s experience.

Code line highlighting

Sure, you can show a block of code on your slide. But you’re usually talking about a specific line or lines of code at a time. If you want to draw your audience’s attention to a specific section of your code, you can use code line highlighting.

For example, if you want to first highlight line 2, then lines 3 through 4, then line 5, you can add the code-line-numbers cell option:

```{python}
#| echo: true
#| code-line-numbers: "2|3-4|5"
(
    anscombe_quartet
    .groupby("dataset")[["x", "y"]]
    .apply(lambda g: g["x"].corr(g["y"]))
    .round(2).to_frame("correlation")
)
```

Scroll through to see what it looks like:

Show code output in a new slide

When rendered, the slides will automatically resize based on the content. However, this means if you have a lot of code and a large output (like an image), it will be hard to see both in a single slide.

Luckily, the Quarto developers have thought of this and have the output-location cell option where you designate where the output should show up. For example, to show the output on the new slide, set output-location to slide:

```{python}
#| echo: true
#| output-location: slide
(
    ggplot(anscombe_quartet, aes("x", "y"))
    + geom_point(color="sienna", fill="orange", size=3)
    + geom_smooth(method="lm", se=False, fullrange=True,
                  color="steelblue", size=1)
    + facet_wrap("dataset")
    + labs(title="Anscombe’s Quartet")
    + scale_y_continuous(breaks=(4, 8, 12))
    + coord_fixed(xlim=(3, 22), ylim=(2, 14))
    + theme_tufte(base_family="Futura", base_size=16)
    + theme(
        axis_line=element_line(color="#4d4d4d"),
        axis_ticks_major=element_line(color="#00000000"),
        axis_title=element_blank(),
        panel_spacing=0.09,
    )
)
```

Add a filename and extension

A subtle (but very helpful) feature of Quarto is the ability to specify the filename and extension of a code block, which you can use if you are talking about different files or programming languages and want to visually distinguish them. Add filename= to your code block:

```{.bash filename="Terminal"}
pip install pandas
```

<br>

```{.python filename="script.py"}
import pandas as pd
```

Extensions for scientific presentation

So far, we’ve just mentioned features that are built into Quarto; however, one of the most powerful features of Quarto is its extension system. Both the Posit developers and the community have built an incredible ecosystem of extensions that augment what Quarto can do. There are hundreds of extensions (see the Quarto gallery by Mickaël Canouil), but here are a curated few.

QuartoLive extension for interactive Python code blocks

You no longer have to switch between your slides and your IDE to run code! Using QuartoLive, you can embed interactive Python code blocks. Run the code, edit it, and rerun, all within your Quarto reveal.js presentation.

Provide a direct link to your slides

Usually, the first question asked during a presentation is, “Will the slides be provided?” Evade that question by using the QR code extension, which adds a QR code that the audience can easily scan while they watch so they can find the slides after the presentation is over.

Add accessibility features

For your audience to be able to read the text on your slides, the font size should probably be larger than you anticipate.

The reveal.js A11y extension provides accessibility features for your slide deck. One nifty feature is the ability to increase the font size on the fly. Enter the menu by pressing A, and then zoom in to what you need.

Publish and share your slides

After you’ve done the fun work of creating your slides, you’ll want to publish and share them with others. We recommend Posit Connect Cloud, which has a generous free tier for Quarto documents, Streamlit and Shiny apps, and much more.

If you’re working in Positron, the Posit Publisher extension is built in and gives you push-button deployment to Posit Connect Cloud right from your editor (in VS Code, grab it from the Marketplace).

If not, you can also publish from the command line with quarto publish, which renders your slides and uploads them:

quarto publish posit-connect-cloud index.qmd

The slides for this very post are published at posit-devrel-make-your-scipy-presentation-in-quarto.share.connect.posit.cloud.

Press F to enter full screen, and you’re ready to present!

Welcome to the wonderful world of Quarto slidecrafting

We hope that this post inspired you to give Quarto presentations a try!

We’ve only scratched the surface — the Quarto reveal.js documentation covers the full set of features for building presentations.

If you are completely new to Quarto, Charlotte’s YouTube video is a great introduction to setting it up, creating a document from scratch, and rendering it.

If you want to see what else is possible, Emil Hvitfeldt is working on a book called Slidecrafting on creating functional and beautiful Quarto reveal.js presentations through theming, layout, interactivity, and extensions.

And definitely look through Mickaël’s Quarto extension gallery to see if other extensions are useful to you. His blog post, Quarto Reveal.js Extensions to Sharpen Your Slides, also has more advanced tricks you can apply to your scientific and technical publications.

Do let us know what you end up creating!

install.packages("tidyclust")

This release brings three new families of clustering models, closer alignment with the rest of tidymodels, and a number of smaller improvements. This post covers the highlights of new models and engines, tighter integration with tidymodels, and updated parallel processing support. You can read the full list of changes in the release notes.

To get started, load the tidymodels and tidyclust packages:

library(tidymodels)
library(tidyclust)

For the examples, we will be using the penguins data set. We are imputing missing values and normalizing the predictors since distance and density-based methods are sensitive to scale and missingness.

data(penguins, package = "modeldata")

rec_spec <- recipe(~ bill_length_mm + bill_depth_mm + flipper_length_mm + body_mass_g,
                   data = penguins) |>
  step_impute_mean(all_numeric_predictors()) |>
  step_normalize(all_numeric_predictors())

New models and engines

Until now, tidyclust supported partition-based methods (k_means()) and hierarchical clustering (hier_clust()). This release expands that considerably with three new model specifications.

db_clust() fits density-based clustering models (DBSCAN), with engines for both "dbscan" and "hdbscan". Density-based methods are well suited to finding clusters of arbitrary shape and identifying outliers as noise.

To use tidyclust, we first make a specification for the clustering method, combine it with the recipe, and fit the workflow as usual.

db_spec <- db_clust(radius = 0.8, min_points = 5) |>
  set_engine("dbscan")

db_fit <- workflow(rec_spec, db_spec) |>
  fit(data = penguins)

db_fit

══ Workflow [trained] ══════════════════════════════════════════════════════════
Preprocessor: Recipe
Model: db_clust()

── Preprocessor ────────────────────────────────────────────────────────────────
2 Recipe Steps

• step_impute_mean()
• step_normalize()

── Model ───────────────────────────────────────────────────────────────────────
DBSCAN clustering for 344 objects.
Parameters: eps = 0.8, minPts = 5
Using euclidean distances and borderpoints = TRUE
The clustering contains 2 cluster(s) and 5 noise points.

  0   1   2 
  5 218 121 

Available fields: cluster, eps, minPts, metric, borderPoints

Notice the Outlier level: points in low-density regions aren’t forced into a cluster. This is also our first new engine where you don’t specify how many clusters to find up front.

gm_clust() fits Gaussian mixture models via the "mclust" engine. Rather than assigning each observation to a single cluster, mixture models describe the data as a combination of Gaussian components.

gm_spec <- gm_clust(num_clusters = 3) |> 
  set_engine("mclust")

gm_fit <- workflow(rec_spec, gm_spec) |>
  fit(data = penguins)

tidy(gm_fit)

# A tibble: 3 × 8
  component  size proportion variance mean.bill_length_mm mean.bill_depth_mm
      <int> <int>      <dbl>    <dbl>               <dbl>              <dbl>
1         1   160      0.458    0.288              -0.892              0.524
2         2    61      0.184    0.288               0.938              0.834
3         3   123      0.358    0.288               0.658             -1.10 
# ℹ 2 more variables: mean.flipper_length_mm <dbl>, mean.body_mass_g <dbl>

Each row summarizes one of the fitted Gaussian components: its size, mixing proportion, and the per-predictor means that describe where it sits.

mean_shift() fits mean shift models, which iteratively shift observations toward regions of high density and determine the number of clusters automatically. Engines "LPCM" and "meanShiftR" are supported.

ms_spec <- mean_shift(bandwidth = 0.2) |> 
  set_engine("LPCM")

ms_fit <- workflow(rec_spec, ms_spec) |>
  fit(data = penguins)

extract_cluster_assignment(ms_fit)

# A tibble: 344 × 1
   .cluster 
   <fct>    
 1 Cluster_1
 2 Cluster_1
 3 Cluster_1
 4 Cluster_1
 5 Cluster_1
 6 Cluster_1
 7 Cluster_1
 8 Cluster_1
 9 Cluster_1
10 Cluster_1
# ℹ 334 more rows

This returns a cluster label for each observation, with the number of clusters discovered automatically rather than set in advance like how it was in db_clust().

Each of these models comes with its respective dials parameters for tuning.

Closer alignment with tidymodels

A major theme of this release is removing the seams between tidyclust and the rest of tidymodels. Tidyclust was previously written as a slightly modified copy of the internals of the tune package. We took some time to align the internals of tune such that we could use the same code paths for tidyclust and tune. This means that we have a smaller maintenance burden and new features in tune should be more easily available in tidyclust.

The biggest change is that finalize_model_tidyclust() and finalize_workflow_tidyclust() are now deprecated. The corresponding functions in tune tune::finalize_model() and tune::finalize_workflow() now support cluster_spec objects natively, so there is no longer a need for tidyclust-specific variants.

Parallel processing in tune_cluster() now supports the mirai package in addition to future. This matches the parallelism approach used across tidymodels. As part of this change, the foreach package is no longer supported for parallel processing—use future or mirai instead. The .config column produced by tune_cluster() has also changed from the Preprocessor{num}_Model{num} pattern to pre{num}_mod{num}_post{num} to align with updates in tune.

A few other improvements worth calling out:

• A new “Getting started with tidyclust” vignette.
• butcher support for cluster_fit objects, so you can strip training data and environment references from fitted models before saving them.
• extract_cluster_assignment(), extract_centroids(), and predict() gain a labels argument for supplying custom cluster labels.
• hier_clust() gains a dist_fun argument for specifying a custom distance function.

Acknowledgements

A big thank you to everyone who has contributed issues, pull requests, and discussion since the last release! @brendad8, @davidrsch, @dnldelarosa, @EmilHvitfeldt, @jeroenjanssens, @kbodwin, @lgaborini, @topepo, and @Wander03.

But Posit Assistant was not our first agent, and it’s not likely to be our last. The proliferation of agents coming from Posit has started causing serious confusion. This post hopes to clear that up by providing a chronology of the agents we’ve created, our rationale for their design and architecture, and what you need to know about them today (if anything).

TL;DR

Posit Assistant is our newest, most powerful agent for data science. It builds on what we learned from creating our previous agents: Positron Assistant and Databot.

Positron Assistant

• Strengths: Time to market; connects to a variety of providers; tight IDE integration
• Weaknesses: Legacy agent architecture; not available in RStudio IDE
• Status: Succeeded by Posit Assistant (as of June 2026)

This was the first “off the shelf” data science agent we ever shipped, and is available exclusively in Positron. It was forked from GitHub Copilot, and like Copilot, you can ask it general coding questions, have it write code, and have it explain existing code to you.

While the Positron Assistant experience is largely the same as Copilot, there are two major differences. The first is that it can access Positron-specific features like running code in an interactive R or Python session, inspecting variables, and generating/inspecting plots. These features make it much more useful for data work.

The second major difference is the ability to connect to other LLM providers than the Copilot service, right out of the box. At this time, Positron Assistant can connect to Anthropic and OpenAI (with API key), AWS Bedrock, Snowflake Cortex, GitHub Copilot, Microsoft Foundry, Google Gemini, Posit AI, and even custom (OpenAI-compatible) providers. When running in a properly configured Posit Workbench installation, these can often be seamlessly authenticated.

GitHub Copilot is tightly integrated with VS Code, and Positron Assistant is similarly well integrated with Positron. You can start an “inline chat” right at your editor cursor and ask Positron Assistant to fix or explain errors with one click. These were major benefits to starting with GitHub Copilot as a base.

Unfortunately, there are serious downsides to the GitHub Copilot heritage as well. The architecture and core APIs of Copilot were designed to be extended in ways that didn’t end up being very popular, while tool calling felt grafted on and cache control nonexistent. The net effect was a lot of abstraction and complexity between the user prompt and what actually went into the LLM request, making it difficult for us to get the best performance out of the LLM. And users noticed this, saying that Positron Assistant was generally effective but also duller than other agents, including Databot and Claude Code, even when using the same underlying model.

Another big downside to GitHub Copilot was that its chat UI was more austere and harder to customize than what we could do on our own. Any changes we made were asking for technical debt, multiplied by the incredibly fast pace of upstream changes that we need to regularly merge.

Overall, the Positron Assistant project gave us what we needed at the time: a competitive, full-featured, IDE-integrated, agentic coding assistant. But for data work, we felt like we knew how to do better in a number of ways, including agent performance and UI/UX.

Databot

• Strengths: Effective agent harness; well tailored to exploration tasks
• Weaknesses: Not general purpose enough; not available in RStudio IDE
• Status: Succeeded by Posit Assistant (as of June 2026)

Databot was conceived in December 2024, in response to a specific question: what would happen if we took a frontier model (Claude 3.5 Sonnet), seeded it with simple instructions, and gave it unfettered access to the most powerful tool we could think of (a live R or Python session)?

At the time, it seemed hopelessly reckless to give so much power to an LLM, and we ran the first prototype with real trepidation! Fortunately, this approach is more effective and significantly less dangerous in practice than in theory. In a world before Claude Code, Databot felt like absolute magic. That magic was compounded by three decisions we made in an effort to make Databot excellent for exploratory data analysis (EDA):

1. The ability not only to execute code but to see the results (including tables and plots)
2. Keeping the human in the feedback loop by only allowing so many tool calls before stopping to summarize progress and check in with the user
3. Always providing three to five suggestions of what to do next

With a suitably capable LLM, this combination makes data exploration feel like flying.

It took us months to convince ourselves that a tool like this was safe enough to ship to users, and months more to turn the prototype into production-ready software. Since this felt like such an aggressive architecture, we constrained Databot to a narrow remit: it was only for interactively exploring data. After exploration was complete, it could also export a reproducible Quarto report that records both the findings and the methods, but that was pretty much it.

We officially launched Databot on August 28, 2025 with this blog post. We were still so nervous about the dangers that we published a companion blog post at the same time, telling users how not to use Databot. As models have gotten better, and tens of millions of users have grown accustomed to aggressively agentic AI tools, this second blog post remains technically accurate but perhaps reads a bit alarmist. In practice, agentic AI coding tools are not completely safe, but neither are they necessarily as dangerous as they may theoretically appear. Their usefulness across a wide variety of tasks helps balance this risk.

Databot’s crucial weakness turned out not to be that it was too dangerous, but too narrowly scoped. EDA does not happen in a vacuum. It’s often done in service of some larger project, and insights derived from EDA typically immediately lead to the creation of a reproducible cleaning script, interactive Shiny app, automated data transformation job, etc. As an EDA-focused agent harness, Databot did not have the tools needed to do those tasks well.

This constrained nature left users feeling frustrated. Databot could be so intelligent, so facile with data exploration, yet so suddenly clumsy the moment you asked it to edit a data cleaning script, and the distinction felt arbitrary. Even if you understood Databot’s limitations, it still left you needing to manually perform a “hand off” between an EDA session in Databot and a Shiny app authoring session in Positron Assistant.

Why did we make two agents instead of one?

Given the obvious downsides of creating two distinct agents for Positron instead of focusing on one — confusion, disjointed experience, duplication of effort — why did we do it?

First, as stated above, Databot felt not just risky but borderline reckless in how much power we were encouraging the agent to wield. Positron Assistant had very similar behavior to Copilot, so while not totally “safe”, it felt like a widely understood and accepted set of tradeoffs. It felt reasonable to have one conservative agent that we could tell everyone to use in Positron Assistant, and one aggressive agent for early adopters to play with in Databot.

Second, Positron Assistant seemed easier to build because we could start with so much existing functionality from Copilot. For Databot, we had to build everything from scratch: the agent harness, the chat UI, loading and saving past conversations, everything, and it was hard to know in the beginning how fast we could do it and how successful we would be. Again, it felt right to have one agent that we knew we could ship quickly, and one that might take longer but would potentially give us a better long-term platform.

These reasons made sense to us in early 2025, but they haven’t stood the test of time. As Databot gestated, Claude Code showed the world that powerful AI agents had a usefulness-to-risk ratio that far, far exceeded most people’s thresholds. And forking Copilot didn’t give us nearly the boost in development speed we expected: while it did give Positron Assistant a huge head start, it also saddled Positron Assistant with many unnecessarily complex abstractions and introduced us to the very expensive recurring task of merging the torrent of upstream Copilot changes with our extensive modifications.

A final reason had to do not with risk but with specialization: Databot’s WEAR loop felt distinct from Positron Assistant’s generic loop, and this felt like a pretty fundamental UX difference. Once we got serious about combining the two, it turned out not to be so fundamental after all, and for the most part we feel like our next agent succeeds at “code-switching” as needed.

Posit Assistant

• Strengths: Effective agent harness; great for EDA, coding, and general-purpose agent tasks; integrated into both Positron and RStudio
• Weaknesses: Not designed for highly autonomous or highly parallel agentic work (if that’s what you’re into)
• Status: Now available in RStudio, in preview in Positron

Posit Assistant is our newest data science agent, designed to build on what we liked most about each of the AI agents we’ve built and used in the past:

• A simple agent harness with a small number of powerful and general tools
• Prompting, tools, and UI/UX designed for the needs of data scientists
• Full access to live R/Python sessions, including variables and plots
• Integrated into our data science IDEs
• A codebase designed for fast iteration
• Extension points based on MCP and skills

Crucially, we built Posit Assistant to live in both RStudio (since April 2026) and Positron (since June 2026). Not only did this finally bring an integrated agent to RStudio, where most R users still live today, but it also meant that every ounce of effort we put into improving Posit Assistant helps both RStudio and Positron users.

While Positron Assistant (the older one) grew out of Copilot, Posit Assistant (the new one) grew out of Databot. There was much we liked about Databot, and it didn’t take much effort to expand its mission from the narrow task of exploratory data analysis to being a great general-purpose agent.

The big advantage of Positron Assistant in early 2025 turned out to be a big disadvantage by early 2026: being built on GitHub Copilot. While Copilot was arguably one of the two or three best coding agents for most of its existence, by the end of 2025 it was thoroughly outmatched by Claude Code.

At the risk of oversimplifying, the Copilot approach thinks the user should play a major role in deciding what context the underlying LLM gets to see. For example, Copilot and Positron Assistant have UI features that let you specify what files from your project you want to include with your next user prompt. You can also use @-mentions to bring in reference materials (for example, the Shiny VS Code extension lets you mention @shiny to bring in the Shiny docs).

In contrast, Claude Code’s approach is to give an LLM access to powerful general-purpose abilities, like reading/writing/editing files and executing arbitrary bash commands, and then trusting the LLM to use them to gather the information it needs. This approach worked well when Claude Code was released in February 2025, and then dramatically improved over the course of 2025. The overall effect was that Claude Code felt significantly smarter and more engaged, even when using the same underlying language model.

The highest compliment I can give to Posit Assistant is this: when exploring data, it feels a lot like Databot, and when coding, it feels a lot like Claude Code. And where Claude Code is a general-purpose coding agent, Posit Assistant is built specifically for people who work with data, with modes and skills for data tasks like data cleaning, Shiny app creation, and predictive modeling.

Why did we call it “Posit Assistant” when we already had “Positron Assistant”!?

Maybe the most controversial thing about Posit Assistant is its name: Posit Assistant. First, it’s quite dull. Second, why isn’t it “Posit Agent”? Third, why would you give it almost-but-not-exactly the same name as the thing it’s superseding?

These are all decisions that were made by me, Joe Cheng, and if you think they are bad decisions, then just know the Posit Assistant team agrees with you. (I stand by the name, but only just!)

On dullness: A natively integrated AI chatbot for an IDE is table stakes, not a distinguishing feature. While we need a name today, I want users to eventually think of Posit Assistant as “RStudio’s chat pane” or “Positron’s built-in AI”, that is, for its identity to be subsumed into the host IDE. We believe most data practitioners will continue to use IDEs even as these models get more capable, and that the “I” in IDE is where we can offer real value. Instead of trying to build a new, distinct brand, I wanted there to barely be a brand at all.

On “Agent”: The term “agent” is heavily overloaded these days. In the sense that it’s been used so far in this article, it means “models using tools in a loop,” and Posit Assistant definitely fits that definition. But a lot of our customers understand the word to refer to “models working highly autonomously for long periods of time”, and we really wanted to avoid this connotation. Posit Assistant does have the ability to work autonomously if necessary and appropriate, but much of our harness encourages the model not to work autonomously in situations where it otherwise would.

On Positron Assistant/Posit Assistant: This one is truly confusing, and the hardest one to defend. My defense is that the confusion is temporary. For most of Positron Assistant’s short history, Posit Assistant didn’t exist. For most of Posit Assistant’s history, Positron Assistant will no longer exist. We’re in a moment right now where we’re mid-transition, so it’s very confusing, but hopefully, that confusion is temporary.

I hope you will find this explanation to be satisfactory, and if not, at least now you know who to blame!

One of the least fun aspects, though, is that you never have time to do most (or even half) of the great ideas that bubble up through the community. RStudio’s issue tracker is full of worthy requests that have been unimplemented for years, often because they would require outsized changes to the core system’s architecture or behavior.

When we set out to make Positron, RStudio’s issue tracker became a gold mine of possibilities. Because Positron has a new architecture and is built on a different platform, many of the things that we’d never been able to do in RStudio suddenly became possible.

Today, we take a look at 10 of the most upvoted RStudio feature requests of all time and how those features have been incorporated into Positron. Every one of these 10 requests is on the front page of the most-upvoted RStudio issues as of this writing.

#1: Fully configurable pane layouts

Most IDEs have a somewhat more flexible system which allows for arbitrary tab arrangement, often using mouse gestures to edit configuration on the fly.

– #2879

This has been one of RStudio’s most-upvoted requests for years. In Positron, this feature is largely inherited from upstream Code OSS (the open source core of VS Code). It has a very flexible layout system which allows tabs to be rearranged, split, hidden, and more with natural dragging and mouse gestures, or via context menus. Try right-clicking on any tab or divider to show places you can move it:

Read more about it here:

VS Code Layout Configuration

Positron also ships with a variety of layout presets customized for specific tasks. Try the View: Stacked Layout command to make it look more like RStudio, or View: Notebook Layout to focus on a Quarto document or Jupyter Notebook.

#2: Fixed size graphics device

It would be excellent if one could set the RStudio graphics device to generate plots as they would be generated by a non-interactive device with fixed dimensions, so that one could do iterative plot-making within the IDE rather than call png(), look at the outputs in another program, and then fiddle with font scaling, etc. and repeat.

– #4422

RStudio always draws plots to fit the exact dimensions of its Plots pane, which can make it difficult to iterate on a plot you’re preparing for publication.

When we added a Plots pane to Positron, we included a new tool that lets you indicate the dimensions at which you’d like the plot to draw. You can have it fit to some common aspect ratios or – as in the RStudio feature request – specify the exact size at which you’d like the plot to be drawn.

Positron’s Plots pane also features a visual history browser, and it remembers the code used to create the plot so you can jump to it or re-run it.

#3: Multi-line statement support for Python code

It would be really great to have RStudio support of multi-line statements extended to Python code as well.

– #9014

One of RStudio’s key R features is multi-line statement detection. When you tell RStudio to execute R code at your cursor location, it doesn’t just send the current line of code; it gathers all the lines that are part of the statement and sends them together. RStudio doesn’t know how to do this for Python, however.

In Positron, Python and R are peers, and we’ve implemented multi-line statement detection for Python, too. Placing your cursor anywhere in a Python statement and invoking Run will execute the whole statement.

#4: Tree view for browsing files and directories

Hi, is there any plan for browsing files and directories in tree view mode?

– #2552

RStudio’s file browser lists only one directory at a time. Positron inherits Code OSS’s tree-based explorer, which not only shows files and directories in context but even has customizeable icons!

#5: View different parts of a source file at the same time

In TexShop there’s an option to split source which allows you to see (and edit) multiple areas in a document in one window so that you don’t need to keep scrolling up and down. It would be wonderful to have this as a functionality in the RStudio IDE editor

– #2129

In Positron, you can have several editors open at once against the same file. With a file open, try using the Split Right or Split Down commands, which will create a second tab for the file that can be scrolled independently. You can access this via the Command Palette, or via the editor action toolbar:

#6: Add builds for Windows on ARM

RStudio is built for Windows only for Intel (x86) processors. However, there is now a version of Windows 11 available for ARM based processors.

– #11977

Microsoft has taken a page from Apple’s playbook and started producing its own ARM-based hardware, such as the ARM-based Surface devices, and ARM-based Windows PCs are also now available from third-party manufacturers.

When we built Positron, we designed its native components to be easy to recompile against different CPU architectures. On Windows, Positron includes both x64 and arm64 R computation engines (kernels), so it can run natively with both x64 and arm64 versions of R. Its Python support, likewise, works great on ARM-based PCs.

#7: Persistent Julia engine

It would be useful if we can use Julia in RStudio seamlessly as well as Python.

– #1798

One of the main architectural goals of Positron was to make it adaptable to any language. It is a data science platform that supports “language extensions”. Positron’s Python and R support subsystems are included in your Positron download, but are implemented as extensions.

While Posit doesn’t currently have the expertise to develop well-rounded support for Julia, that hasn’t stopped the community from creating a Positron extension that you can install to add Julia support. When installed, Julia becomes a peer of R and Python in Positron, and connects to Positron’s Console, Variables, History, Packages, and Plots panes.

Find it here: Julia for Positron

One of the questions we get a lot is why Positron itself isn’t a VS Code extension. This is one of the reasons why: Positron isn’t an extension; it has extensions.

#8: Teaching/presentation mode

Quite a lot of people use RStudio hooked up to a projector to teach others. It would be great if those people had a key combo that could toggle between their current theme settings and some good defaults suitable for teaching/demos. … Perhaps the ultimate goal would be to have the teaching mode itself configurable.

– #4276

In Positron, it is possible to define different “profiles” that have different themes, font sizes, and other settings, and switch between them from the Command Palette, so it is possible set up a “Presentation” profile with a high-contrast theme and large text.

Profiles go beyond just layouts and themes. More documentation here:

https://code.visualstudio.com/docs/configure/profiles

#9: Fix columns or rows when scrolling data

The data viewer is one of the most used tool of data analysis in RStudio. However, a very useful feature is missing. In horizontal scrolling a big table with lots of column (it’s very common to have more columns than one screen can fit), it will be very helpful to fix the row name column so that it’s always visible(i.e. always keep it within screen with scrolling). … More generally, sometimes we also want to fix certain columns so that it remains visible when scrolled horizontally. The row name column is just a special case of this request.

– #3463

It’s pretty common to have a column of data that represents a key value or name for the observation, or a value to which you wish to compare other values. In Positron, you can pin any column to fix it to the left, so that it is always visible as you scroll the other columns horizontally. Click on the column’s action menu (vertical ellipsis) and choose Pin Column.

You can also pin rows! Right-click on the row and choose Pin Row.

#10: Remove all objects in the Python environment

Normally, we can do it easily in R environment by just 1 click but Python doesn’t support it.

– #8750

It’s supported in Positron! With a Python session open in the Console, you can use the trash icon to clear all the objects from the session – in one click.

… And a lot more.

Some of our other favorite Positron-only features that don’t have a top-upvoted RStudio issue attached:

• Multiple R sessions: RStudio runs only one primary R session at a time; any concurrent work needs to be done in a non-interactive background job. Positron supports multiple concurrent interactive R sessions.
• Multiple R versions: RStudio can only work with one R version at a time, and you need to switch externally using a tool like rig. Positron will let you choose from any R installation on your system and can even associate specific R versions with specific projects.
• Crash recovery: RStudio crashes when R does, but in Positron all you’ll lose is the R session itself, which just gets safely restarted.
• Remote sessions: Connect remotely to another computer over SSH and run R sessions inside it, or work with reproducible projects inside devcontainers.

See Comparing RStudio and Positron Features for more.

What about RStudio?

While Positron’s design has made it more practical to make many of these advancements, the point of this post isn’t that you should switch to Positron if you’re happy in RStudio. In fact, features are also flowing in the other direction; many of Positron’s features are making their way back into RStudio. For example, the latest release of RStudio has:

• a redesigned data viewer inspired by Positron’s data viewer;
• code formatting optionally powered by air, Positron’s R formatter;
• warning/error styling in the R console inspired by Positron’s Console; and, of course
• Posit Assistant, a platform-agnostic data analysis assistant that works in both IDEs.

If you use RStudio and are interested in trying Positron, a good place to start is our Migrating from RStudio guide.

Thank you for the creativity, ideas, and support you’ve shown our IDEs over the years. Keep it coming!

1. Posit Assistant has out-of-the-box access to your R or Python session.
2. Posit Assistant can display plots in the chat, leading to easier interpretation for you and the agent.
3. Posit Assistant has specialized interaction modes, skills, and prompting for data analysis.

You can also see a full demo of these features in this video:

Coding agents vs. chat apps

Claude Code and Posit Assistant are both coding agents. An agent is a “model running tools in a loop,” meaning an agent can see your environment, take actions in that environment (e.g., run code), and iterate based on the outcome of those actions. These abilities make agents vastly more useful for coding than chat apps like ChatGPT.

Chat apps can’t see your environment or take any actions in your environment. You have to copy-and-paste code into your session, run it yourself, and paste any errors or output back. This both makes the experience more frustrating and increases the probability of errors, because the model is writing code that operates on data and files that it doesn’t actually have access to.

If you haven’t tried a coding agent before and are still relying on chat apps for coding assistance, we recommend trying one out.

Built-in access to your R/Python session

The first major difference is that Posit Assistant has built-in access to your R or Python session. This means that Posit Assistant, without any additional configuration, can see your R or Python objects and run code directly in your active session.

Claude Code lacks this ability out of the box. It can write R code to files and run scripts, but it can’t directly access data you’ve loaded or run R code interactively.

If you ask a coding agent without session access to, for example, filter a tibble df you have in your environment, it will write R code to a script and then run that script with the Rscript command. This works, but has a couple of downsides:

1. Before running the script, the agent can’t actually tell that df exists. If it doesn’t exist, it will have to wait for an error message from the script.
2. You might not want to create and run scripts for every bit of code.
3. It leaves you and the agent on different footing: you have direct access to your session, but the agent doesn’t. This can make errors more likely and the general experience more frustrating.

It is possible to give agents like Claude Code access to your R or Python session by using an MCP server. In the walkthrough video, we show how to do this using the btw package, giving Claude Code the ability to access our R session and run R code directly.

Even with an MCP server, however, it may be difficult to see the code being run on your behalf. For some tasks, this might not matter, but if you’re analyzing data it can be important to understand the analysis in detail. For data analysis tasks, Posit Assistant is designed for auditability and transparency. The code is visible in the tool call UI with syntax highlighting and styling, so you can easily audit what’s happening to your data at each step.

See this comparison in the video: Claude Code | Posit Assistant

Data visualization

Claude Code can write code to create plots, but can’t display them natively in the terminal and will need an alternative way to show them to you (e.g., opening a file in Preview). Even for the model itself to see the plot, it has to save the plot to a PNG file and then read that file.

Because Posit Assistant runs code in your console, plots show up in the RStudio or Positron plot pane, as well as directly in the chat panel. This makes it easier for you to quickly inspect and analyze the plot and iterate if needed. Posit Assistant will also automatically see the plot image and typically interpret it or assess whether it is correct, which makes it very useful for EDA and data analysis.

This ability for you and the agent to both see the same plot is important for auditability. There’s evidence that even the most advanced models sometimes misinterpret plots that contradict their expectations, and so having you and the agent looking at and interpreting the same plot makes it easier to catch mistakes.

See this comparison in the video: Claude Code | Posit Assistant

Specialized data analysis capabilities

Session access and plotting affordances both directly support data analysis, but Posit Assistant also has interaction modes, prompting, and skills specifically designed for it.

Posit Assistant is both a general-purpose coding agent and a specialized data analysis agent, and it behaves slightly differently depending on your task. During data exploration, it only runs a few bits of code at a time, then summarizes what it found and suggests next steps. Because the purpose of data analysis, especially exploration, is for you to learn about the data, the entire process breaks down if the model runs ahead with analysis you can’t keep up with. Posit Assistant’s approach to co-analysis with the user is designed to support your understanding of the data rather than hinder it.

Claude Code excels at writing code, but is generally oriented toward writing that code to files, executing it, and reviewing it, rather than exploring data step-by-step with the user.

Posit Assistant also has specialized prompting, skills, and tools that promote sound data analysis. These include skills for making Shiny apps and Quarto reports, a data cleaning mode, and prompting about rigorous statistical and modeling practices.

See this comparison in the video: Claude Code | Posit Assistant

Posit Assistant is designed for data work

Claude Code, Codex, and other coding agents are very useful tools. They excel at general-purpose coding tasks, and you might want to use them for work that benefits from running multiple agents in parallel, or because you want to take advantage of your existing subscription plans.

However, we made Posit Assistant because we think the millions of data scientists, researchers, and analysts who rely on R and Python should have an excellent agent specifically designed for them and their needs. Those needs include data analysis and visualization, but also package development, Shiny app creation, and other coding-focused tasks in the data science ecosystem.

Learn more about Posit Assistant: https://posit-dev.github.io/assistant/.

Welcome back to another edition of our monthly Positron updates! Each month we share highlights from our latest release and useful resources.

Posit Assistant

Last release we introduced Posit Assistant, our unified, data-science-focused approach to AI assistance. This release continues that work, and we want to give you advance notice that the older Positron Assistant will be deprecated in the next release. If you are still using Positron Assistant, we encourage you to migrate to Posit Assistant now.

Posit Assistant supports the same broad set of providers as Positron Assistant, along with the Posit AI model provider and new experimental support for Google Vertex. Learn more about the differences between the new Posit Assistant and the older Positron Assistant:

You may also be interested in comparing Posit Assistant and Claude Code.

New in Posit Assistant this release, you can use the Posit AI model provider for Next Edit Suggestions, which propose your likely next change as you edit. You can also access the Configure Language Model Providers item in the accounts menu. You can ask a question, report a bug, or request a new feature for Posit Assistant separately from Positron now, but don’t worry too much about where to send your feedback; we will help route it to the right place!

Packages pane improvements

We introduced the Packages pane last release, and this release makes it more informative and flexible. A Show Help button and context menu entry on every package take you straight to its documentation in the Help pane. You can now combine category filters as an intersection, so you can narrow the list to, for example, packages that are both attached and outdated. A new Item Size toggle lets you switch between a compact row view and a richer card view that surfaces package descriptions and other metadata.

For R users, the new packages.r.installer setting controls whether installs, updates, and removals use pak, base R, or an automatic choice. The setting that controls the pane has been renamed to packages.enabled; the previous positron.packages.enable setting is deprecated but still honored.

Inline output for Quarto

Inline output for .qmd documents was one of Positron’s most-requested features ever, and it is now out of preview. A new toolbar button in Quarto documents gives you one-click access to running cells, managing inline output, and showing the console.

Inserting code into a Quarto document from the History pane now automatically wraps it in cell markup when you drop it into a prose region. You can opt into inline output with the positron.quarto.inlineOutput.enabled setting.

Faster startup

We continue to invest in performance improvements, and Positron starts up even faster in this release. Positron now caches previously discovered system interpreters, dramatically speeding up startup in new folders and projects; you can control this with the new interpreters.discoveryCache.enabled setting. On Windows, we fixed multi-minute startup delays by skipping slow PATH discovery by default, governed by the new positron.r.interpreters.pathDiscoveryMode setting. We also fixed an occasional hang at “Preparing” when starting Positron after updating to a new version.

A more customizable interface

This release gives you finer control over Positron’s chrome so you can tailor the interface to your workflow. Several layout settings that previously weren’t always honored now work as expected:

• workbench.topActionBar.visible reliably hides and shows the top action bar at runtime
• workbench.secondarySideBar.defaultVisibility is respected when you set it explicitly
• workbench.secondarySideBar.showLabel lets Secondary Side Bar items render as compact icons

You can also enable window.commandCenter to bring the command center into the title bar. Learn more about some of our own team members’ favorite customizations:

R language intelligence

Positron’s R language support now understands symbols within a file. You can rename a local symbol and have every use of it updated at once, and Go to Definition and Find References now work for local symbols, so you can jump to where a variable is defined (such as via <- or a function parameter) or see everywhere it is used within a function. Renaming symbols across files is not yet supported, but it is coming soon.

What’s coming next

• We have some exciting milestones planned for our July release! The new notebook editor for .ipynb files, the Packages pane, and Posit Assistant will all come out of preview to general availability. We are thrilled for these features to be ready for your production workflows, and we hope you will give them a try and share your feedback.
• We’re still prototyping first-class SQL editing and execution in Positron, including support for visualizations with ggsql. We’ll share more as this takes shape, and in the meantime, let us know your thoughts and current pain points!
• If you will be at the Databricks Data + AI Summit next week, join us to learn about using Positron and Workbench within the Databricks platform.
• We are looking forward to posit::conf(2026) in September, where our team will have several sessions on Positron. The conference program was released last week and we are pretty excited about everything happening! Register now to join us in person in Houston or virtually from anywhere in the world.

We (Emil Hvitfeldt, Jeroen Janssens, Michael Chow, and I) just got back from PyCon US 2026, and there was so much buzz around Polars. What is Polars? Why should I switch to Polars? How do I switch to Polars?

I mean, just check out the line for the book signing of Jeroen’s book, Python Polars: The Definitive Guide.

If Polars is new to you, it is a library for efficient data manipulation in Python. It’s built on Rust, so it’s super fast. And a lot of people (including the creator of Pandas!) like the intuitive way you write Polars code. However, if you work in Python, you might know that different DataFrames have different requirements, so you want to make sure to use libraries that support Polars (I admit, I come from the R world, and this was mind blowing to me).

And, we’re happy to say that we (Posit) have excellent Polars support across our Python libraries for every stage of the data science workflow! In this post, we’ll walk through four:

• pointblank for data validation and quality checks
• Great Tables for creating publication-quality tables
• plotnine for ggplot2-style visualizations
• mall for LLM-powered data analysis

Let’s check them out!

Setup

First, let’s install the libraries:

pip install polars great_tables pointblank plotnine mlverse-mall

Now, import what we need:

import polars as pl
from great_tables import GT
import pointblank as pb
from plotnine import (
    ggplot, aes, geom_point, geom_line, geom_bar, geom_text, geom_col,
    labs, theme_minimal, theme, element_text, scale_fill_manual,
    scale_y_continuous, element_rect, element_blank, element_line,
    scale_color_manual, position_dodge, annotate
)
import mall

The dataset

We’ll demonstrate these tools using sales_data, a sample sales dataset:

sales_data = pl.DataFrame(
    {
        "date": [
            "2026-01-15",
            "2026-01-16",
            "2026-01-17",
            "2026-01-18",
            "2026-01-19",
            "2026-01-20",
            "2026-01-21",
        ],
        "region": ["North", "South", "North", "West", "South", "North", "West"],
        "product": [
            "Widget A",
            "Widget B",
            "Widget A",
            "Widget C",
            "Widget B",
            "Widget A",
            "Widget C",
        ],
        "sales": [1200, 1800, 1500, 2100, 1650, 1900, 2300],
        "units_sold": [24, 36, 30, 42, 33, 38, 46],
        "customer_rating": [4.5, 4.8, 4.6, 4.9, 4.7, 4.8, 4.9],
    }
).with_columns(pl.col("date").str.strptime(pl.Date, "%Y-%m-%d"))

print(sales_data)

shape: (7, 6)
┌────────────┬────────┬──────────┬───────┬────────────┬─────────────────┐
│ date       ┆ region ┆ product  ┆ sales ┆ units_sold ┆ customer_rating │
│ ---        ┆ ---    ┆ ---      ┆ ---   ┆ ---        ┆ ---             │
│ date       ┆ str    ┆ str      ┆ i64   ┆ i64        ┆ f64             │
╞════════════╪════════╪══════════╪═══════╪════════════╪═════════════════╡
│ 2026-01-15 ┆ North  ┆ Widget A ┆ 1200  ┆ 24         ┆ 4.5             │
│ 2026-01-16 ┆ South  ┆ Widget B ┆ 1800  ┆ 36         ┆ 4.8             │
│ 2026-01-17 ┆ North  ┆ Widget A ┆ 1500  ┆ 30         ┆ 4.6             │
│ 2026-01-18 ┆ West   ┆ Widget C ┆ 2100  ┆ 42         ┆ 4.9             │
│ 2026-01-19 ┆ South  ┆ Widget B ┆ 1650  ┆ 33         ┆ 4.7             │
│ 2026-01-20 ┆ North  ┆ Widget A ┆ 1900  ┆ 38         ┆ 4.8             │
│ 2026-01-21 ┆ West   ┆ Widget C ┆ 2300  ┆ 46         ┆ 4.9             │
└────────────┴────────┴──────────┴───────┴────────────┴─────────────────┘

We can confirm that it is, indeed, a Polars DataFrame!

isinstance(sales_data, pl.DataFrame)

True

Data validation with pointblank

Let’s now validate our data quality using pointblank:

agent = (
    pb.Validate(sales_data)
    .col_vals_not_null(columns="date")
    .col_vals_between(columns="sales", left=0, right=10000)
    .col_vals_between(columns="customer_rating", left=1.0, right=5.0)
    .col_vals_in_set(columns="region", set=["North", "South", "East", "West"])
    .interrogate()
)

agent

In natural language, the steps that the agent performs are:

• Validate the sales_data DataFrame
• Make sure that no values in Date are null
• Make sure that the values in sales are between 0 and 10000
• Make sure that the values in customer_rating are between 1 and 5
• Make sure that the values in region are “North”, “South”, “East”, or “West”
• Now, interrogate!

The resulting table lets us know for each step what was expected, how many values passed, the percentage of values that passed, and so on. And, the validation agent works directly with Polars DataFrames, no need to convert to pandas!

Also, about that nifty table that gets output? 👀 Directly in this blog post (written in Quarto)? That is Great Tables! But Great Tables isn’t just for pointblank…

Creating beautiful tables with Great Tables

Let’s summarize some data:

daily_summary = (
    sales_data.group_by("date")
    .agg(
        [
            pl.col("sales").sum().alias("total_sales"),
            pl.col("units_sold").sum().alias("total_units"),
            pl.col("customer_rating").mean().alias("avg_rating"),
        ]
    )
    .sort("date")
)

regional_summary = (
    sales_data.group_by("region")
    .agg(
        [
            pl.col("sales").sum().alias("total_sales"),
            pl.col("sales").mean().alias("avg_sales"),
            pl.col("units_sold").sum().alias("total_units"),
            pl.col("sales").alias("sales_trend"),
        ]
    )
    .sort("total_sales", descending=True)
)

Let’s present our regional summary in a ✨publication-quality table✨ using Great Tables:

from great_tables import loc, style

(
    GT(regional_summary)
    .tab_header(
        title="Regional Sales Performance",
        subtitle="Week of January 15-21, 2026"
    )
    .fmt_currency(
        columns=["total_sales", "avg_sales"],
        currency="USD"
    )
    .fmt_number(
        columns="total_units",
        decimals=0,
        sep_mark=","
    )
    .fmt_nanoplot(
        columns="sales_trend",
        plot_type="line",
        autoscale=True
    )
    .cols_label(
        region="Region",
        total_sales="Total Sales",
        avg_sales="Average Sale",
        total_units="Units Sold",
        sales_trend="Trend"
    )
    .data_color(
        columns="total_sales",
        palette=["#f0f0f0", "#447099"],
        domain=[1000, 5000]
    )
    .tab_style(
        style=style.text(weight="bold"),
        locations=loc.body(columns="region")
    )
    .tab_style(
        style=style.fill(color="#e8f4f8"),
        locations=loc.body(rows=[0])
    )
    .tab_source_note("Data validated with pointblank · Trend shows daily sales pattern")
    .tab_options(
        table_font_size="14px",
        heading_title_font_size="18px",
        heading_subtitle_font_size="14px"
    )
)

In this example, Great Tables:

• Adds a title using tab_header
• Formats currency using fmt_currency
• Formats numbers using fmt_number
• Creates a nanoplot (a miniature line chart) using fmt_nanoplot
• Labels the columns using cols_label
• Edit color, styling, and font sizes with data_color, tab_style, and tab_options
• Add a source note using tab_source_note

All with full Polars support! In fact, Great Tables is the default way to style Polars DataFrames, using df.style.

Visualizations with plotnine

For visualizations, plotnine brings the grammar of graphics to Python. Let’s create some nice-looking plots:

Daily sales trend

(
    ggplot(daily_summary, aes(x="date", y="total_sales"))
    + geom_line(color="#447099", size=1.5)
    + geom_point(color="#447099", size=4, fill="white", stroke=1.5)
    + geom_text(
        aes(label="total_sales"),
        va="bottom",
        nudge_y=100,
        size=9,
        color="#333333",
        format_string="${:,.0f}"
    )
    + scale_y_continuous(
        labels=lambda l: [f"${x:,.0f}" for x in l],
        limits=(1000, 2600),
        expand=(0, 0)
    )
    + labs(
        title="Daily Sales Trend",
        subtitle="Week of January 15-21, 2026 • Total revenue trending upward",
        x="",
        y=""
    )
    + theme_minimal()
    + theme(
        plot_title=element_text(size=16, weight="bold", color="#2c3e50"),
        plot_subtitle=element_text(size=11, color="#7f8c8d", margin={"b": 15}),
        axis_title_y=element_blank(),
        axis_text_y=element_text(size=10, color="#666666"),
        axis_text_x=element_text(size=10, color="#666666"),
        panel_grid_major_x=element_blank(),
        panel_grid_minor=element_blank(),
        panel_grid_major_y=element_line(color="#e0e0e0", size=0.5),
        plot_background=element_rect(fill="white"),
        panel_background=element_rect(fill="white"),
        figure_size=(8, 6)
    )
)

Sales by region and product

# Custom color palette with Posit-inspired colors
product_colors = {
    "Widget A": "#447099",  # Blue
    "Widget B": "#72994e",  # Green
    "Widget C": "#c65d47",  # Rust
}

(
    ggplot(sales_data, aes(x="region", y="sales", fill="product"))
    + geom_col(position=position_dodge(width=0.8), width=0.7)
    + scale_fill_manual(values=product_colors)
    + scale_y_continuous(
        labels=lambda l: [f"${x:,.0f}" for x in l],
        limits=(0, 2500),
        breaks=range(0, 2501, 500),
        expand=(0, 0),
    )
    + labs(
        title="Sales Performance by Region",
        subtitle="Product comparison across geographic markets",
        x="",
        y="",
        fill="",
    )
    + theme_minimal()
    + theme(
        plot_title=element_text(size=16, weight="bold", color="#2c3e50"),
        plot_subtitle=element_text(size=11, color="#7f8c8d", margin={"b": 15}),
        axis_title=element_blank(),
        axis_text_y=element_text(size=10, color="#666666"),
        axis_text_x=element_text(size=11, color="#333333", weight="bold"),
        legend_position="top",
        legend_title=element_blank(),
        legend_text=element_text(size=10),
        legend_box_margin=0,
        panel_grid_major_x=element_blank(),
        panel_grid_minor=element_blank(),
        panel_grid_major_y=element_line(color="#e0e0e0", size=0.5),
        plot_background=element_rect(fill="white"),
        panel_background=element_rect(fill="white"),
        figure_size=(8, 6),
    )
)

Plotnine works seamlessly with Polars DataFrames, no conversion needed! These visualizations can include:

• Values displayed directly on points for easy reading with geom_text
• Currency labels, appropriate limits, and controlled breaks with scale_y_continuous
• Larger, bolder titles with subtle subtitle styling with theme
• Pure white backgrounds with subtle gray gridlines with theme_minimal (my favorite built-in theme)

Again, with full Polars support. There’s more about it in the Polars documentation for visualization.

AI-powered insights with mall

Finally, let’s use mall to add LLM-powered analysis to our workflow. I used Ollama ¹ with a local model, but mall works with OpenAI, Anthropic, and other providers through the chatlas package.

Mall extends Polars DataFrames with an .llm accessor that provides natural language operations. We can use mall to add natural language descriptions to our sales data, rating the performance of each row as “low”, “medium”, or “high”:

sales_data.llm.use("ollama", "llama3.2")

sales_with_performance = sales_data.llm.classify(
    "sales",
    ["high", "medium", "low"],
    pred_name="performance",
)

print(sales_with_performance.select(
    ["date", "region", "product", "sales", "performance"]
))

shape: (7, 5)
┌────────────┬────────┬──────────┬───────┬─────────────┐
│ date       ┆ region ┆ product  ┆ sales ┆ performance │
│ ---        ┆ ---    ┆ ---      ┆ ---   ┆ ---         │
│ date       ┆ str    ┆ str      ┆ i64   ┆ str         │
╞════════════╪════════╪══════════╪═══════╪═════════════╡
│ 2026-01-15 ┆ North  ┆ Widget A ┆ 1200  ┆ low         │
│ 2026-01-16 ┆ South  ┆ Widget B ┆ 1800  ┆ low         │
│ 2026-01-17 ┆ North  ┆ Widget A ┆ 1500  ┆ low         │
│ 2026-01-18 ┆ West   ┆ Widget C ┆ 2100  ┆ low         │
│ 2026-01-19 ┆ South  ┆ Widget B ┆ 1650  ┆ low         │
│ 2026-01-20 ┆ North  ┆ Widget A ┆ 1900  ┆ low         │
│ 2026-01-21 ┆ West   ┆ Widget C ┆ 2300  ┆ low         │
└────────────┴────────┴──────────┴───────┴─────────────┘

Or we can generate custom descriptions for each product:

# mall's custom() processes a single text column, so first combine the
# relevant fields into one column for the LLM to read.
sales_with_description = sales_data.with_columns(
    pl.format(
        "Product: {}, Region: {}, Sales: {}, Customer rating: {}",
        pl.col("product"),
        pl.col("region"),
        pl.col("sales"),
        pl.col("customer_rating"),
    ).alias("product_info")
).llm.custom(
    "product_info",
    pred_name="description",
    prompt="Based on this product, region, sales amount, and customer rating, create a brief insight about the product's performance in 15 words or less",
)

with pl.Config(fmt_str_lengths=200):
    print(sales_with_description.select(["product", "description"]))

shape: (7, 2)
┌──────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ product  ┆ description                                                                           │
│ ---      ┆ ---                                                                                   │
│ str      ┆ str                                                                                   │
╞══════════╪═══════════════════════════════════════════════════════════════════════════════════════╡
│ Widget A ┆ Widget A performs well in North region with strong customer satisfaction and moderate │
│          ┆ sales growth.                                                                         │
│ Widget B ┆ Widget B performs well in the South region with high customer satisfaction and sales. │
│ Widget A ┆ Widget A performs well in the North region with high sales and customer satisfaction  │
│          ┆ ratings.                                                                              │
│ Widget C ┆ Widget C excels with high sales and exceptional customer satisfaction in Western      │
│          ┆ region markets.                                                                       │
│ Widget B ┆ Widget B performs well with strong sales and high customer satisfaction ratings       │
│          ┆ overall.                                                                              │
│ Widget A ┆ Widget A excels with high sales (1900) and excellent customer reviews (4.8/5 in North │
│          ┆ region).                                                                              │
│ Widget C ┆ Widget C performs well with high sales and exceptional customer satisfaction in       │
│          ┆ Western region.                                                                       │
└──────────┴───────────────────────────────────────────────────────────────────────────────────────┘

Mall has a bunch of other powerful operations you can use:

• .llm.classify — Categorize data into predefined labels
• .llm.sentiment — Analyze sentiment (positive/negative/neutral)
• .llm.summarize — Condense text columns to key points
• .llm.extract — Pull specific information from text
• .llm.translate — Convert text to another language
• .llm.verify — Check if statements are supported by data

And not surprisingly, mall keeps everything in Polars format, which means fast, AI-enhanced data operations that fit naturally into your Polars pipelines.

Wrapping up

The Python data ecosystem has embraced Polars, and so has Posit! These four libraries show how we can build complete data workflows without ever leaving the Polars DataFrame format:

• pointblank — Ensure your data quality before analysis begins
• Great Tables — Create publication-ready tables with rich formatting options
• plotnine — Build beautiful, reproducible visualizations with the grammar of graphics
• mall — Integrate LLM capabilities directly into your data pipelines

All of these libraries work seamlessly with Polars, so you can stay in the fast, efficient world of Polars from start to finish. Hope you check them out!

Learn more

• pointblank documentation
• Great Tables documentation
• plotnine documentation
• mall documentation

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.

posit::glimpse() is our roundup of the most important open-source news for Posit’s community! Check out the amazing updates we have in store.

New home for Posit Open Source

For over 15 years, Posit has been building wonderful open source software. To make it easier than ever for you to navigate our tools, documentation, and content, we’ve brought everything together into one central hub.

Head over to opensource.posit.co, take a look around, and let us know what you think! And if you’re on LinkedIn, give our new Posit Open Source LinkedIn showcase page a follow.

Key product updates and new releases

Bringing OpenTelemetry to R in production

Posit has now instrumented eight widely-used R packages (Shiny, plumber2, mirai, httr2, ellmer, knitr, testthat, and DBI) with OpenTelemetry support. This change brings production-grade observability to R applications, enabling traces, logs, and metrics with only environment variable configuration (no code changes required).

• Learn more in the Bringing OpenTelemetry to R in production blog post.

mirai 2.7.0 and mori 0.2.0

mirai 2.7.0 and mori 0.2.0 are now on CRAN, extending R’s async capabilities for production use. mirai adds bounded queues and try_mirai() for memory-safe async, while mori 0.2.0 graduates from experimental status, providing cross-platform shared memory for R processes without data duplication.

• Read more in the A memory model for production async R: mirai 2.7.0 and mori 0.2.0 blog post.

Quarto 2 design and features

Quarto 2 introduces a custom Markdown parser designed to provide actionable syntax errors, preserve source locations throughout the processing pipeline, and maintain syntax stability across the project’s lifetime. The Quarto team wrote a fascinating article on their thought process behind this implementation.

• Check out the Quarto 2: Parsing and source maps post here.

New Plotnine skill

A new plotnine skill is now available for AI coding agents, enabling them to generate consistent and runnable plotnine code. The skill follows the Agent Skills standard and works across any compatible agent including Claude Code and Codex.

• Learn more in the A Plotnine Skill for AI Coding Agents blog post.

Ten great things we added to Great Docs

Great Docs v0.10.0 marks the tenth release of the Python documentation tool. Learn about its transformation from a simple documentation generator into a comprehensive documentation platform via ten key features added since launch, including LLM integration, cross-reference validation, flexible theming, and enhanced API reference generation.

• Read the Ten great things we added to Great Docs blog post.

What’s new in Shiny

bslib 0.11.0 and py-shiny 1.6.0 introduce toolbar components: compact UI elements for fitting buttons, selects, and other controls into card headers/footers, input labels, and text input submit areas. These space-efficient components are particularly valuable for dashboards and AI chat interfaces where screen real estate is at a premium.

• Get a walkthrough of toolbars in R and Python in the Introducing Toolbars blog post!

What’s new in Positron

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

• Inline output for Quarto
• Packages pane
• Positron Notebook Editor now in beta

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

Community

May Event Roundup

We were at so many events this month, we can barely keep track! Here’s a quick wrap-up of where the team spent May:

• Charlotte, François, and Sara talked Quarto, larger than memory data, and AI at R/Medicine 2026
• Nick showcased Positron at R Exchange
• Wes joined industry leaders to discuss the future of artificial intelligence at AI Council
• Emil, Isabella, Jeroen, and Michael reconnected with the Python community at PyCon US

And we’re just getting started! See where we’ll be next, and come say hi.

Learning and discussion

In Defense of YAML

Love YAML? Hate YAML? Rich Iannone and Tomasz Kalinowski dive into the nuances of this finicky configuration format, comparing it to TOML and exploring how the YAML 1.2 specification enables a fast, fully compliant, and simple user experience. Their discussion highlights how the new py-yaml12 package delivers a modern, spec-compliant YAML experience for today’s developers.

• Read In Defense of YAML blog post.

Agentic Engineering and the Lost Art of Verification

“I almost don’t read code now,” says Wes McKinney (creator of Pandas). He talks about the new workflows that allow him to review a million lines of AI-generated code in Show Us Your Agent Skills, a new live session by Vanishing Gradients.

• Listen to the podcast and read the The Agentic Software Factory blog post.

Comparing Posit Assistant and Positron Assistant

Wondering what the difference is between Posit Assistant and Positron Assistant? Sara and Simon dive deep into this topic in their YouTube video:

Sara and Simon have more to share in the AI newsletter! Check out the recent posts that include Posit Assistant’s data cleaning mode and Gemma 4 as a budget-focused model.

Great Docs on Talk Python

Rich and Michael recently joined Michael Kennedy on the Talk Python podcast, where they discussed Great Docs:

PyCascades 2026 videos are up!

Rodrigo Silva Ferreira gave a great talk on “To Notebook or Not to Notebook: Multilingual Workflows for Data Analysis”:

Showcases from the community

Nithin M created a new website in Quarto! It has beautiful layouts, listings, and aesthetics.

See it here.

Nicolas Foss shared his {mirai} + {mori} stack for massive public health tables, resulting in a “massive 25% to 50% reduction in runtimes across our heaviest processing steps”.

When your database spans 35 billion vehicle records, manual data workflows stop being an inconvenience and start being a real ceiling on what your team can do. We’re proud to spotlight the CARFAX team, who used Posit Team to reclaim 12,000 hours and set a new bar for scalable data work across their organization.

Read their story here.

What’s next

Do you love shorts (not the type you wear, but the vertical video kind)? We’re publishing shorts over at YouTube, Instagram, TikTok, and our new Posit Open Source LinkedIn showcase page. I’d love to hear what short you’d like to see next!

We continue to have an excellent line up on the Data Science Hangout and Data Science Lab.

• On June 9, we’re doing a Community Showcase with Kylie Ainslie and Daniel Chen! Let’s learn about how others are using open-source tools in really cool ways.
• Jamie Shive, Director of Data Science at the National Hockey League, is the featured leader of the Hangout on June 11 (which could coincide with the Stanley Cup finals!). Let’s talk about everything about hockey and beyond.

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.

Good news! Toolbars are here to save you.

Their small size and low-profile aesthetic is perfect for keeping your favorite filters and buttons compact and legible. They’re modular and they work in some of your favorite existing components. Seeing is believing, so let’s jump in!

We’re going to provide some examples of classic spots where you might want a toolbar.

install.packages("bslib")

pip install --upgrade shiny

Our Example

We’re going to build a version of this app piece by piece:

Setup Code

Let’s get you set up with a basic app with some cards. We’ll use this canvas as a starting point for our toolbar components.

library(shiny)
library(bslib)

ui <- page_fluid(
  h2("Example App"),
  layout_columns(
    card(
      card_header(
        "Toolbar in header & label"
      ),
      card_body(
        p("Placeholder text.")
      )
    ),
    card(
      card_header(
        "Toolbar in header, footer, label"
      ),
      card_body(
        p("More placeholder text.")
      ),
      card_footer(
        p("Footer content here.")
      )
    ),
    col_widths = c(6, 6)
  ),
  card(
    card_header(
      "Toolbar in Text Input Submit Area: Message Composer"
    ),
    card_body(
      layout_columns(
        p("Placeholder for an input"),
        div(
          p("Placeholder for outputs")
        ),
        col_widths = c(6, 6)
      )
    )
  )
)

server <- function(input, output, session) {
  # Placeholder
}

shinyApp(ui, server)

from faicons import icon_svg

from shiny import App, Inputs, Outputs, Session, reactive, render, ui

app_ui = ui.page_fluid(
    ui.h2("Example App"),
    ui.layout_columns(
        ui.card(
            ui.card_header(
                "Toolbar in header & label",
            ),
            ui.card_body(ui.p("Placeholder text.")),
        ),
        ui.card(
            ui.card_header(
                "Toolbar in header, footer, label",
            ),
            ui.card_body(ui.p("More placeholder text.")),
            ui.card_footer(ui.p("Footer content here.")),
        ),
        col_widths=[6, 6],
    ),
    ui.card(
        ui.card_header(
            "Toolbar in Text Input Submit Area: Message Composer",
        ),
        ui.card_body(
            ui.layout_columns(
                ui.p("Placeholder for an input"),
                ui.div(ui.p("Placeholder for outputs")),
                col_widths=[6, 6],
            ),
        ),
    ),
)


def server(input: Inputs, output: Outputs, session: Session) -> None:
    pass


app = App(app_ui, server)

A toolbar on its own is pretty simple. All you have to do is:

toolbar(align = "right")

ui.toolbar(align="right")

That’s just an empty container. The real fun is when we start adding our toolbar inputs and connecting them to card contents.

Toolbars in Card Headers & Footers

Toolbars are great for card headers and footers because they provide a clear way to associate a set of controls with a given subset of the app. For example, you can see below that the header toolbar provides controls that clearly correspond to the contents of the card.

card_header(
  "Sales Data",
  toolbar(
    align = "right",
    toolbar_input_select(
      id = "region_filter",
      label = "Region",
      choices = c("All", "North", "South", "East", "West"),
      icon = icon("filter")
    ),
    toolbar_divider(),
    toolbar_input_button(
      id = "save_btn",
      label = "Save",
      icon = icon("floppy-disk")
    )
  )
)

library(shiny)
library(bslib)

ui <- page_fluid(
  h2("Example App"),
  layout_columns(
    card(
      card_header(
        "Sales Data",
        toolbar(
          align = "right",
          toolbar_input_select(
            id = "region_filter",
            label = "Region",
            choices = c("All", "North", "South", "East", "West"),
            icon = icon("filter")
          ),
          toolbar_divider(),
          toolbar_input_button(
            id = "save_btn",
            label = "Save",
            icon = icon("floppy-disk")
          )
        )
      ),
      card_body(
        tableOutput("sales_table")
      )
    ),
    card(
      card_header(
        "Toolbar in header, footer, label"
      ),
      card_body(
        p("More placeholder text.")
      ),
      card_footer(
        p("Footer content here.")
      )
    ),
    col_widths = c(6, 6)
  ),
  card(
    card_header(
      "Toolbar in Text Input Submit Area: Message Composer"
    ),
    card_body(
      layout_columns(
        p("Placeholder for an input"),
        div(
          p("Placeholder for outputs")
        ),
        col_widths = c(6, 6)
      )
    )
  )
)

server <- function(input, output, session) {
  # Handle save button click
  observeEvent(input$save_btn, {
    # Change icon to checkmark and show notification
    update_toolbar_input_button(
      "save_btn",
      icon = icon("check"),
      label = "Saved",
      session = session
    )
    showNotification("Saving", type = "message")
  })

  # Sample sales data
  sales_data <- reactive({
    data.frame(
      Product = c("Widget A", "Widget B", "Widget C", "Widget D"),
      Region = c("North", "South", "East", "West"),
      Sales = c(1200, 850, 1450, 920),
      stringsAsFactors = FALSE
    )
  })

  # Filtered sales data based on region filter
  filtered_data <- reactive({
    data <- sales_data()

    if (input$region_filter != "All") {
      data <- data[data$Region == input$region_filter, ]
    }

    data
  })

  # Render the table
  output$sales_table <- renderTable({
    data <- filtered_data()
    data$Sales <- paste0("$", format(data$Sales, big.mark = ",", trim = TRUE))
    data
  })
}

shinyApp(ui, server)

ui.card_header(
    "Sales Data",
    ui.toolbar(
        ui.toolbar_input_select(
            id="region_filter",
            label="Region",
            choices=["All", "North", "South", "East", "West"],
            icon=icon_svg("filter"),
        ),
        ui.toolbar_divider(),
        ui.toolbar_input_button(
            id="save_btn",
            label="Save",
            icon=icon_svg("floppy-disk"),
        ),
        align="right",
    ),
),

import pandas as pd
from faicons import icon_svg

from shiny import App, Inputs, Outputs, Session, reactive, render, ui

app_ui = ui.page_fluid(
    ui.h2("Example App"),
    ui.layout_columns(
        ui.card(
            ui.card_header(
                "Sales Data",
                ui.toolbar(
                    ui.toolbar_input_select(
                        id="region_filter",
                        label="Region",
                        choices=["All", "North", "South", "East", "West"],
                        icon=icon_svg("filter"),
                    ),
                    ui.toolbar_divider(),
                    ui.toolbar_input_button(
                        id="save_btn",
                        label="Save",
                        icon=icon_svg("floppy-disk"),
                    ),
                    align="right",
                ),
            ),
            ui.card_body(ui.output_table("sales_table")),
        ),
        ui.card(
            ui.card_header(
                "Toolbar in header, footer, label",
            ),
            ui.card_body(ui.p("More placeholder text.")),
            ui.card_footer(ui.p("Footer content here.")),
        ),
        col_widths=[6, 6],
    ),
    ui.card(
        ui.card_header(
            "Toolbar in Text Input Submit Area: Message Composer",
        ),
        ui.card_body(
            ui.layout_columns(
                ui.p("Placeholder for an input"),
                ui.div(ui.p("Placeholder for outputs")),
                col_widths=[6, 6],
            ),
        ),
    ),
)


def server(input: Inputs, output: Outputs, session: Session) -> None:
    @reactive.effect
    @reactive.event(input.save_btn)
    def update():
        ui.update_toolbar_input_button(
            "save_btn",
            icon=icon_svg("check"),
            label="Saved",
        )
        ui.notification_show("Saving", type="message")

    # Sample sales data
    @reactive.calc
    def sales_data():
        return pd.DataFrame(
            {
                "Product": ["Widget A", "Widget B", "Widget C", "Widget D"],
                "Region": ["North", "South", "East", "West"],
                "Sales": [1200, 850, 1450, 920],
            }
        )

    # Filtered sales data based on region filter
    @reactive.calc
    def filtered_data():
        data = sales_data()

        if input.region_filter() != "All":
            data = data[data["Region"] == input.region_filter()]

        return data

    # Render the table
    @render.table
    def sales_table():
        return (
            filtered_data()
            .style.hide(axis="index")
            .format({"Sales": "${:,.0f}"})
            .set_table_styles([
                {"selector": "th", "props": [
                    ("border-bottom", "1px solid black"),
                    ("padding", "8px 6px"),
                    ("text-align", "left"),
                ]},
                {"selector": "td", "props": [
                    ("padding", "6px"),
                ]},
            ])
        )


app = App(app_ui, server)