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

You can install the CRAN version of lorax via

install.packages("lorax")

or get the development version using

pak::pak("tidymodels/lorax")

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

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

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

rgr_fit

Ranger result

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

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

Visualizing the Trees

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

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

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

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

Which Predictors Were Used?

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

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

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

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

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

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

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

How often are predictors used?

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

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

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

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

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

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

var_imp(rgr_fit)

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

Examining Rules

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

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

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

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

[1] "call"

rgr_rules$rules[[1]]

item_23 <= 0.5 & hour <= 14.6645

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

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

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

A List of Methods

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

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

What’s Next?

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

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

1: Understand how Positron discovers your environment

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

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

2. Use the Interpreter Selector

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

3. Install Python with uv

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

4. Manage packages with the Packages Pane

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

5. View package documentation

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

6. Start projects with New Folder from Template

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

7. Make use of the Command Palette

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

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

8. Let Posit Assistant help manage your environment

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

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

Get it now:

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

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

OAuth token caching

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

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

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

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

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

Other features

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

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

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

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

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

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

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

Distributing state: CRDTs for real-time collaboration

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

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

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

Distributing compute: mirai and mori in the wild

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

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

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

The best part: the people

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

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

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

Contributing back: R Dev Day

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

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

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

Looking ahead

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

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

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

Positron Notebook Editor

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

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

Packages pane

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

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

Posit Assistant

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

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

Data Explorer

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

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

R language intelligence

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

What’s coming next

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

To install the package, run:

install.packages("mcptools")

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

library(mcptools)

Images in tool results

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

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

library(ellmer)

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

Running that function:

tools$fetch_reference_image()

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

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

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

MCP Servers on Posit Connect

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

engine: mcptools
tools: tools.R

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

Fetch tools as R functions from authenticated MCP servers

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

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

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

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

Now looks like:

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

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

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

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

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

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

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

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

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

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

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

Announcements

posit::conf(2026) is happening soon!

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

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

We’ve joined the Jupyter Foundation

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

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

Announcing an expanded Posit Academy

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

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

Introducing the Posit Impact Awards

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

• Submit your nomination before July 20th.

Key product updates and new releases

Data visualization and reporting

ggsql 0.4.1

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

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

Ask more of your dashboard with querychat and ggsql

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

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

Great Tables 0.22.0

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

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

Data access

dbplyr 2.6.0

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

• Learn more in the dbplyr 2.6.0 blog post.

webR 0.6.0

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

• Learn more in the webR 0.6.0 blog post.

Developer tools and AI

debrief 0.1.0

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

• Learn more in the debrief 0.1.0 blog post.

pkgsite 0.1.0

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

• Learn more in the pkgsite 0.1.0 blog post.

watcher 0.2.0

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

• Learn more in the watcher 0.2.0 blog post.

Development environment

Air 0.10.0

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

• Learn more in the Air 0.10.0 blog post.

What’s new in Positron

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

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

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

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

Machine learning and modeling

brulee 1.0.0

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

• Learn more in the brulee 1.0.0 blog post.

CatBoost support in tidymodels

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

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

tidyclust 0.3.0

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

• Learn more in the tidyclust 0.3.0 blog post.

Event roundup

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

Watch the recordings from some of these events:

Jun 15, 2026 | 34 min | 221 views

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

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

Neal Richardson

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

Jun 26, 2026 | 47 min | 29 views

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

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

Sara Altman, Simon Couch

infer tidymodels

Showcases from the community

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

• Check out the spotlight.

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

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

• Lorcana dashboard
• Lorcana GitHub repo

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

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

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

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

What’s next

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

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

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

May 29, 2026 | 57 min | 1.2k views

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

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

Charlie Gao

mirai mori plumber plumber2 Positron

Jun 23, 2026 | 58 min | 3.7k views

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

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

Hadley Wickham

bookdown bookdown.org leaflet pointblank

Feb 19, 2026 | 55 min | 1.7k views

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

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

Edgar Ruiz

devtools dplyr pkgdown roxygen2 usethis

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

watcher is a lightweight R package that watches files and directories for changes and reacts in the background. It shipped quietly last year as the engine behind Shiny’s auto-reload, and until now that is mostly where it lived. watcher 0.2.0 is on CRAN, and we’re taking this opportunity to introduce it as a general-purpose filesystem watcher for R developers to use.

Install it from CRAN:

install.packages("watcher")

The engine behind Shiny auto-reload

The inner loop of building a Shiny app is edit, save, switch to the browser, reload. Auto-reload removes the friction of the last two steps: you save, and the app reloads itself.

The easiest way to turn it on is Shiny’s Developer Mode, which flips on a handful of developer-friendly options for the session – auto-reload among them, alongside unminified JavaScript and full stack traces. Call devmode() once and run your app as usual:

shiny::devmode()
shiny::runApp("app.R")

Now every time you save a file in the app directory, the running app reloads to match:

Editing app.R on the left; the app on the right reloads on each save. No manual refresh or restart.

Under the hood, Developer Mode sets shiny.autoreload = TRUE (you can set that option directly if you’d rather not switch on the rest of Developer Mode), which hands your app directory to watcher and starts it watching in the background. The instant you save a file, watcher’s callback fires and Shiny pushes a reload to the browser.

Previously Shiny did this by polling: every few hundred milliseconds it re-listed the directory and compared modification times. That works, but the cost scales with the size of your project and the reload only ever happens on the next tick. watcher instead subscribes to the operating system’s own filesystem-change notifications, so the reload fires on the save itself, and an idle app does no work at all.

For version 0.2.0, we’ve simplified how the package installs from source. This means we can have it power auto-reload by default: the next release of Shiny will require watcher outright, so it’s installed alongside Shiny with nothing to install by hand. (Shiny 1.14.0 uses watcher when it’s present and falls back to polling otherwise – so for now it’s worth installing watcher yourself).

watcher, the package

This same machinery is available directly, outside of Shiny. watcher() returns an R6 object that you can start and stop:

library(watcher)

dir.create("data")

w <- watcher(
  path = "data",
  callback = \(paths) cat("changed:", paths, "\n"),
  latency = 0.5
)
w$start()

From now on, any change under data/ calls your function back with the paths that changed:

file.create("data/report.csv")
#> changed: /home/you/project/data/report.csv

Three arguments to watcher() cover most needs:

• path – a file, a directory (watched recursively), or a vector of paths. Defaults to the working directory.
• callback – a function taking one argument: a character vector of the paths that changed. The default, NULL, simply writes the changed paths to stdout.
• latency – seconds to debounce events before reporting them. Defaults to 1.

w$stop()

The returned object also has $stop(), $is_running() and $get_path() alongside $start().

watcher runs on a background thread, but your callback runs on R’s main thread, scheduled through later. It fires when R is idle at the top level, whenever you call later::run_now(), or automatically inside an event loop such as Shiny’s. This is what lets it slot easily into Shiny or plumber without blocking the session.

Put it to work

watcher is deliberately small and general. Anything you want to happen when a file changes, you can wire to it:

• rebuild a report or re-render a document when its source or data changes
• reprocess a directory as new files land in it
• re-run tests or reload package code while you develop
• reload configuration without restarting a long-running service

The shape is always the same – give watcher() a path and a function:

library(watcher)

rebuild <- function(paths) {
  message(format(Sys.time()), ": ", length(paths), " file(s) changed")
  # ... your render / test / reload step here ...
}

w <- watcher("data", rebuild, latency = 1)
w$start()

The callback receives the paths that changed, so you can act on exactly what triggered it. File created, updated, removed and renamed events are monitored, for individual files or whole directory trees.

From here:

• watcher package site – reference and examples.
• r-lib/watcher – source, issues, and feedback.
• For Shiny, enable Developer Mode with shiny::devmode() (or set options(shiny.autoreload = TRUE) directly).

Acknowledgments

watcher builds on libfswatch by Enrico M. Crisostomo and Alan Dipert. This is a mature C++ filesystem-monitoring library, which uses the native, event-driven notification API on each platform.

Thanks go to Garrick Aden-Buie for wiring watcher into Shiny’s auto-reload, and to everyone who has contributed issues, fixes, and feedback.

Questions and ideas are very welcome on GitHub: r-lib/watcher.

If you use Positron, the Air Extension has probably already updated you to the new release! Otherwise, follow one of Air’s editor guides to install the latest version for your editor.

To see every bug fix, check out our CLI changelog and extension changelog.

Assignment style 😎

The headlining feature of 0.10.0 is a new assignment-style option, one of our top requests! This allows you to enforce <- or = for assignment throughout your codebase. Choose one of "arrow" for <-, "equal" for =, or "preserve" to leave existing code as is. For example, with assignment-style = "arrow":

# This
a = 1
fn = function(x, y) {
  z <- x + y
  z
}

# Is standardized to
a <- 1
fn <- function(x, y) {
  z <- x + y
  z
}

This option defaults to enforcing <- everywhere, which is what the style guide already recommended. Note that this is a breaking change for Air, as the previous behavior didn’t enforce any assignment style. To revert to the old behavior, use "preserve".

This feature is surprisingly sophisticated! In R, you can always convert from = to <- without changing the meaning of the code, but the reverse isn’t true. Consider the following:

quote(x <- 1)

This quotes the expression x <- 1 and returns it. Blindly changing to = results in:

quote(x = 1)

That’s very different! This sets an argument named x to 1. Trying to run this will result in an error since quote() doesn’t have an x argument. Air knows every case where <- is allowed but = isn’t, so you can rest assured that this option won’t impact the meaning of your code in any way.

Positron terminal support

Positron’s integration with Air has gotten even better! When the Air extension activates, it now prepends the bundled Air executable to your integrated terminal’s PATH. This means:

• You can now run Air commands from Positron’s terminal, even without installing the CLI separately.
• Your terminal version of Air should now always match the version used by the editor itself.

This is particularly useful with agents like Claude Code, where you’ll often want to tell your agent to run Air on any R files it touches (see usethis::use_tidy_agents() in the development version of usethis for a way to automatically add this to an AGENTS.md).

If you’ve already installed the Air CLI separately, note that the bundled version will take precedence in Positron’s terminals by default. To force both the editor and the integrated terminal to use your externally installed version of Air, set air.executableStrategy: "environment". To opt-out of terminal support, set air.addExecutableToTerminalPath: false.

RStudio improvements

Thanks to Kevin Ushey, RStudio’s support for Air is improving rapidly!

Note that you’ll need RStudio 2026.06.0 for this, which isn’t out yet, but should be by the end of next week.

RStudio now has “native” support for Air, rather than just being configurable as an External Formatter. If you opt-in to Air, RStudio will now automatically download the latest version of the air binary the first time you save a file, making the whole experience much smoother.

You can turn this on via Tools -> Global Options... -> Code -> Formatting. I recommend checking both Use Air for code formatting and Reformat documents on save.

Lions, tigers, and bears uv, pixi, and mise, oh my!

Air now lives on PyPi as air-formatter (sadly air was already taken), which means that you can now install Air’s CLI via uv:

# Install globally
uv tool install air-formatter
air format path/to/file.R

# Run one-off command
uvx --from air-formatter air format path/to/file.R

It might sound a little absurd to put an R code formatting tool on Python’s PyPI, but in a world where an increasingly large number of R users are also uv users, it’s pretty darn convenient to be able to invoke it this way!

Additionally, Air is on conda-forge thanks to @salim-b, which means you can also install it with pixi and mise:

# Add to a project
pixi add air
mise use conda:air

# Install globally
pixi global install air
mise use --global conda:air

# Run one-off command
pixi exec air format path/to/my/script.R
mise exec conda:air -- air format path/to/my/script.R

pre-commit support

Air now has pre-commit and prek support via posit-dev/air-pre-commit. To run Air on changed R files before every commit, add the following to your .pre-commit-config.yaml:

repos:
- repo: https://github.com/posit-dev/air-pre-commit
  # Air version
  rev: 0.10.0
  hooks:
    # Run the formatter
    - id: air-format

stdin support

Air’s CLI now has stdin support! You can activate this with the new --stdin-file-path option like so:

cat R/across.R | air format --stdin-file-path R/across.R

air will receive the contents of cat R/across.R on stdin, format it, and then emit the formatted result back out on stdout.

You typically won’t call this directly, but it’s very useful for editors and IDEs without full language server support. For example, with Zed you can configure Air as an external formatter with the following setup:

"formatter": {
  "external": {
    "command": "air",
    "arguments": ["format", "--stdin-file-path", "{buffer_path}"]
  }
}

This allows Zed to invoke Air on every file save.

Note that Zed does have full language server support, and it’s recommended to use our Air extension for Zed instead, but it makes for a nice example anyways!

Invoking Air via stdin can also be useful in some embedded contexts, such as inside arf, an R console.

Shell completions

Thanks to @salim-b, Air can now generate shell completions for itself via a new air generate-shell-completion <shell> command, where <shell> can be one of zsh, bash, powershell, fish, or elvish. Read the documentation for how to set this up for your specific shell. With shell completions set up, you can Tab your way through air commands at the command line:

Installing CatBoost

The one wrinkle is installation. The CatBoost R package is not on CRAN, so you can’t reach for install.packages("catboost") directly.

Grab the URL for your platform from the CatBoost R installation guide and install it with the remotes package. For example, on an Apple Silicon or Intel Mac:

install.packages("remotes")
remotes::install_url(
  "https://github.com/catboost/catboost/releases/download/v1.2.10/catboost-R-darwin-universal2-1.2.10.tgz",
  INSTALL_opts = c("--no-multiarch", "--no-test-load", "--no-staged-install")
)

Swap in the release version, operating system, and architecture that match your setup. The guide lists the full URL pattern and the binaries available for each release.

Once CatBoost itself is installed, the tidymodels packages is just the usual packages:

# install.packages("pak")
pak::pak(c("tidymodels", "bonsai"))

You’ll need bonsai 0.4.1 (or later) and parsnip 1.4.0 (or later), which is where the CatBoost engine landed and got polished.

Fitting a CatBoost model

CatBoost is supported as an engine for []boost_tree()](https://parsnip.tidymodels.org/reference/details_boost_tree_catboost.html). Loading bonsai registers the engine, and from there it behaves like any other parsnip model spec:

library(tidymodels)
library(bonsai)

cat_spec <-
  boost_tree(trees = 500, learn_rate = 0.05) |>
  set_engine("catboost") |>
  set_mode("regression")

cat_fit <- fit(cat_spec, mpg ~ ., data = mtcars)
cat_fit

parsnip model object

CatBoost model (500 trees)
Loss function: RMSE
Fit to 10 feature(s)

Tuning

The CatBoost engine supports the standard boost_tree() tuning parameters, and the recent releases made tuning both faster and more correct.

A typical tuning setup looks like this:

cat_spec <-
  boost_tree(trees = tune(), learn_rate = tune()) |>
  set_engine("catboost") |>
  set_mode("regression")

cat_wf <- workflow(mpg ~ ., cat_spec)

set.seed(123)
folds <- vfold_cv(mtcars, v = 5)

tune_res <- tune_grid(cat_wf, resamples = folds, grid = 20)

show_best(tune_res, metric = "rmse")

# A tibble: 5 × 8
  trees learn_rate .metric .estimator  mean     n std_err .config         
  <int>      <dbl> <chr>   <chr>      <dbl> <int>   <dbl> <chr>           
1  1473     0.0379 rmse    standard    2.76     5   0.419 pre0_mod15_post0
2   527     0.0513 rmse    standard    2.81     5   0.443 pre0_mod06_post0
3  1053     0.0941 rmse    standard    2.83     5   0.447 pre0_mod11_post0
4   211     0.127  rmse    standard    2.84     5   0.400 pre0_mod03_post0
5   632     0.234  rmse    standard    2.86     5   0.480 pre0_mod07_post0

Thanks to the submodel trick tuning trees doesn’t require refitting the model from scratch at every candidate value.

orbital support

CatBoost models also work with orbital, allowing you to turn your fitted catboost model into SQL and run predictions directly inside a database.

library(orbital)

cat_spec <-
  boost_tree(trees = 50, learn_rate = 0.05) |>
  set_engine("catboost") |>
  set_mode("regression")

cat_wf <- workflow(mpg ~ ., cat_spec)
cat_fit <- fit(cat_wf, data = mtcars)

orbital_obj <- orbital(cat_fit)
orbital_obj

── orbital Object ──────────────────────────────────────────────────────────────
• .pred = dplyr::case_when(cyl <= 5 ~ dplyr::case_when(wt <= 2.17 ~ dplyr ...
────────────────────────────────────────────────────────────────────────────────
1 equations in total.

From here you can predict in-database with predict() against a database connection, or generate the SQL directly with orbital_sql(). See the orbital documentation for the full set of supported backends.

Wrapping up

CatBoost is a great addition to the gradient boosting options available in tidymodels, especially if you work with categorical features or want a strong out-of-the-box model.

For the full details, see the bonsai changelog and the parsnip 1.4.0 release notes.

Since its inception, Project Jupyter has grown into one of the world’s most widely used open source ecosystems for interactive computing, powering breakthroughs in research, education, and industry. The Jupyter Foundation, hosted by the Linux Foundation, was established to support the long-term sustainability of this work by bringing together organizations committed to investing in the project’s future.

By joining as a Foundation Member, we are becoming active stewards of its future. Our membership helps fund the core infrastructure, the release engineering, and the community events that keep Jupyter at the cutting edge of scientific computing. This move reinforces our promise to the open source community: we will not only build on these tools, but we will also build up the people and processes that create them.

Open source is a shared resource, and it requires shared responsibility. We encourage our partners and peers in the industry to join us in supporting the foundations that make our work possible.

To learn more about our commitment to open research and technical innovation, visit our About Page.

Who should come?

You don’t need an extensive development background. You don’t need to have solved issues before or sent a pull request. What you do need: a GitHub account and some basic familiarity with git.

In the weeks before TDD, on September 3, 2026 at 12-1 pm EDT, we’ll hold optional virtual office hours so you can get your R environment, git workflow, GitHub setup, and IDE all humming in harmony — walk in on the day feeling completely ready. Participants who have signed up by that date will receive an email with the Zoom link for the office hours.

How to sign up

There is a token $10 cost for the day; we provide the venue, snacks, lunch, and a barista. If cost is an issue, please email hadley@posit.co and we’ll work that out. We only charge a small fee to encourage people to show up for the day.

Get your ticket now!

Note: By using this link, you agree to Posit’s Privacy Policy, available at https://posit.co/about/privacy-policy. You also consent to using https://lu.ma for the purposes of processing your event attendance fees.

Previous Tidy Dev Days have sold out quickly, so don’t wait!

install.packages("brulee")

# or 

pak::pak("brulee")

New Models

In the field of deep learning (DL), the term “tabular” refers to models that use common rectangular data sets, i.e., data in data frames or matrices. It specifically excludes raw images or unstructured text.

This release adds five new models:

• Residual networks (ResNet) via brulee_resnet()
• Regularization learning networks (RLN) with brulee_rln()
• AutoInt via brulee_auto_int()
• Self-Attention and Inter-sample Attention Transformer (Saint) using brulee_saint()
• Chronos2 foundational model for forecasting via brulee_chronos()

These models share common argument names and have the same conventions as existing brulee models, such as brulee_mlp(). Many of these models incorporate modern neural network techniques, such as batch normalization, residual connections, and/or attention mechanisms.

For applications with large amounts of data, these modern techniques can make an already difficult optimization problem easier. The attention mechanisms also allow the model to be more expressive, leading to better performance.

Here’s an example using AutoInt. The data are simulated values with 10 predictors, a regression equation containing numerous interaction terms, and a true RMSE of 0.25.

The model was trained and evaluated on a random 10% of the data to determine early stopping. Training (using the ADAMw optimizer) stopped after 5 bad epochs and reverted to the estimates at epoch 7.

library(brulee)
library(tidymodels)

set.seed(83)
train_data <- sim_regression(2000, method = "hooker_2004")
test_data <- sim_regression(2000, method = "hooker_2004")

# Put the predictors on the same scale:
rec <-
  recipe(outcome ~ ., data = train_data) |>
  step_normalize(all_numeric_predictors())

# Set the R seed
set.seed(13)
# Set the torch seed (they don't need to be the same)
torch::torch_manual_seed(13)
autoint_fit <-
  brulee_auto_int(
    rec,
    data = train_data,
    num_embedding = 20,
    verbose = TRUE
  )

epoch: 000, learn rate: 0.01, Loss (scaled): 1.06
epoch: 1, learn rate: 0.01, Loss (scaled): 0.179
epoch: 2, learn rate: 0.01, Loss (scaled): 0.144
epoch: 3, learn rate: 0.01, Loss (scaled): 0.12
epoch: 4, learn rate: 0.01, Loss (scaled): 0.103
epoch: 5, learn rate: 0.01, Loss (scaled): 0.115
epoch: 6, learn rate: 0.01, Loss (scaled): 0.102
epoch: 7, learn rate: 0.01, Loss (scaled): 0.101
epoch: 8, learn rate: 0.01, Loss (scaled): 0.109
epoch: 9, learn rate: 0.01, Loss (scaled): 0.101
epoch: 10, learn rate: 0.01, Loss (scaled): 0.108
epoch: 11, learn rate: 0.01, Loss (scaled): 0.112
epoch: 12, learn rate: 0.01, Loss (scaled): 0.116

autoplot(autoint_fit)

One new addition to brulee is a collection of summary() methods that print layer dimensions and the corresponding number of parameters. This model is complex but, by deep learning standards, is small:

summary(autoint_fit)

AutoInt architecture
inputs: 10 (0 categorical, 10 numeric) | output dim: 1

Embedding layer
  ContWeights(10 x 20)                200 params

Self-attention backbone (3 blocks, 2 heads)
  Linear(20 -> 32)                    672 params
  MultiheadAttention(32, heads=2)   4,224 params
  MultiheadAttention(32, heads=2)   4,224 params
  MultiheadAttention(32, heads=2)   4,224 params
  + skip: Linear(20 -> 32)            672 params
  ReLU                                  0 params
  output: 10 embeddings of dim 32 (flattened: 320)

Output head
  Linear(320 -> 1)                    321 params

Total parameters: 14,537

How well does the model work on unseen data? Pretty well! The RMSE is fairly close to the best possible value.

test_pred <-
  predict(autoint_fit, test_data) |>
  bind_cols(test_data)

test_pred |>
  ggplot(aes(outcome, .pred)) +
  geom_point() +
  geom_abline(col = "#8FDA04FF", lty = 2, linewidth = 1) +
  geom_smooth(col = "#D84D16FF", se = FALSE) +
  coord_fixed(ratio = 1)

test_pred |> metrics(outcome, .pred)

# A tibble: 3 × 3
  .metric .estimator .estimate
  <chr>   <chr>          <dbl>
1 rmse    standard       0.316
2 rsq     standard       0.898
3 mae     standard       0.251

One important note: the Chronos model is a pretrained foundational model for forecasting. On its first use, it will download the model weights. These are about 200 MB in size and are cached locally, so this download should occur only once. This is similar to how our package for the TabPFN foundational model operates.

Numerical Changes

This version breaks backward compatibility with previous versions, but for good reasons.

The first is to switch from 64-bit precision to 32-bit. This is a common strategy (and many DL models go down to 16- or 8-bit precision). This should make models run faster and have a smaller memory footprint, but the main reason was to enable GPU computations on Apple machines. Note, however, that for the data set and model sizes shown in the example above, there is limited efficiency gain on the GPU. Since the computational load is relatively light (by DL standards), the GPU spends most of its time idle, so it isn’t much faster than the CPU. With larger data sets and models like Saint or Chronos, there should be some time savings. Overall, though, there should be drastic memory savings when using the GPU compared to pure CPU computations.

We’ve also made an effort to increase the numerical stability of these methods. This involves a more pervasive gradient clipping strategy and, for classification models, a more numerically stable implementation of the cross-entropy objective function.

One small improvement concerns reproducibility. torch has some inconsistencies in how random numbers are handled for GPU computations. When initializing parameters for these models, the random numbers are generated on the CPU and then moved to the GPU. This allows the model to start from the same place independently of where the subsequent computations occur.

What’s Next

For brulee, the next big step is an R torch implementation of the TabICL foundational model. This shows great promise but has a large computational footprint (in terms of code and system resources). Like Chronos, it will also require downloading pretrained model weights. We have a working version but are conducting additional testing before we release it.

Outside of brulee, we’re working on a parsnip interface to these models. Deep neural networks tend to have many tuning parameters, and many of them substantially affect model performance. The extension will include a function to make efficient space-filling designs for models with multiple hidden layers.

Thanks

Banner image by Laura Peruchi.

Thanks to contributors @edgararuiz, @jeroenjanssens, @lizelgreyling, and @Wander03.

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().

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!