Starting with this month’s release (2026.10), Posit Assistant can now interact with nearly the entire Positron surface. This is less about replacing pointing and clicking with prompts (although you can do a bit of that too) and more about revealing things to Assistant that Positron already knows, giving it more and better context for your questions about your data or Positron itself.

These new features are currently in preview; enable them with the Assistant: Preview Features setting in Positron.

Enabled? Here are some things you can try:

Packages

Assistant can now connect to the same internal data source as Positron’s Packages pane. This means that requests to install a package will be fulfilled using the method appropriate to your current Python or R installation (Assistant used to get this wrong, occasionally). It also means you can ask for information about installed packages that Positron adds, such as active CVEs.

Try:

install the ggplot2 package in Positron

or

do any of the packages used in this script have active vulnerabilities? ask Positron

Interpreters

Positron maintains an inventory of every R and Python installation on your system so that it can recommend the best one for a new project, show a list when you ask to open a console, and so on. R and Python environment management and discovery is a complex topic with dozens of different packaging systems and conventions in play, so this inventory is invaluable.

Now Posit Assistant can see that list, too, answer questions about it, and set up new environments for you in Positron.

why don’t I see my R 4.1 installation in Positron?

what’s the highest version of Python available in Positron?

set up a new uv environment in this Positron project

Consoles

Posit Assistant can now start and select consoles. This is pretty useful if you work with long-running or concurrently running code!

run this R script in a separate Positron console

Publishing to Posit Connect

If you use Posit Connect, you can ask Posit Assistant to publish your content to Connect, or Connect Cloud.

publish this app to Connect

Security

You’ll be prompted each time Assistant wants to interact with Positron. Just as with code execution or shell execution, you can approve Positron commands one by one or auto-approve for your project.

Because Positron commands can make changes and perform some sensitive actions, they are not available in Assistant’s Ask mode.

Troubleshooting & Feedback

We’re still improving the way this system works. Many of the queries above are also answerable in some form without consulting Positron, though the results won’t be as good or consistent with your environment. Consequently, you may occasionally see Posit Assistant reach for the wrong tool; tell it to “ask Positron” or “use a Positron command” to accomplish a task if it gets it wrong.

We’d love your feedback on this new functionality in Positron, good or bad! Drop us a line in the Positron Discussions forum on Github.

We are thrilled to announce rig 0.11.0 (and 0.10.0), with lots of new functionalities: user mode R installations, R package and project management and much more. This is the third of three blog posts about the new rig release. This post is about managing R projects.

The first post covered user mode R installations, the second focused on R packages.

Full changelog on the rig web site.

Introduction

The new rig proj command lets you manage R projects and virtual environments. An R project lets you share and run R code in a standardized way. rig’s R projects use an rproj.toml manifest, which is still under development.

rig’s R project implementation largely works the same way as other project management tools for Python, Rust, and other languages.

The project lifecycle

A project lifecycle typically involves

1. rig proj init (or rig proj import) to create a new project.
2. rig proj add (and rig proj remove) to manage project dependencies.
3. rig proj lock to resolve how the project is installed over a range of R versions in a range of platforms.
4. rig proj sync to install a project according to the lock file.
5. rig run to execute R code within the context of the project.

Creating projects

There are three ways to create an R project. One is to create a brand new project with rig proj init. This creates a minimal rproj.toml manifest file that you can either edit manually or via rig proj add:

❯ rig proj init
✓ Created rproj.toml
✓ Created .Renviron
✓ Created .gitignore
✓ Created .rvenvlib/rvenv
ℹ Project set up for R 4.6.1. Next: add dependencies to rproj.toml, then
  run `rig proj lock` and `rig proj sync`.

❯ cat rproj.toml
[project]
name = "x"
version = "0.1.0"
type = "project"

[dependencies]
R = ">= 4.6"

Another way is to convert an existing project to an rproj.toml manifest. Start with an existing R project with a DESCRIPTION file and run rig proj import to create an rproj.toml manifest from it. Or start with an renv lock file and call rig proj renv import. rig proj import keeps all fields of DESCRIPTION, including various types of dependencies. For R packages you can use rproj.toml as the source of truth for package metadata and dependencies and (re)generate DESCRIPTION from it as needed, e.g. for CRAN submission.

A third way to create a project is to write an rproj.toml manifest manually.

Project types

There are two types of R manifests: projects and packages. In general we use project as a generic name for both types and consider a package as a specialized project.

For a package, create the R/, src/, etc. directories as usual. See below for a possible way to use the devtools based development tools for a rig project.

For projects rig does not have a suggested way for organizing R and other code, documentation and tests. If in doubt, follow the conventions of R packages. Use [[bin]] to specify executable scripts within the project, relative to the project root. You’ll be able to run these scripts with rig run.

Locking a project

rig proj lock reads rproj.toml and works out which exact packages should be downloaded and installed to satisfy all requirements from rproj.toml. All requirements always include the optional and soft dependencies. The result is a lock file called rproj.lock. This is also a TOML file, typically much bigger than the original rproj.toml project manifest.

Universal lock files

The lock can and usually does include packages for multiple platforms. The exact set of platforms and R versions to include in the lock file can be specified in rproj.toml or at the command line. By default rig includes the current R release and five platforms: the platform of the current machine, macOS arm64, Windows x86_64, generic glibc Linux and source (four platforms if the current platform coincides with one of the others).

A multi-platform lock file means that it is much easier to plan the cross-platform deployment of a project: a team can include all relevant platforms and R versions in the lock file and commit a lock file to version control.

rig also records system requirements in the lock file, for platforms that need them.

Stable URLs

Universal lock files only really work well if they contain stable URLs for binary packages for all platforms and R versions. This is why it is important to use P3M (or another Posit Package Manager instance) with extended metadata about all older package versions and all their corresponding binary builds. With P3M rig is typically able to generate lock files with binary packages for the last 3-4 R versions on all common platforms.

Sticky lock files

Adding new dependencies to a project runs rig proj lock, but it keeps the package versions already in rproj.lock, unless they conflict with the new requirements. This is important to be able to maintain a stable set of package versions while still adding new dependencies. To update an already existing dependency to a newer version, you need to run rig proj lock --upgrade-package. Or run rig proj lock --upgrade to upgrade all packages.

Preferring binary packages

By default rig does not choose an older binary package over a newer source package. You can change that with the prefer-binary setting in rproj.toml. E.g. prefer-binary = true means that rig will choose an older binary package over a newer source package, if the older package also satisfies the dependency requirements.

Excluding newer package versions

You can prevent rig from automatically upgrading to newer package versions by using the exclude-newer setting in rproj.toml. For example, exclude-newer = "2026-09-30" will exclude any package versions that were published after the specified date. This works for P3M’s CRAN and Bioconductor repositories, but not for generic CRAN-like repositories which typically do not have release dates.

Repositories

Projects ignore the global repository settings configured via rig repos. By default projects use P3M’s CRAN and Bioconductor repositories. This can be configured with [[repository]] entries in rproj.toml. You can turn off P3M’s CRAN and Bioconductor repositories and you can also add your own custom repositories.

rig’s solver and universal lock files work best with P3M’s CRAN and Bioconductor metadata, so we strongly recommend using them whenever possible.

Syncing a project

rig proj sync installs the packages listed in rproj.lock into the project library in .rvenv/lib, inside the project’s virtual environment. It locks first if the project manifest has changed since creating the lock file.

If the current project is a package (type = "package"), then rig proj sync will also install the package itself into the project library.

rig proj sync also installs the R version requested in the lock file, if it is not already installed. This makes it very easy to deploy a project in an empty container or virtual machine: only rig and the lock file are needed and rig installs everything required for the project: R, system requirements and R packages.

rig proj sync installs the hard requirements and the dev dependency group by default. For a production deployment you can use the --no-dev option to skip installing development dependencies. Use --group and --extra to install optional dependency groups and extra dependencies.

Fast and lean libraries

rig clones the package files when installing packages into the project library, whenever possible. This means that installation is very fast and space-efficient. Having the same package version installed for ten projects on the same disk only takes up the space of a single copy.

The virtual environment

A rig project has two kinds of files. rig proj init creates the ones that belong in version control: rproj.toml, .Renviron, .rvenvlib/rvenv and .gitignore. Commit these, together with rproj.lock, and a fresh clone of the project works after a rig proj sync, or right away with rig run.

rig proj sync creates the rest in the .rvenv directory: the project library in .rvenv/lib, R and Rscript wrapper scripts in .rvenv/bin, and some configuration files. .rvenv is specific to the machine, it is in .gitignore, and you can delete it any time, rig proj sync creates it again.

The .Renviron file and the small rvenv package in .rvenvlib make sure that R uses the project library whenever it starts in the project directory: from a terminal, or from RStudio, Positron or VS Code. You do not need to activate the project explicitly, although .rvenv/bin has activation scripts for the common shells if you prefer that.

Inside the project R only sees the project library, the tools library (see below) and the packages that come with R. Packages from your user or site library do not leak into the project.

If the project library is out of date compared to rproj.lock, e.g. after a git pull, R prints a warning at startup, and rig proj status tells you what changed. If you start R with rig run in the project directory, then it automatically runs rig proj sync as needed. If you use Positron, VS Code, RStudio or another IDE, then R will warn at startup if the virtual environment is out of date and suggest that you run rig proj sync and restart R.

Managing dependencies

R package dependencies are specified in the rproj.toml manifest under three types of tables. The [dependencies] table includes packages that are always installed. These are considered as R packages required for the project. Packages in [dependency-groups.<name>] are groups of development dependencies and they are only installed if requested, except for the dev group which is installed by default. For example, the packages that are needed for building the pkgdown website can go into a [dependency-groups.website] table. dependency-groups is similar to Config/Needs/<name> in DESCRIPTION files of R packages. Dependencies of optional features go into [optional-dependencies.<name>] tables and are only installed if requested. For example, if your package has functions for visualization, but these are not required for the core functionality, you may put them in an [optional-dependencies.viz] table and other packages using yours may opt in to the viz feature. (The infrastructure for depending on optional features in packages is not built yet, and package repositories need to support it as well.)

You can edit the rproj.toml manifest manually to add dependencies or use rig proj commands to do it. rig proj add adds packages to rproj.toml, then updates rproj.lock and installs the new packages into the project library:

❯ rig proj add dplyr cli

❯ cat rproj.toml
[project]
name = "x"
version = "0.1.0"
type = "project"

[dependencies]
R = ">= 4.6"
cli = "*"
dplyr = "*"

Without a version requirement rig adds a package as "*", any version. The exact version is recorded in rproj.lock, so you only need a version requirement if the project really needs a certain version. Version requirements use the same syntax as for rig pkg install, e.g. 'cli@>= 3.6' or 'dplyr@^1.1.0'. rig proj remove removes packages.

Use --dev to add a development dependency, e.g. testthat. These go into the [dependency-groups.dev] table.

Packages from GitHub, GitLab, git repositories, URLs and local paths use the same syntax as rig pkg install, see the second post. Bioconductor or other packages coming from the configured repositories work the same way as CRAN packages. To pin a package to a certain repository, e.g. an R universe, use --with-repos:

❯ rig proj add --with-repos rlib=https://r-lib.r-universe.dev cli

This adds the repository to rproj.toml and pins cli to it:

[dependencies]
cli = { version = "*", repository = "rlib" }

[[repository]]
name = "rlib"
url = "https://r-lib.r-universe.dev"

If rig cannot resolve the new dependencies, e.g. because of a typo in a package name, it restores rproj.toml.

Running a project

rig run starts R in the project’s environment, from anywhere inside the project. It locks and syncs the project first, if needed, so day to day you mostly need rig proj add, rig proj remove and rig run.

rig run script.R runs a script in the project’s environment. Arguments after the script name go to the script, and commandArgs(TRUE) picks them up. Use --no-project to run the script without the project.

A project can give names to its scripts, in [[bin]] tables of rproj.toml:

[[bin]]
name = "report"
path = "scripts/report.R"
description = "Build the report"

Then rig run report --format pdf runs scripts/report.R with the --format pdf arguments, and rig run --list lists all named scripts of the project.

You can also run the .rvenv/bin/R and .rvenv/bin/Rscript wrappers directly, or start R from your IDE in the project directory, see the virtual environment above.

Package development with devtools

To develop an R package as a rig project, use type = "package" in rproj.toml, or run rig proj import on an existing package. rig proj sync then installs the package itself into the project library, and creates DESCRIPTION from rproj.toml (if missing), so R CMD build, R CMD check and other tools keep working.

Development tools like devtools, usethis and roxygen2 are not dependencies of the package, so they should not be in rproj.toml. rig has a special global package library for them, called tools, and adds it to the library path of every project. Install your tools there once:

❯ rig pkg install -l tools devtools usethis roxygen2

and then they are available in all projects:

❯ rig run
> devtools::load_all()
> devtools::document()
> devtools::test()

Packages that the package’s tests and documentation need, e.g. testthat or knitr, are different. Add these with rig proj add --dev, so they are locked together with the other dependencies.

Inline scripts

Sometimes a project is just a single R script. For these rig supports inline dependencies: the script declares the R version and the packages it needs in a special comment block with a # /// script header and a # /// footer:

# /// script
# [dependencies]
# R = ">= 4.4"
# cli = "*"
# dplyr = ">= 1.1"
# ///

library(dplyr)
cli::cli_text("Hello from {.pkg cli}!")

Without the leading # characters, the block is the same TOML as in rproj.toml.

rig run script.R installs the right R version if needed, installs the packages into a separate environment in rig’s cache, and then runs the script. Your own package libraries do not change. The next run reuses the environment, so it starts right away. You can share a single .R file, and it runs the same way on every machine that has rig.

You can write the block by hand, or let rig manage it:

❯ rig proj init --script script.R
❯ rig proj add --script script.R cli dplyr
❯ rig proj remove --script script.R dplyr

To pin the exact R and package versions, lock the script:

❯ rig proj lock --script script.R

This writes script.R.lock next to the script. Keep the two files together, and rig run will use the versions from the lock file.

On macOS and Linux, start the script with #!/usr/bin/env -S rig run and make it executable, to run it like any other command. On Windows, rig system script-assoc lets you run .R files from cmd and PowerShell. See the scripts guide for more.

Caches

rig caches the files it downloads: repository metadata, package files, packages it built from source, git repositories of git and GitHub dependencies, and the environments of inline scripts. rig pkg, rig proj and rig run share the same cache, and so do all projects, so rig downloads or builds a package only once. rig refreshes the repository metadata once a day by default.

rig cache info shows how much space the cache takes, by category, and rig cache clean deletes it, or only one category of it, with --category:

❯ rig cache info
❯ rig cache clean --category scripts

Use --no-cache to skip the cache for a single command, and rig system dirs --cache to see where the cache is.

Your feedback is welcome!

We would love to hear your thoughts, suggestions, and any issues you encounter while using rig. Please use the issue tracker for bug reports and feature requests, and the discussion forum or Posit community for general questions and discussions.

Welcome back to another edition of our monthly Positron updates! Each month we share highlights from our latest release and useful resources. Last release we told you about a redesigned welcome page, a first version of Import Data, new Posit Assistant features, expanded Data Connections, package vulnerability scanning, and a more responsive Console. This milestone brings a new ability for Posit Assistant to drive Positron itself, a built-in MCP server so you can bring your own coding agent, Data Connections on by default, faster language features for Quarto, and smoother interpreter and project setup.

Posit Assistant can drive Positron

Posit Assistant can now operate Positron itself, not just the R or Python session inside it. You can ask it to run a Shiny app, open a Parquet file in the Data Explorer, set up a Python environment, browse your data connections, or deploy to Posit Connect. Posit Assistant uses the same source of truth as the Positron UI, so it works with your real interpreters, packages, and connections rather than guessing at them.

In practice, this means Posit Assistant can run and preview Dash, FastAPI, Flask, Gradio, marimo, Streamlit, and Shiny apps with the same app commands you use, see which apps are running along with their status and URL, and stop them. It can show HTML files and URLs in the Viewer pane, and it can read, take screenshots of, and interact with data apps and other content there, which makes it much more useful for checking its own work on an app. It can read your configured and detected Data Connections, browse a connection’s schema, and give you the code to open it. It can also tell which interpreter a project uses, explain why an installed interpreter isn’t showing up, and make that interpreter available, and it knows the commands for deploying to Connect through Posit Publisher.

To try this preview feature, enable the assistant.previewFeatures setting, and tell us what you think in the GitHub discussion.

Bring your own coding agent

If you already have a favorite coding agent other than Posit Assistant, this release lets it work alongside you in Positron. A new built-in Model Context Protocol (MCP) server lets coding agents such as Claude Code, Codex, and Gemini CLI work in your live Python and R sessions. Our goal is to give these agents a set of tools comparable to what Posit Assistant has: agents can list your sessions, run code in the Console, inspect objects without cluttering your history, read recent session history, interrupt a long-running computation, look at the current plot, and search for and run Positron commands. These other agents may not have the data science expertise that Posit Assistant has, but they can still help you write code and explore data.

You stay in the loop on what an agent does. Code that an agent runs shows up in the Console with the agent’s name next to it, so you can always tell agent code from your own. Console tabs also now show a dot when code runs in a console you aren’t looking at, whether that code came from Posit Assistant or an external agent.

To try this experimental feature, enable the ai.mcp.enabled setting. Positron configures Claude Code for you automatically, and the Positron MCP: Add to Coding Agent command sets up the Codex and Gemini CLIs. For any other MCP client, Copy Connection Details gives you a URL and token to connect with.

Data Connections on by default

Data Connections is now the default way to work with databases and data warehouses in Positron. Data Connections connects to databases directly, without needing a Python or R session, and it replaces both the older Connections pane and the Catalog Explorer. If you need the older Connections pane, set dataConnections.enabled to false and reload the window.

This release also extends what you can connect to and how you sign in. Amazon Redshift connections can sign in with AWS Identity and Access Management (IAM), for both Redshift Serverless and provisioned clusters, using credentials from the standard AWS credential provider chain. On Posit Workbench, Snowflake and Databricks connections can use the session’s managed credentials with no credential input at all. Snowflake users get the most new features this month; the Data Connections pane shows Snowflake semantic views with their dimensions, facts, metrics, and relationships, you can browse Snowflake stages as folders and files, and connections in connections.toml show up automatically as detected connections.

Smaller improvements round out the experience. When you open a DuckDB or SQLite file from the Explorer, Positron offers to create a data connection for it. Connect With can now generate ggsql code for SQLite, DuckDB, ODBC, PostgreSQL, and Redshift connections.

The Add Data Connection dialog lists each driver with a short description, and Positron now tells you when a connection fails to open or expand. For slow tables and views, the Data Explorer now shows a progress indicator and placeholders while data arrives, and it loads column summaries in two passes so that missing-value counts appear quickly and sparklines follow later.

Faster language features for Quarto

Positron now provides completions, hover, diagnostics, outline, formatting, and other language features natively for R and Python cells in Quarto and R Markdown documents. Before, the Quarto extension wrote temporary virtual documents to disk to power these features. Positron now uses a virtual notebook in memory instead, which is faster (especially in remote sessions) and solves a whole category of bugs, such as Python imports that did not resolve correctly. It also means Go to Definition, Find References, and Rename work across R cells, finding names that earlier cells define.

The document outline for Quarto and R Markdown documents with many code chunks now updates quickly, and it no longer shows duplicate groups or symbols. Inline output, including HTML tables and the inline Data Explorer, now scales with your editor font size. If you run into problems with the new language features and need to go back to the old behavior, set quarto.embeddedLanguageFeatures.native to false.

Interpreter project setup

Positron is better at setting up the right Python environment for your project. When a workspace has a uv.lock or pixi.lock file but no environment yet, Positron offers to create it with uv sync or pixi install, which is especially handy right after you clone a project. If uv is missing, the New Folder flow can install it for you, and package installs and the Packages pane work with uv right away. When Positron finds a new Python environment in a workspace, it now offers to start a console session in it, and system Python installations now show last in the interpreter picker, below uv, venv, conda, and pyenv environments.

For more control over interpreters in both Python and R, interpreter path settings now support ${workspaceFolder}, so a project can point to an interpreter that lives inside it. The new interpreters.definitions setting lets you define additional R and Python interpreters, each with its own label, environment variables, and startup script. This is useful for workflows like loading environment modules or configuring rJava before a session starts. Set interpreters.discovery to definitionsOnly to show only the interpreters you have defined for a language.

What’s coming next

• Meet Posit at Snowflake World Tour NYC on October 15. Stop by our booth, schedule time with a Posit expert, or catch our theater session on AI-powered data science where your data lives, inside Snowflake.
• Join us at Data Outpost on November 4-5 in San Francisco. I’ll be speaking on “The SQL Agent Harness We Didn’t Mean to Build,” about how the SQL tools we built in Positron for people turned out to already be a harness for AI assistants.

We are thrilled to announce rig 0.11.0 (and 0.10.0), with lots of new functionalities: user mode R installations, R package and project management and much more. This is the second of three blog posts about the new rig release. This post is about managing R packages.

The first post covered user mode R installations. The third post focuses on project management.

Full changelog on the rig web site.

Introduction

The new rig pkg command lets you manage R packages: installing, removing, and querying package dependencies. It supports CRAN-like repositories, packages in git repositories (including on GitHub), URLs pointing to package files and packages in local files and directories.

rig pkg is aimed at R users and developers who use a single (or a few) package libraries. If you prefer to use project-specific libraries, you probably want to use rig proj instead.

Managing installed packages

rig pkg list lists installed packages in a library. rig pkg remove removes a package from a library.

❯ rig pkg list
559 packages (R 4.6.1, main: /Users/gaborcsardi/Library/R/arm64/4.6/library)

Package              Version      Built   Platform                   Source
----------------------------------------------------------------------------------------------------------------
abind                1.4-8        4.6.0   -                          RSPM
ade4                 1.7-24       4.6.0   aarch64-apple-darwin23     CRAN
adegenet             2.1.11       4.6.0   aarch64-apple-darwin23     CRAN
AdmixPoly            1.0.1        4.6.0   aarch64-apple-darwin20     RSPM
affy                 1.90.0       4.6.1   aarch64-apple-darwin23     RSPM
affyio               1.82.0       4.6.0   aarch64-apple-darwin20     RSPM
[...]

rig pkg commands use the current default R version (as in rig default), unless the -r or --r-version option specifies otherwise. They use the default library (as in rig library default), unless the -l or --library option specifies otherwise.

rig pkg doctor checks the health of your package library, identifying any issues with installed packages or their dependencies: missing dependencies, dependency conflicts, ABI conflicts, etc. It also tells you how to fix these issues.

❯ rig pkg doctor
3 problems (1 error, 2 warnings) in 559 packages (R 4.6.1, main: /Users/gaborcsardi/Library/R/arm64/4.6/library)

Package              Version   Severity   Problem   Details
-------------------------------------------------------------------------------------------------------------
00LOCK-dress.graph   -         warning    lock      lock directory left behind by an interrupted installation
dress.graph          -         warning    broken    no DESCRIPTION file
missoNet             1.5.1     error      missing   Imports ComplexHeatmap, not installed

To fix the errors, run:
  rig pkg install ComplexHeatmap

To remove the leftover lock directories, if no installation is running, run:
  rm -rf /Users/gaborcsardi/Library/R/arm64/4.6/library/00LOCK-dress.graph

To remove the broken packages, run:
  rm -rf /Users/gaborcsardi/Library/R/arm64/4.6/library/dress.graph

✗ Found 1 error in /Users/gaborcsardi/Library/R/arm64/4.6/library

Installing packages

rig pkg install can install R packages from CRAN-like repositories, git repositories, GitHub, URLs, and local paths. It uses the default R version and the default package library (see below about libraries), unless otherwise specified. It caches metadata and package files heavily, avoids redundant downloads and installations, and performs downloads and package builds in parallel. It uses the host OS’s file cloning capabilities to efficiently copy files when installing packages.

If you used the pak R package to install R packages previously, rig pkg will probably feel familiar, except that you can run it from the command line instead of from within R.

This is what installing a package into an empty library looks like, if the package files are already cached:

❯ rig pkg install dplyr
▶ Downloading binary package metadata
▶ Solving dependencies
✓ Solved dependencies
15 of 15 packages to install (R 4.6.1, test: /Users/gaborcsardi/Library/R/arm64/4.6/library/__test)
Package     Version  Type    Action   Reason
cli         3.6.6    binary  install  not installed
dplyr       1.2.1    binary  install  not installed
generics    0.1.4    binary  install  not installed
glue        1.8.1    binary  install  not installed
lifecycle   1.0.5    binary  install  not installed
magrittr    2.0.5    binary  install  not installed
pillar      1.11.1   binary  install  not installed
pkgconfig   2.0.3    binary  install  not installed
R6          2.6.1    binary  install  not installed
rlang       1.3.0    binary  install  not installed
tibble      3.3.1    binary  install  not installed
tidyselect  1.2.1    binary  install  not installed
utf8        1.2.6    binary  install  not installed
vctrs       0.7.3    binary  install  not installed
withr       3.0.3    binary  install  not installed

▶ Downloading 15 packages
✓ Cached: cli
✓ Cached: dplyr
✓ Cached: generics
✓ Cached: glue
✓ Cached: lifecycle
✓ Cached: magrittr
✓ Cached: pillar
✓ Cached: pkgconfig
✓ Cached: R6
✓ Cached: rlang
✓ Cached: tibble
✓ Cached: tidyselect
✓ Cached: utf8
✓ Cached: vctrs
✓ Cached: withr
Complete: 0 downloaded, 15 cached [========================================] 15/15 packages

▶ Installing 15 packages.
Installed R6 2.6.1
Installed cli 3.6.6
Installed rlang 1.3.0
Installed magrittr 2.0.5
Installed pkgconfig 2.0.3
Installed glue 1.8.1
Installed withr 3.0.3
Installed utf8 1.2.6
Installed generics 0.1.4
Installed lifecycle 1.0.5
Installed vctrs 0.7.3
Installed tidyselect 1.2.1
Installed pillar 1.11.1
Installed tibble 3.3.1
Installed dplyr 1.2.1
✓ Installed all 15 packages successfully
✓ Installed 15 packages (R 4.6.1, test: /Users/gaborcsardi/Library/R/arm64/4.6/library/__test)

Version constraints

rig pkg install supports version constraints for packages. Request a specific version of a package with @==<version>:

❯ rig pkg install ggplot2@==4.0.2

If you are familiar with ~ and ^ version constraints from other languages, you can use them with rig pkg install as well. E.g. to install the latest version of the ggplot2 3.x.y series, you would run:

❯ rig pkg install ggplot2@^3.0.0

Dependency solver

The rig dependency solver makes sure that all package dependencies are resolved correctly before installation. If the combination of packages cannot be installed on the specified R version or platform, rig will report an error and refuse to proceed with the installation. For example:

❯ rig pkg install -r 4.0.5-x86_64 'testthat@>=3.3.0'
▶ Downloading binary package metadata
▶ Solving dependencies
✗ Cannot resolve dependencies for R 4.0.5 / x86_64-apple-darwin:
  Because testthat >=3.3.0 depends on R >=4.1.0 and you requested
  testthat >=3.3.0, the requested packages cannot be installed.

Packages from git, GitHub, URLs, paths

If you are familiar with pak’s syntax for installing packages from various non-CRAN sources, you can use the same syntax with rig. E.g. a GitHub package is simply username/repo. You can use the usual syntax for tags, branches, pull requests:

❯ rig pkg install r-lib/cli
❯ rig pkg install r-lib/cli@badcafe
❯ rig pkg install r-lib/cli@some-branch
❯ rig pkg install r-lib/cli#41

Prefix packages in git repositories with git::. To install a package from a URL simply use the full URL. For a local path use a relative path starting with ./, ../ or ~/ or an absolute path:

❯ rig pkg install .
❯ rig pkg install ./mypkg
❯ rig pkg install ../mypkg
❯ rig pkg install ~/works/mypkg
❯ rig pkg install /opt/src/mypkg
❯ rig pkg install ./mypkg_1.0.0.tar.gz

Preferring binary packages

rig prefers to install the binary package for a certain package version if it is available, instead of building and potentially compiling it from source. By default it does not choose an older version over a newer one just because a binary is available for the older version. The --prefer-binary option changes this. Use it if you prefer older binary packages over newer source packages:

❯ rig pkg install --prefer-binary tidyverse

Installing dependencies

To install the dependencies of a package, without installing the package itself, use --no-install-project. This is especially useful to install all dependencies of a package tree in the current working directory. The second variant also installs soft (development) dependencies:

❯ rig pkg install --no-install-project .
❯ rig pkg install --no-install-project --dev .

Repositories

rig pkg subcommands always use the configured repositories, see the rig repos command. They also have --with-repos and --without-repos options to include or exclude specific repositories when performing a single package operation, without modifying the configured repositories. E.g. to query the version of a package on CRAN and P3M you can run:

❯ rig pkg info otel --without-repos --with-repos=p3m --versions
otel — 2 versions (latest 0.2.0)

Version   Published    R          Deps
-------------------------------------------------------
0.1.0     2025-07-31   >= 3.6.0      0
0.2.0     2025-08-29   >= 3.6.0      0   ← latest

❯ rig pkg info otel --without-repos --with-repos=cran --versions
otel — 1 version (latest 0.2.0)

Version   Published   R          Deps
-------------------------------------------------------
0.2.0     ?           >= 3.6.0      0   ← latest

Package queries

rig pkg info prints information about a package, by default about the latest version:

❯ rig pkg info tidymodels
tidymodels 1.5.0 (RSPM)
Easily Install and Load the 'Tidymodels' Packages

The tidy modeling "verse" is a collection of packages for modeling and
statistical analysis that share the underlying design philosophy, grammar, and
data structures of the tidyverse.

Maintainer    Max Kuhn <max@posit.co>
License       MIT + file LICENSE
Published     2026-04-23 06:20:02 UTC
URL           https://tidymodels.tidymodels.org,
              https://github.com/tidymodels/tidymodels
BugReports    https://github.com/tidymodels/tidymodels/issues
Compilation   no

Depends       R (>= 4.1)
Imports       broom (>= 1.0.12), cli (>= 3.6.6), conflicted (>= 1.2.0), dials
              (>= 1.4.3), dplyr (>= 1.2.1), ggplot2 (>= 4.0.3), hardhat (>=
              1.4.3), infer (>= 1.1.0), modeldata (>= 1.5.1), parsnip (>=
              1.5.0), purrr (>= 1.2.2), recipes (>= 1.3.2), rlang (>= 1.2.0),
              rsample (>= 1.3.2), rstudioapi (>= 0.18.0), tailor (>= 0.1.0),
              tidyr (>= 1.3.2), tune (>= 2.1.0), workflows (>= 1.3.0),
              workflowsets (>= 1.1.1), yardstick (>= 1.4.0)
Suggests      covr, glue, knitr, rmarkdown, testthat (>= 3.0.0), xml2

rig pkg info --versions lists all versions of a package. This only works with P3M repositories because it needs extended metadata that plain CRAN-like repositories typically do not have:

❯ rig pkg info tidymodels --versions
tidymodels — 17 versions (latest 1.5.0)

Version   Published    R        Deps
-------------------------------------------------------
0.0.1     2018-07-27   >= 3.1     18
0.0.2     2018-11-27   >= 3.1     20
0.0.3     2019-10-04   >= 3.1     20
0.1.0     2020-02-16   >= 3.1     22
0.1.1     2020-07-14   >= 3.1     20
0.1.2     2020-11-22   >= 3.1     19
0.1.3     2021-04-19   >= 3.1     20
0.1.4     2021-10-01   >= 3.1     21
0.2.0     2022-03-19   >= 3.4     21
1.0.0     2022-07-13   >= 3.4     21
1.1.0     2023-05-01   >= 3.4     21
1.1.1     2023-08-24   >= 3.4     21
1.2.0     2024-03-25   >= 3.6     21
1.3.0     2025-02-21   >= 3.6     21
1.4.0     2025-09-05   >= 4.1     21
1.4.1     2025-09-08   >= 4.1     21
1.5.0     2026-04-23   >= 4.1     21   ← latest

rig pkg deps prints the dependencies of a package. rig pkg tree does the same, but as a dependency tree. You can use these commands to query non-CRAN-like packages. E.g. the dependency tree of the package in the current working directory is

❯ rig pkg tree --dev .
otelsdk 0.2.4.9000 (local: /Users/gaborcsardi/works/otelsdk) — 14 direct, 51 total
├── otel 0.2.0
│   └── R (>= 3.6.0) [D]
└── utils
[Suggests]
├── callr 3.8.0
│   ├── R (>= 3.4) [D]
│   ├── otel 0.2.0 (>= 0.2.0) (*)
│   ├── processx 3.9.0 (>= 3.6.1)
│   │   ├── R (>= 3.4.0) [D]
│   │   ├── ps 1.9.3 (>= 1.9.3)
│   │   │   ├── R (>= 3.4) [D]
│   │   │   └── utils
│   │   ├── R6 2.6.1
│   │   │   └── R (>= 3.6) [D]
│   │   └── utils
│   ├── R6 2.6.1 (*)
│   └── utils
├── cli 3.6.6
│   ├── R (>= 3.4) [D]
│   └── utils
├── curl 8.0.0
│   └── R (>= 3.0.0) [D]
[...]

The --dev flag includes development dependencies as well.

rig pkg search searches all CRAN packages using R-hub package search service:

❯ rig pkg search palette --short
- "palette" ----------------------------------- 177 packages in 0.009 seconds -
 #     package      version  by                     @ title
 1 100 RColorBrewer 1.1-3    Erich Neuwirth        5y ColorBrewer Palettes
 2  46 colorspace   2.1-3    Achim Zeileis         3M A Toolbox for Manipula...
 3  23 paletteer    1.7.0    Emil Hvitfeldt        9M Comprehensive Collecti...
 4  16 ggsci        5.2.0    Nan Xiao              2M Scientific Journal and...
 5  13 wesanderson  0.3.7    Karthik Ram           3y A Wes Anderson Palette...
 6   8 rcartocolor  2.1.2    Jakub Nowosad         1y 'CARTOColors' Palettes
 7   8 pals         1.10     Kevin Wright          2y Color Palettes, Colorm...
 8   8 scico        1.5.0    Thomas Lin Pedersen   3y Colour Palettes Based...
 9   6 palette      0.0.3    Christopher T. Kenny  1y Color Scheme Helpers
10   6 MetBrewer    0.2.0    Blake Robert Mills    5y Color Palettes Inspire...
11   6 palr         0.5.0    Michael D. Sumner     2M Colour Palettes for Data
12   6 blends       0.1.2    David Hodge           3M Blend Colours and Pale...
13   6 biscale      1.1.0    Christopher Prener    1y Tools and Palettes for...
14   5 palettes     0.2.2    Michael McCarthy      1y Methods for Colour Vec...
15   5 PrettyCols   1.1.0    Nicola Rennie         2y Pretty Colour Palettes
16   5 gifski       1.32.0-2 Jeroen Ooms           2y Highest Quality GIF En...
17   5 wacolors     0.3.1    Cory McCartan         5y Colorblind-Friendly Pa...
18   4 colourpicker 1.3.0    Dean Attali           3y A Colour Picker Tool f...
19   4 amerika      0.1.1    Philip Waggoner       1y American Politics-Insp...
20   4 makePalette  0.1.2    Jorge L. C. Musaja    3y Make Palette

Next 20 results: rig pkg search palette --from 21 --short

Package libraries

rig creates a user-level package library for each R installation by default. (See the rig FAQ why.) This is the package library that rig pkg commands use by default.

The rig library command supports creating other package libraries, still stored in the user’s home directory. You can refer to them by name and make them the default library for rig pkg commands with rig library default.

For example to create a temporary library and install the Shiny package from GitHub into it, including development dependencies, you can run:

rig library add test
rig library default test
rig pkg install --dev rstudio/shiny

You can also use the -l or --library option of the rig pkg commands to change the package library temporarily for one command, without changing the default.

If you are using the macOS menu bar app, then you can also manage package libraries through the app’s interface.

System requirements

On certain Linux systems rig supports automatic system requirements installation. These are currently:

• Ubuntu Linux
• RedHat Enterprise Linux and clones
• openSUSE Linux and SUSE Linux Enterprise
• Debian Linux
• Fedora Linux
• Alpine Linux

For the automatic system requirements installation to work, rig must run as the root user or with password-less sudo privileges to call the system package manager.

Note that in user mode, rig installs the self-contained manylinux R build, which does not require any system-level dependencies and also sets up Posit’s manylinux package repository, which has self-contained binaries for most CRAN and Bioconductor packages. So in user mode you typically do not need to worry about system-level dependencies.

Your feedback is welcome!

We would love to hear your thoughts, suggestions, and any issues you encounter while using rig. Please use the issue tracker for bug reports and feature requests, and the discussion forum or Posit community for general questions and discussions.

Last month, we gave a posit::conf(2026) keynote on building correct, transparent, and reproducible data agents. The talk brings together many themes from this newsletter, so this week we’re sharing an annotated walkthrough. You can also see the full slide deck here.

Correctness vs. convenience

(Simon)

This morning, your VP pulled up a coding agent and asked a reasonable question:

How is traffic trending for our site?

The agent looked around the workspace, found a table that seemed relevant, wrote a SQL query against it, and returned a polished chart. Daily visits, it said, were down 64% over the last 90 days.

The variation looks a little tight, and the bend is a little sharp. Is there any possible reason we might see that bend other than a genuine change in site traffic?

It turns out that a version of Chrome released 45 days earlier fired the page-view event differently, so it was not aggregated correctly in the database. As people updated Chrome, it appeared that site visits were trending down. This was not even the table the data science team used to track site traffic.

But you are not there! Your VP sees this chart and takes it to the rest of the leadership team. They decide to restructure the organization and spend millions of dollars to reverse the trend.

A month later, somebody asks, “Could you recreate that chart? Let’s see how things are trending now.” The agent cannot find it. Many coding agents delete conversation histories after 30 days, and they often do data analysis in temporary files so they do not clutter the project directory. The source code for the analysis is long gone.

The coding agent offers to recreate the chart. It looks around the workspace, finds a table, and runs some SQL. The number was going up the whole time.

This is a fictional story, but we’e seen situations like this internally at Posit and at many of the organizations we work with. It is becoming normal to vibe-analyze data: ask an agent a question, receive a plausible answer, and move on without understanding how it was produced.

The tension between correctness and convenience is not new

Posit CTO Joe Cheng summarized the current moment this way:

AI has broadened the group of people who can convincingly do data analysis, but many may have no idea what data scientists go through to produce a trustworthy analysis.

Joe said this a month before the keynote, but he could have said it seven years ago. In 2019, the beverage company Conviviality disclosed that a spreadsheet arithmetic error had contributed £5.2 million to a £14 million forecasting mistake. When that “innocent spreadsheeting mistake” came to light, the business sank.

Or Joe could have said it 20 years ago, when a sign error in closed-source protein-modeling software sent a research field down the wrong path. A lab published landmark study after landmark study while other labs struggled to reproduce its findings. Only after another lab found a protein structure that was nearly a mirror image of one that the first lab had published did the first lab audit its source code. They found a negative sign where it did not belong and retracted five papers.

There were threats to correctness in data analysis long before AI. Posit’s stance has never been that people must sacrifice convenience for correctness. While preparing the talk, I found this quote in a blog post old enough to refer to itself as a “weblog”:

JJ was saying that a tool could be both correct and convenient. (By convenient, we do not mean 7-Eleven. We mean straightforward and intuitive.😜)

Can we take the same stance toward AI? Is it possible to make data analysis agents that are both correct and convenient for end users?

Why build AI tools at all?

(Sara)

This pull between correctness and convenience has been on our minds throughout the new, exciting age of LLMs. In 2025 and early 2026, AI started to feel really, really convenient for data analysis. That made us worry about correctness.

In August 2025, when we released Databot, our state-of-the-art exploratory data analysis agent, we did so under what was essentially a warning label. The release post was one of the first things I worked on after joining the AI team, and it gave me the chance to do something I think I am particularly good at: be pessimistic.

We were all really excited about Databot. It felt like flying through your data, gathering insights faster than you thought would ever be possible. It was precisely that convenience that worried us. People might trust it because they were having so much fun, even when it was wrong. So we wrote an entire article detailing basically every way we thought Databot might fail.

If you were at posit::conf(2025), you might remember Joe Cheng describing it as both the most exciting and the most dangerous software he had worked on in his 30-year career.

That raises a fair question, one we contemplate ourselves on a weekly basis: If AI causes all this chaos and makes all these mistakes, why are we doing this? Why involve ourselves at all?

There are many answers. We’ll focus on one.

Curiosity and exploration

Before joining the AI team, I taught data science. One thing that always struck me was what brought people with very different backgrounds into the field. The thing that united many of them was a sense of curiosity. Maybe they were curious about a scientific field, computers, statistics, or how R and Python themselves work. Data rewards that curiosity: There are datasets on almost everything.

But even as an undergraduate who knew some statistics and a little R, I often felt like I was looking at an ocean from above. The dataset was right in front of me, and I knew there was so much going on, but I just couldn’t see it.

As a graduate student, I learned the tidyverse and more about data science. As I got better at using those tools, I finally felt like I had what I needed to ask and answer questions about my data.

The right tools let us see below the surface. They enable that curiosity.

That same curiosity motivates our work now. We are curious about how these models work, how we can build things around them to make them work better, and, maybe most importantly, how we can turn them into tools that open new worlds of analysis. For us, AI is a continuation of work we have always done: finding new ways to explore data.

The models got better

I also wanted to spend some time on what has changed since August 2025, when we released that warning-label image. One major thing happened: The models got better.

About a year before the keynote, we ran an experiment to understand how well models interpret plots. We showed them plots based on a transformed diamonds dataset and asked them to describe what they saw.

The models gave answers like, “There is a strong positive relationship between carat and price.” That sounds plausible until you look at the plot, which shows the opposite. Behind the scenes, we had manipulated the data to reverse a canonical relationship, so larger diamonds were, unintuitively, less expensive.

We wanted to know whether the models could see what was in front of them and interpret plots that contradicted their expectations. A year ago, the answer was largely no.

In November 2025, even the best models of the time were abysmal at this task. They said what they expected to see instead of paying attention to what was actually happening in the plot.

We tried all sorts of interventions to improve the bluffbench scores, and absolutely nothing worked. Then we waited six months.

By May 2026, the major AI companies were releasing models that were noticeably better at the task. By September, the numbers had jumped dramatically: The models could interpret these counterintuitive plots.

The models got better. That does not mean data science is solved.

Models still make mistakes

After that experiment, we asked another question: Can models identify data-quality issues in visualizations? In bluffbench2, we again showed them plots and asked what they saw.

If you look carefully, there’s a suspiciously straight line through the cloud of points. If we really cared about this data, that’s something to investigate: Did something weird happen when the data was created? We wanted to know whether models would do the same.

It turns out they don’t really. Even the leading models were not very good at this task. They struggle to notice subtle data-quality issues.

But there’s another problem. Data analysis is not just you, plus a good model, plus your data. It also depends on context that is not necessarily in your CSV file, warehouse table, or JSON file.

All data is constructed. It all has context. That context might live in a data dictionary, a Markdown file, or a semantic view. Maybe it just lives in the head of a coworker who has been at the organization for 15 years, knows absolutely everything, and has never written a single thing down.

That context is not inherently inaccessible to models. We could give it to them. But it has to be in the right format, it has to be curated, and it has to itself be correct.

So the models have gotten better, but data analysis with AI is not solved. The question then becomes: How do we make AI-involved analysis correct?

How do we make AI for data analysis trustworthy?

(Sara)

Here’s a common thought about AI: It’s untrustworthy, but useful. To make it trustworthy, we need to add in a person.

Here’s a simple version of what that might look like. The agent or model does stuff, probably writes a bunch of code. A person then looks at that code and verifies, approves, or redirects as needed. That feeds back into the agent. This intuitively can feel really appealing. The agent gets to do what it’s good at, the person does what they’re good at, and there’s an expert there to keep everything from going off the rails.

And so it’s kind of tempting to apply this pattern everywhere. Any time the agent might make a mistake, we have a person there to clean it up and make sure nothing bad happens. We call this relatively simplistic view the slap a human on it approach.

In this approach, you don’t really think very much about what the person will actually do. How will they apply their expertise? What is the purpose of their involvement? How will we keep them from technically being in the loop but without actually applying their expertise?

I’m being a bit facetious, but this isn’t that far from how we wrote risk mitigation with Databot a year earlier. We said that Databot and LLMs were not at a point where users could abdicate responsibility. You still needed all of your data skills to catch errors, interpret results in context, and avoid being misled by confident but incorrect claims.

And all of that is still true! But we never said how this was supposed to happen. We assumed that if an expert was there, they would catch the mistakes.

But just adding a person doesn’t really guarantee a better result. Human–AI combinations do not reliably outperform the better of the human or AI working alone.

People also get tired of approving requests, and then they stop reading them. Think about the last time your coding agent showed you a command to approve. Did you carefully read it, or did you hit approve as quickly as possible and feel annoyed that it even bothered to ask?

Human decision-making is not fixed. How much you trust the system, how much you trust the people who built it, the timing of the information, your cognitive load, and how much your coworkers trust the agent can all influence the decision you make. Even if you are an expert who makes the right decision outside an interaction with an agent, adding the agent might change that decision.

So how do we design the entire system to produce correct work? How do we build trust and correctness into the agent itself, and design interactions with users that actually support their expertise?

That maps onto two principles we returned to throughout the talk:

1. Help the agent be correct.
2. Make it less bad when the agent is wrong.

Posit Assistant

(Simon)

Posit Assistant is Posit’s coding and data science agent. It is available in RStudio, Positron, and the terminal. When it is running inside an IDE, it works in the same R or Python session you’re using. You can use whatever model you want from whatever provider you have access to.

For the demo, I returned to one of my first experiences of seeing below the surface with data science. In an introductory statistics class, I analyzed flight data to understand whether I could book tickets that were less likely to be delayed. I used ggplot2 and dplyr, pushing data frames around and visualizing them.

I asked Posit Assistant to find an R package with Houston flight data and retrieve data from the previous year. It found anyflights, read its documentation, and generated the correct call.

Next, I asked it to grab data from the same time the previous year. The agent read the package documentation and so was able to write the code with the right arguments the first time.

We have seen that many coding agents have a superficial relationship with data quality, and we wondered whether we could do better. Posit Assistant proactively recommends cleaning the data and has a dedicated data-cleaning mode. It runs scratch code to look for missing values, outliers, and similar issues. Once it finds them, it surfaces questions to the user in an interactive dialog.

In the demo, the agent found missing values in a relevant column, then found some flights with departure delays of multiple days. I chose to keep both: Those outliers represented what really happened.

At the end of cleaning mode, the agent wrote a persistent file in the project directory to ingest and clean the data. When someone revisits the analysis, they can reproduce those steps.

Posit Assistant also shows plots inside the conversation. It is nice to be able to see them, but we also think it is necessary: Our evaluations show that agents cannot reliably interpret plots. When one carrier appeared unusually delayed, it checked the sample size and found only 32 flights, suggesting that we should not read too much into the pattern.

Once the analysis was complete, I asked the agent to turn it into a persistent Quarto report.

I have one more “little zoomy zoom”: The entire conversation cost five cents.

Part of our mission at Posit is to provide tools to people regardless of their economic means.

Posit Assistant is designed to be token-efficient and can use capable, inexpensive open-weight models such as GLM 5.3 Flash through Posit AI Pass. We spend a lot of time watching the open-weights model space for models on the Pareto frontier: capable of data analysis and orders of magnitude cheaper than frontier models.

Returning to the two principles, part of helping the agent be correct is, quite literally, asking nicely. We say, “Pretty please pay attention to data cleanliness. Pretty please be open to uncertainty when carrying out data analysis.”

We also design interactions around the user’s expertise: Cleaning mode asks about the data-generating process, plots remain visible, and the user shares the agent’s R or Python session.

Posit Assistant assumes that the user is a data scientist, analyst, or someone else who writes code and wants to work in an IDE, close to that code. But what if the user is not a data scientist? How do we help them get correct answers, too?

Introducing commons

(Sara)

Let’s return to our vibe-analyzing VP. I think it’s easy to say, “They just shouldn’t be doing this kind of analysis.” But let’s be on their side for a moment. They had a question, they wanted it answered, and so they’re going to reach for a tool that gives them an answer.

The problem is that they reached for the wrong tool and it gave them the wrong answer.

The data team already has vetted, maintained code that computes site traffic correctly. We call this trusted code. Trusted code might live in a package, Shiny app, Quarto document, report, or dashboard.

Instead of having the model write bespoke code from scratch every time someone asks a question, what if it could use that trusted code?

This is one of the core ideas behind a new open-source package that we’re excited to share with you all today. It’s called commons.

commons helps data scientists build trustworthy data agents for their collaborators. It is an open-source R and Python package built on the ellmer, chatlas, and shinychat stack.

(Simon)

Here is how the VP’s analysis works with a commons agent. When the VP asks, “How is traffic trending for our site?” the first thing the agent does is search for a trusted calculation. If it finds one that answers the question, it invokes that calculation directly.

The calculation returns a plot and a green shield indicating that the answer came from a trusted calculation. commons adds that marker deterministically; the agent itself does not control it.

What makes coding agents so convenient is that they are everything tools. They will write their own R, Python, or SQL code to answer a question. Trusted calculations cannot cover every question, so commons has a fallback path.

When no trusted calculation exists, the agent can use context authored by the data team. commons verifies any citation against that context before displaying its blue citation marker.

If there is neither a trusted calculation nor supporting context to cite, the agent can write code, but commons displays a yellow warning so the user knows to treat the answer cautiously.

Here’s a diagram of the various ways the agent can come up with answers and how the trust relationships are mapped.

So far, we’ve been talking about the VP’s experience with the commons agent. What is it like to work with commons as a data scientist? There are three main loops: build, deploy, and improve.

With data collection enabled, data scientists can review cases where the agent had to write its own code. If those cases share a pattern, they can add trusted code that moves future responses up the trust ladder, making the agent more correct over time.

Returning to our two principles, commons helps the agent be correct by letting it directly use trusted code. It makes mistakes less bad by telling the user when the agent did not directly use trusted code, and by moving responses up the trust ladder over time.

Other use-cases for commons

(Sara)

The VP example is business intelligence, but commons is not only for BI or vice presidents. It’s for any data person who wants to build an agent that gives correct answers to their collaborators.

We’ve made a sample clinical trials agent to highlight this functionality. Its data is simulated. The trusted code is a TLG catalog: code written and trusted by data people to work on this type of data and produce correct answers. You can ask it questions such as, “Plot Kaplan–Meier curves.”

It is still very bad to be wrong

(Sara)

It’s now so easy to ask any kind of agent a question about your data and get a wrong answer that looks completely plausible.

The problem is not just that the answer is wrong, and it’s also not just that you might be unable to reproduce it or have no idea how it arrived at the answer.

These are bad enough, but there’s another problem. If we become accustomed to, say, 15% of our numbers being wrong, we might lose trust in analysis itself and its ability to tell us things about the world, or become used to numbers just being a bit wrong all the time.

But correctness matters, especially in particular industries, and Posit has always built tools to support correct analysis. We do not think that standard should change just because AI is here.

But AI has expanded who can get answers from data. Now anyone can ask a question about their data. That changes how we need to think about the infrastructure for building correct, transparent, and reproducible agents.

With commons, a data team establishes which code and calculations it trusts and provides the organizational context the agent needs. The team can give that agent to someone who might otherwise perform a vibe analysis. That person keeps the convenience of asking questions in natural language, while the answers are grounded in the data team’s trusted work and can be traced and reproduced.

That is where data scientists and analysts come in. This infrastructure must be built by people who understand the data, calculations, and organization. commons helps them build it and make it available to others.

Looking forward

Looking forward, we have been experimenting with something called Canvas.

Canvas is a next-generation agent experience. It assumes that you might not always want to look at the code. That does not mean the code is not there when you need it, but you might not always want to work in an IDE.

This frees up real estate for expansive, new agent-collaboration interfaces. Canvas feels a little aggressively agentic to us, in the way Databot felt a year ago.

Recent past newsletters

• New releases from ellmer, shinychat, and commons
• You probably don’t want to fine-tune

Subscribe via RSS

We are thrilled to announce rig 0.11.0 (and 0.10.0), with lots of new functionalities: user mode R installations, R package and project management and much more. This is the first of three blog posts about the new rig release. This post is about managing R installations and the new user mode. The second post shows how rig can help with managing R packages, and the third focuses on project management.

Full changelog on the rig web site.

New Web Site

rig has a new web site at https://rig.r-lib.org! See this web site for installation instructions, including the new user mode install; reference documentation (also in rig help!), guides about larger topics and tutorials to get started.

User Mode R Installations

rig can now install and manage R installations without requiring administrative privileges. rig calls this user mode. In user mode, R installations are installed in the user’s home directory rather than system-wide. System-wide installations are still the default currently, and they are called admin mode.

You may have both user mode and admin mode installations on one computer, but each rig command runs in either user mode or admin mode. The default is admin mode. See below for how to change it. Use --admin or --user to pick the mode for a single command, e.g. rig ls --admin always lists admin mode installations, and rig ls --user always lists user mode ones.

Advantages of using user mode:

• No admin: no need for administrative privileges.
• All Linux: works on all glibc (from glibc 2.34) and musl (from musl 1.2) based Linux systems.
• Multiple patch versions: on macOS you can install multiple patch versions side by side.
• Convenience: no need to use sudo or an admin account to install and manage R.

User mode is quite new, though. It is much less tested than admin mode, and you may encounter bugs or unexpected behavior more frequently. On Linux, the generic distro-agnostic builds may be slower for numerical work than builds specifically compiled for the distribution.

User mode (admin mode as well, actually) is slightly different on each operating system. Here is a table about where rig stores its files on each OS in both modes.

You can call the new rig system dirs command to see where rig stores its various files:

❯ rig system dirs
Mode                  user
Architecture          arm64
R root                /Users/gaborcsardi/.local/share/rig/r
Binary dir            /Users/gaborcsardi/.local/bin
Config file           /Users/gaborcsardi/Library/Application Support/com.gaborcsardi.rig/config.json
Data dir              /Users/gaborcsardi/Library/Application Support/com.gaborcsardi.rig
Cache dir             /Users/gaborcsardi/Library/Caches/com.gaborcsardi.rig
Download dir          /var/folders/h9/6ct_py4s319fxt88dxn506l00000gp/T/rig-502
Logs dir              /Users/gaborcsardi/Library/Logs/com.gaborcsardi.rig
Project library root  (in-project, .rvenv/lib)

The same in admin mode:

❯ rig system dirs --admin
Mode                  admin
Architecture          arm64
R root                /Library/Frameworks/R.framework/Versions
Binary dir            /usr/local/bin
Config file           /Users/gaborcsardi/Library/Application Support/com.gaborcsardi.rig/config.json
Data dir              /Users/gaborcsardi/Library/Application Support/com.gaborcsardi.rig
Cache dir             /Users/gaborcsardi/Library/Caches/com.gaborcsardi.rig
Download dir          /var/folders/h9/6ct_py4s319fxt88dxn506l00000gp/T/rig-502
Logs dir              /Users/gaborcsardi/Library/Logs/com.gaborcsardi.rig
Project library root  (in-project, .rvenv/lib)

macOS

On arm64 macOS rig can install both arm64 and x86_64 builds of R. The latter ones need Rosetta to run. User mode has a different, simpler naming scheme than admin mode on macOS, matching Linux and Windows. This is an example list of user mode R installations:

❯ rig ls
* name          version    aliases
------------------------------------------
  3.6.3-x86_64  (R 3.6.3)
  4.0.5-x86_64  (R 4.0.5)
  4.1.3
  4.1.3-x86_64  (R 4.1.3)
  4.2.3
  4.3.3
  4.4.3
  4.5.3                    oldrel
  4.5.3-x86_64  (R 4.5.3)  oldrel-x86_64
  4.6.0
* 4.6.1                    release
  4.6.1-x86_64  (R 4.6.1)  release-x86_64
  devel         (R 4.7.0)
  devel-x86_64  (R 4.7.0)
  next          (R 4.6.1)
  next-x86_64   (R 4.6.1)

• The native (arm64) builds are named simply with the version number.
• R-devel is simply named devel and the next version of R (R-patched, R-alpha, etc.) is named next.
• The x86_64 builds are suffixed with -x86_64.
• You can use the release alias for the most recent version of R and the oldrel alias for the previous minor release branch. E.g. the R-release quick link starts the latest version of R.

Windows

On Windows rig installs CRAN’s R builds as a regular user in user mode. This installation writes the user’s registry settings instead of the system-wide registry settings.

The names of the R installations are the same as for admin mode. rig now supports installing x86_64 and aarch64 R builds on aarch64 Windows, and similarly to macOS, the non-native builds get a -x86_64 suffix:

PS C:\Users\Gabor Csardi> rig ls
* name          version    aliases
------------------------------------------
  4.4.3
  4.4.3-x86_64  (R 4.4.3)
  4.5.3
* 4.6.1                    release
  devel         (R 4.7.0)
  next          (R 4.6.1)

The new rig rtools command lets you manage Rtools installations. In user mode they are installed into the user’s roaming profile directory, and rig configures R and Rtools to work together correctly. On aarch64 Windows, you can install both x86_64 and aarch64 versions of Rtools.

PS C:\Users\Gabor Csardi> rig rtools ls
name  version  full-version   arch     path
------------------------------------------------------
40    4.0      4.0.3.0        x86_64   C:\Users\Gabor Csardi\AppData\Roaming\rig\data\rtools\40-x86_64
44    4.4      4.4.6459.6401  aarch64  C:\Users\Gabor Csardi\AppData\Roaming\rig\data\rtools\44
45    4.5      4.5.6768.6492  aarch64  C:\Users\Gabor Csardi\AppData\Roaming\rig\data\rtools\45

Linux

On Linux rig installs a portable (manylinux) R build in user mode. These builds are self-contained, generic glibc (or musl) builds of R. These builds are intended to work on a wide range of Linux distributions. However, they are not as battle-tested as the builds rig uses in admin mode.

On glibc systems rig also configures the manylinux repository for CRAN, that pairs very well with the portable R builds. These packages are self-contained and compatible with most glibc-based Linux distributions:

> getOption("repos")
                                                         P3M-manylinux
"https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/latest"
                                                                  CRAN
                                         "https://cloud.r-project.org"

Positron and RStudio configuration

rig automatically configures RStudio (when running rig add and rig default), so that the rig-default R version is also the default in RStudio. On macOS and Windows this is automatic. On Linux rig puts the rig binary directory (see the table above) on the PATH in user mode, and it is generally on the PATH in admin mode. This is enough to ensure that the rig-default R version is also the default in RStudio on Linux.

Positron does not have a generic default R version like RStudio does, but you can choose a default for each workspace. rig (in rig add and rig default) updates your Positron configuration (the current user’s config file) to make sure that Positron finds all user-mode R installations.

Switching to user mode

Call rig system user-mode to switch a previous setup from admin mode to user mode. This will reinstall your current R installations in user mode, and remove the admin mode installation. (But see its options to adjust this!)

See more about the migration at the rig homepage.

Portable Linux

Above you have seen how rig installs portable manylinux builds in user mode. It is also possible to install them in admin mode. This can be useful for Linux systems that rig does not have native builds for. To install a portable Linux build use --platform portable:

rig add --platform portable 4.6

Moreover, if rig does not support a Linux distribution natively, it will install the manylinux (or musllinux) builds instead, assuming that they are supported, even in admin mode. With this, most Linux distributions work automatically, in both admin and user modes.

Repository management

The rig release improved the rig repos subcommand substantially. These are the biggest changes.

P3M by default

rig now configures Posit Public Package Manager (P3M) as a default repository, on all platforms except aarch64 Windows. (Because P3M would serve incompatible x86_64 binaries here.) This is because we found P3M more reliable and because P3M includes older package versions and has more extensive metadata.

Nevertheless you can opt out with rig add --without-repos=p3m ... at installation time, or with rig repos setup --without-repos=p3m at any time.

Custom repositories

You can now add custom repositories to your rig configuration using rig repos add <name> <url>. For example:

rig repos add myrepo https://myrepo.example.com

You can then turn these (and also the built-in) repositories on or off using rig repos enable and rig repos disable.

Improved repository list

The output of rig repos available is now more informative and easier to read. Type rig repos available <reponame> to get more information about a repository.

❯ rig repos available
8 repositories

Name              Default   Type       Title
-----------------------------------------------------------------------------
P3M               depends   built-in   Posit Public Package Manager
P3M-manylinux     depends   built-in   Posit Package Manager manylinux portable packages
RHUB              no        built-in   R-Hub repositories
r-universe/cran   depends   built-in   R-universe CRAN mirror
r-universe/bioc   no        built-in   R-universe Bioconductor mirror
CRAN              yes       built-in   The Comprehensive R Archive Network
CRAN-archive      depends   built-in   CRAN archive
Bioconductor      no        built-in   Open source software for Bioinformatics

Use `rig repos available <name>` to see a repository's URLs.
`depends`: a default only on some platforms, architectures or R versions.

❯ rig repos available r-universe/cran
r-universe/cran (1 URL)
R-universe CRAN mirror

R-universe's mirror of CRAN. The only repository serving arm64 Windows binary
packages.

Default      only on platforms matching aarch64-*-mingw32

URL          https://cran.r-universe.dev
Platforms    windows, *-mingw32
Archs        aarch64

Repository status

Use rig repos status to check the status of all enabled repositories.

❯ rig repos status
6 repositories of R 4.6.1, index bin/macosx/sonoma-arm64/contrib/4.6

name              ping   status        types              updated            url
-----------------------------------------------------------------------------
P3M             601 ms   ok            source, win, mac   -                  https://packagemanager.posit.co/cran/latest
BioCsoft        233 ms   ok            source, win, mac   2026-10-01 17:08   https://bioconductor.org/packages/3.23/bioc
BioCann         120 ms   source only   source, win, mac   2026-08-01 16:49   https://bioconductor.org/packages/3.23/data/annotation
BioCexp         111 ms   source only   source, win, mac   2026-09-15 20:32   https://bioconductor.org/packages/3.23/data/experiment
BioCworkflows   111 ms   source only   source, win, mac   2026-08-01 16:39   https://bioconductor.org/packages/3.23/workflows
BioCbooks       120 ms   source only   source, win, mac   2026-08-01 16:25   https://bioconductor.org/packages/3.23/books

`ping` is the time the repository took to answer for the index above.
`types` is what the R installation's `repositories` file declares.
`source only`: this repository has no index for this platform and R version.

Other improvements

Avoid unneeded reinstalls

rig add now does not reinstall an R version if it is already installed. Use --reinstall to force a reinstall.

.exe quick links on Windows

On Windows rig now uses .exe quick links instead of .bat files. .bat files have a lot of issues with passing arguments, .exe files work much better.

Run R with R on Windows

The new rig system fix-r-alias subcommand deletes the R alias from PowerShell, so you can now use R to start R.

rig is now signed on Windows

Thanks to the SignPath Foundation, the rig executables and the rig installer are all signed now.

rig system blas

The new rig system blas command lets you manage the BLAS/LAPACK library used by R on macOS.

Update and uninstall

Use rig self update to update rig itself, and rig self uninstall to uninstall it. These commands only work if you installed rig using the install script. If you installed it with a package manager or ran the installer manually, you have to use the same package manager or uninstall it manually.

Your feedback is welcome!

We would love to hear your thoughts, suggestions, and any issues you encounter while using rig. Please use the issue tracker for bug reports and feature requests, and the discussion forum or Posit community for general questions and discussions.

Acknowledgments

Huge thanks to everyone who contributed to rig 0.10.0 and 0.11.0: @achubaty, @AdaemmerP, @AdrienLeGuillou, @Adrilihan, @Andryas, @bashirhamidi, @benyamins, @biocyberman, @Bisaloo, @cderv, @CGMossa, @danielloader, @dkczk, @eitsupi, @elendil95, @eliocamp, @EllaKaye, @etiennebacher, @frosforever, @gdevenyi, @ggrothendieck, @grantmcdermott, @gvelasq, @hadley, @jabenninghoff, @jameslairdsmith, @jennybc, @jeroen, @jfin4, @John15321, @jonbry, @JosiahParry, @kalenkovich, @kenahoo, @kieran-mace, @klmr, @krlmlr, @lotum-david-j, @malcolmbarrett, @mcanouil, @mhurtado13, @MilesMcBain, @mitsuki5284, @mns-nordicals, @morphatic, @Nerwosolek, @noamross, @paluigi, @robjhyndman, @rumichaska, @SaintRod, @sammieephung, @sda030, @ShixiangWang, @t-kalinowski, @tylermorganwall, @venpopov, @vikasrawal, @wzbillings, and @zivankaraman.

I came into the internship as a computational biologist. In my PhD research, I work with single-cell sequencing, genomics, and multi-omics data, and with the public databases and identifiers that come with them.

Across different projects, I kept running into the same problems:

• Biological datasets are getting enormous.
• The information needed to interpret them is scattered across many databases.
• Identifiers are surprisingly inconsistent.
• The same API and data-access logic gets rewritten again and again.
• Even when excellent public datasets exist, there can still be a huge gap between the data being available and a researcher being able to use it comfortably.

Those gaps became the theme of my summer.

How do we make increasingly large and complicated biological datasets genuinely usable for researchers?

Making enormous biological datasets explorable

One of the projects I am most excited about is Tahoe Explorer (source).

Tahoe-100M contains more than 100 million single-cell perturbation profiles. That scale is scientifically exciting, but it creates a practical problem: you cannot treat 100 million observations like a normal dataframe inside an interactive application.

I wanted researchers to be able to answer basic questions before committing to a large analysis. Which cell lines are represented? Which drugs were tested? How much coverage exists for the combination I care about? What do we know about the genomic background of those cell lines? And once I find what I need, how do I retrieve only that part of the dataset?

Tahoe Explorer lets researchers move through drugs, cell lines, samples, genes, coverage, and cell-level metadata without first downloading and loading the entire resource. For the larger data, queries are pushed down to DuckDB, which returns only the rows or summaries the current view needs.

I integrated additional information from resources such as DepMap and Cellosaurus, including variant information for the cell lines. That makes it possible to think about perturbation response alongside the genomic context of each cell line.

The Subset builder tab then turns exploration into something reproducible. Users can define the experiment they care about and generate R or Python code for retrieving that subset later.

Another feature of the app is the built-in chat assistant. It can help researchers reason about Tahoe, identify useful filters, interact with supported parts of the app, and finally build those reproducible subset recipes.

What I like most is that the assistant lives inside the app. It can use tools over the data and help operate the workflow. To me, that is a much more interesting direction for AI in scientific software.

The Tahoe app solved one type of scaling problem: accessing and understanding a dataset that is much larger than the application itself. One layer later, the same issue came back, with the visualization itself as the bottleneck.

plotomics and Plotomics Live (source) came out of that bottleneck.

plotomics is a visualization library for computational biology with a shared TypeScript rendering core and wrappers for R and Python. Its 17 components cover embeddings, heatmaps, volcano plots, networks, oncoplots, genomic views, spatial data, survival analysis, and other common biological visualizations. Of those, 15 ship in R, Python, and JavaScript; the two genome browsers are JavaScript and Python only.

For large visualizations, the browser can draw with WebGL or Canvas. Numeric data can also move to the frontend as binary buffers instead of being serialized into huge JSON payloads.

The visualization logic exists once. The R, Python, and JavaScript wrappers all talk to the same rendering engine.

I built Plotomics Live to explore how far that model could go inside Shiny.

The app contains 26 biological visualizations, built from those 17 components with several of them used more than once, across single-cell data, spatial transcriptomics, genomics, networks, perturbation data, and other common workflows. Every one of them renders two ways, and an engine toggle puts the GPU-accelerated React component beside the server-rendered ggplot2 image so you can compare them directly.

One page, for example, interactively renders more than half a million real single-cell observations in the browser.

Plotomics Live is where I worked out what Shiny can look like when R remains the analytical engine and the browser does more of the work it is good at.

Connecting biological information that lives everywhere

Scale was only one recurring problem. The other was fragmentation.

A lot of computational biology does not involve one database or one algorithm. It involves assembling an answer from many different resources.

Variant interpretation is a good example. If I am reviewing a variant, I may want information from ClinVar, gnomAD, Ensembl, UniProt, AlphaFold, Open Targets, dbNSFP, ProtVar, and several other sources.

Variant Reviewer (source) brings those sources together in one reactive workflow.

A researcher can start from a gene, a variant, or both, and the app combines clinical significance, population frequency, prediction scores, gene constraint, protein domains and 3D protein structure.

But building Variant Reviewer surfaced another problem. Every external biological service behaves differently: its own identifiers, its own failure modes, its own rate limits. One might return a clean “not found” response while another throws an error. And one slow or unavailable service should not break the entire application.

Once I started solving those problems in one app, it became apparent that I should not keep solving them separately.

Building the infrastructure once

Five packages grew out of problems that kept appearing across the applications.

biobouncer

biobouncer handles biological identifier validation. Gene symbols change. Ontology identifiers have different namespaces. Variants can be syntactically valid but biologically meaningless. Public databases each have their own identifier conventions.

biobouncer provides a common layer for validating these inputs using pattern checks, cached resources, remote validation, and existence checks. It also has implementations across R, Python, and TypeScript backed by the same conformance data.

If the same identifier moves through an R pipeline, a Python analysis, and a web interface, I want “valid” to mean the same thing everywhere.

biohttp

biohttp handles the repetitive infrastructure around external APIs. Retries, throttling, caching, batching, timeouts, circuit breaking, and structured errors should not need to be rebuilt in every scientific application.

It also makes an important distinction between a service successfully returning no biological result and the service itself failing. That sounds small until an application depends on several external databases at once.

bioclients

bioclients sits on top of that transport layer and provides R clients for 29 biological services. Ensembl, UniProt, gnomAD, Open Targets, ClinVar, AlphaFold, and the rest each get a client that understands the structure and meaning of what they return.

Network requests and response parsing are separated so parsers can be tested against stored responses without requiring a live API.

The separation is intentional:

• biohttp handles how we talk to a service.
• bioclients handles what that biological service returns.

plotomics

plotomics is the exception in this list. I described it above, because it came out of one specific problem before I was thinking about shared infrastructure at all. It belongs here anyway, for the same reason as the rest: the rendering layer only had to be built once.

biocohort

Before APIs and visualization even matter, most omics projects have another problem: keeping the study organized. Subjects, samples, assays, species, and the manual corrections made along the way often end up spread across spreadsheets and scripts.

biocohort provides a validated study representation for keeping those relationships together. The same manifest can describe multiple assay types and organisms, generate pipeline sample sheets, and preserve corrections that would otherwise disappear inside preprocessing code.

This one is particularly close to my own research because these small bookkeeping problems become very expensive once a project grows.

This shift from app-specific code to reusable infrastructure was the biggest change in how I approached the internship. Instead of asking, “How do I make this app work?”, I started asking, “Which part of this problem will the next app also need?”

From retrieving data to synthesizing evidence

Once those pieces became reusable, I could build higher-level research workflows on top of them.

Gene List Builder (source) came from another task I have done manually many times: starting with a disease and assembling a defensible list of associated genes.

The application resolves the disease to an ontology term, queries multiple gene-disease resources, normalizes the results, removes duplicates, and produces a ranked list using transparent and adjustable source weights.

The evidence comes from the underlying databases, the scoring is visible, and the provenance remains available. An optional AI layer can then help with curation after that deterministic evidence-gathering step.

GeneScout (source) takes the same idea further.

It acts as an evidence-review workbench for evaluating candidate genes in a disease context. Its deterministic layer resolves genes, retrieves public evidence, keeps citations attached, scores the evidence, and applies caveats. An optional agent can then synthesize what was retrieved and suggest follow-up directions.

Both apps rest on the design principle I came away from the summer caring about most:

AI can help interpret scientific evidence without needing to be the source of the evidence.

Turning analyses into tools researchers can actually explore

I built several more focused applications around common genomics workflows.

Recount Explorer (source) provides an interactive entry point into recount3, allowing researchers to browse uniformly processed RNA-seq studies, inspect quality metrics, explore expression and PCA, and export data, without writing any code.

DE Explorer (source) makes differential-expression results interactive, moving from a PCA of sample-level structure to a volcano plot, a filterable results table, and a heatmap of the genes you select.

Signature Scoring (source) summarizes expression profiles into pathway-level scores and lets researchers compare those scores across groups before drilling down into the genes driving a pathway.

Drug Perturbation (source) explores connectivity between gene-expression signatures and reference perturbations, including potential mimics and reversers across different cellular contexts. Its reference panel is synthetic, built over the TCGA-BRCA gene space.

Genome Explorer (source) places recurrent variants into an interactive genomic view and lets users move from cohort-level patterns to individual loci.

These five are deliberately narrower than the applications above. An analysis can end in a tool: a thin Shiny layer turns a computational result into something the researcher who understands the biology can actually explore.

Working in open source

I had worked on open-source software before, but working inside Posit’s Open Source group changed how I thought about building research software.

Code review was where a lot of the interesting work happened.

I spent much more time thinking about API design, failure modes, backwards compatibility, and what another developer would experience after I stopped actively working on a project.

That distinction became very clear over the summer:

Making something run once is different from making something other people can depend on.

I got to move well outside the R layer I knew best. Across the summer I worked with R, Python, JavaScript, TypeScript, React, WebGL, Shiny internals, and newer work around shinyreact, which the Shiny team introduced in Introducing shinyreact at the end of September.

Starting the internship at Open Source Work Week in Boston made the whole experience even better. Meeting everyone in person at the beginning made the later remote collaboration feel much more natural.

I am very grateful to Barret Schloerke, Carson Sievert, Joe Cheng, the rest of the Shiny team, and everyone across Posit who provided feedback, answered questions, challenged ideas, or helped me understand another part of the stack.

I learned a lot from being able to build freely while surrounded by people who know these tools from the inside.

Next for these projects

The internship ended, but I do not really think of these projects as finished. They are open source, and many of them solve problems I still encounter in my own research. I hope researchers use them, find things I did not anticipate, and help shape where they go next.

The applications and supporting packages are collected in the Shiny Showcase: Bioinformatics repository, with source code, documentation, examples, and citation information for the individual projects. The live gallery links every app to a running deployment you can open in a browser.

I presented this as a talk in August 2026. The deck covers the same projects in slides, and its source is public.

If you work in computational biology, genomics, or research software, I would genuinely love to hear what is useful and what is missing.

Try an app, use one of the packages, or open an issue if something breaks or could work better. Pull requests are welcome. Or tell me about the research-software problem you keep solving manually.

A lot of this work started exactly that way. I noticed recurring problems in my own research that felt harder than they should be, and I tried to build the tools I wished I already had.

Want to catch up on talks? While we prepare the videos for YouTube, all session recordings are available now on the event portal:

• Register / log in at conf.posit.co
• Go to “Schedule”
• Select any session and click “View recording”

Announcing the winners of the Posit Impact Awards

We were thrilled to launch the inaugural Posit Impact Awards to celebrate stories of measurable, meaningful change across our community. At posit::conf(2026), we were honored to announce our eight winners, each receiving a conference pass to join us in Houston!

A huge congratulations to all our winners, and a heartfelt thank you for the incredible work you do (and for sharing it with us)!

• Explore their stories in the 2026 Posit Impact Awards blog post and join us at the Data Science Hangout to hear from other Impact Award winners and nominees featured in the next few weeks.

Open Source updates from posit::conf(2026)

Introducing commons

commons 0.1.0 introduces a new framework for building trustworthy self-service data analysis agents in R and Python. The package implements a three-tier trust labeling system that transparently indicates whether agents invoke trusted code directly, write new code justified by vetted context, or provide untrusted answers. Built on Posit’s LLM stack (ellmer, chatlas, shinychat), commons enables teams to convert existing analytical code into AI agent capabilities while maintaining transparency about code sources.

• Learn more about commons 0.1.0.
• Join Sara & Simon’s virtual webinar on October 28th to learn more about commons. Register here.

Quarto Hub

Quarto Hub is a new hosted platform from Posit. In Quarto Hub, you can create, edit, comment on, and publish your Quarto projects (single documents, presentations, websites) collaboratively and in real time.

• Watch Carlos Scheidegger’s talk, “Quarto Hub: Collaboratively edit, create, and share documents”, on the event portal.

skiLift and skiPatrol

Posit has taken over maintenance over two R packages that provide comprehensive tools to work and collaborate within Snowflake’s data platform and ML ecosystem:

• skiLift: a DBI-compliant Snowflake connector written in R, that authenticates and communicates via the Snowflake SQL API (REST).
• skiPatrol: an R interface to Snowflake’s ML platform: model registry, feature store, experiments, model monitoring, and container services.

Learn more in the R, meet Snowflake: Introducing Posit’s skiLift and skiPatrol Packages blog post.

Even more open source updates

Beyond all the exciting conf news, September was packed with major product updates and community highlights across the board!

At the database layer

ggsql 0.5.0: Readers, Writers, and Beta status

ggsql is a tool that implements a grammar of graphics for SQL, enabling ggplot2-style data visualization directly from database queries. ggsql 0.5.0 reaches beta status with major improvements to database connectivity and rendering capabilities. The release introduces hybrid-reader mode for read-only connections with cache support, replaces the Vega-Lite renderer with a custom writer supporting PNG, JPEG, SVG, and PDF output, and adds rich text support through extended markdown. New features include caption support, minor breaks on scales, and true variable line aesthetics with gradients.

• Read more in the ggsql 0.5.0: Readers, Writers, and Beta status blog post.

orbital 0.7.0

orbital enables the running predictions of tidymodels workflows inside databases. orbital 0.7.0 and tidypredict 1.2.0 massively expand in-database prediction capabilities for tidymodels workflows. The release adds 27 new model/engine combinations including discriminant analysis, naive Bayes, neural networks, SVMs, partial least squares, and ensemble methods. tidypredict now functions as a developer toolkit with new generics for programmatic use, and improved error messaging guides users when probability predictions aren’t available.

• Read more in the orbital 0.7.0 blog post.

AI-powered R tools

ellmer 0.5.0

ellmer makes it easy to use large language models (LLM) from R. ellmer 0.5.0 brings major improvements for working with large language models in R. New file handling functions reduce token costs by efficiently managing documents. The release adds citation tracking from web search tools, token counting for cost prediction, and streaming structured output support. Developer features include tool_context() for accessing request metadata and new lifecycle hooks for building agents.

• Read more in the ellmer 0.5.0 blog post.

vitals 0.4.0

vitals is a framework for large language model evaluation in R. vitals 0.4.0 brings significant performance improvements and new agent comparison capabilities for LLM evaluation in R. The release includes claude_code() and codex() helpers for benchmarking custom ellmer-built agents against leading coding agents, plus vitals_log_read() for loading log files back into resumable Chat objects. Log files are now ~4x smaller and the log viewer is substantially faster.

• Read more in the vitals 0.4.0 blog post.

Our stuff is so Shiny

Check out all the major work done by the Shiny team in September!

Introducing shinyreact: React UI backed by a Shiny server

shinyreact enables developers to build Shiny applications with React-based UIs while keeping Shiny’s reactive computation on the server. The package provides two primary React hooks for client-server communication, gives access to the entire npm ecosystem of React components, and includes AI Agent Skills for building and converting apps.

• Read more in the Introducing shinyreact: React UI backed by a Shiny server blog post.

Shiny for Python 1.8

Shiny for Python 1.8 introduces in-memory server testing without browsers, enabling developers to test reactive logic with pytest using a mock connection. The release adds ui.page_html() for using complete HTML documents from bundlers like Vite, and session.allow_reconnect() to maintain live sessions after dropped websocket connections. Additional improvements include deprecation of ui.output_text_verbatim() in favor of clearer naming, reactive value destruction fixes, and multiple bug fixes for downloads, navsets, and data frames.

• Read more in the Shiny for Python 1.8 blog post.

Multiple tables, saved conversations, and take-home dashboards: querychat R 0.4.0 and Python 0.9.0

querychat facilitates safe and reliable natural language exploration of tabular data, powered by SQL and large language models (LLMs). querychat R 0.4.0 and Python 0.9.0 introduce multiple table support with automatic joins, persistent conversation history across sessions, and the /handoff command for exporting chats as downloadable Quarto dashboards, Shiny apps, or marimo notebooks. The release builds on shinychat’s full-page layout with editable messages and file attachments, adds YAML-based data dictionaries for context, and integrates with pins boards for chatting with pinned data.

• Read more in the Multiple tables, saved conversations, and take-home dashboards: querychat R 0.4.0 and Python 0.9.0 blog post.

Complete chat applications in shinychat: R 0.5.0 and Python 0.7.1

shinychat provides a Shiny toolkit for building generative AI applications like chatbots and streaming content. shinychat R 0.5.0 and Python 0.7.1 deliver complete chat application capabilities with conversation history, message editing and branching, greetings, file attachments, and slash commands. The new page_chat() layout provides full-window interfaces with integrated navigation, tool displays, citations, and artifact previews. Features include persistent conversation storage, search and organization tools, streaming responses with thinking panels, and toolbars for contextual actions.

• Read more in the Complete chat applications in shinychat: R 0.5.0 and Python 0.7.1 blog post.

posit::conf(2027) will be in Seattle, WA from Sept 13-15

Save the date: We’re heading back to the Pacific Northwest for posit::conf(2027)! Subscribe to “Events” to get notified when registration opens.

In the meantime, join us for our ongoing virtual events:

• Data Science Hangout for casual conversations with leaders in the data space
• Data Science Lab for live coding sessions with practitioners building cool things with code

Hope to see you there!

shinyreact splits a Shiny app along a clean line. The Shiny server does reactive computation. The UI is a React client that you own. shinyreact is the bridge between them, and it ships zero UI components of its own.

You can install it from CRAN or PyPI:

install.packages("shinyreact")

pip install shinyreact

shinyreact is new, and so is the way of building Shiny apps it proposes. We intend to keep the API small, but expect it to evolve as we learn from early adopters.

Shiny + React?

For most Shiny apps, defining the UI in your app.py or app.R file allows you to construct a complete, production-ready app in just a few lines of code.

The trouble starts when the design asks for something Shiny and bslib don’t have: a unique layout, richer interaction, or a component from a non-Bootstrap design system. At that point, Shiny hasn’t had the right tool for the job.

React is that tool, for three reasons:

• Ecosystem. React is the most widely used UI library on the web. Design systems, charts, tables, and maps are all one npm install away.
• The right model. React components are functions of state, which fits Shiny’s reactive model naturally. When the server sends new data, the UI re-renders efficiently.
• AI assistance. LLMs have trained on an enormous amount of React code. Ask a frontier agent for a UI and it will produce better React than it will bespoke Shiny UI. This aligns with Shiny’s goal that app developers should never be required to write low-level HTML or JavaScript themselves.

Later in the post, we’ll discuss a genomics app that renders a 584,000-cell UMAP on the GPU from a plain Shiny server. First, the basics.

Old Faithful with shinyreact

Here is the classic Old Faithful histogram app as a shinyreact app:

library(shiny)
library(shinyreact)

# Set up the page UI using shinyreact
ui <- page_react()

server <- function(input, output, session) {
  x <- faithful$waiting

  breaks <- reactive({
    seq(min(x), max(x), length.out = input$bin_count + 1)
  })

  # Use `reactive_output()` to send data to the client
  output$dist_data <- reactive_output({
    bins <- hist(x, breaks = breaks(), plot = FALSE)
    list(breaks = I(bins$breaks), counts = I(bins$counts))
  })
}

shinyApp(ui, server)

import numpy as np
import pandas as pd
from shiny.express import input
from shinyreact import reactive_output, set_react_page

# Set up the page UI using shinyreact
set_react_page()

x = pd.read_csv("faithful.csv")["waiting"].to_numpy()


@reactive_output
def dist_data():
    breaks = np.linspace(x.min(), x.max(), input.bin_count() + 1)
    counts, _ = np.histogram(x, bins=breaks)
    return {"breaks": breaks.tolist(), "counts": counts.tolist()}

Two things are different from a traditional Shiny app.

1. The UI is one line. page_react() (or set_react_page() in Shiny Express) serves the React client that lives in your app’s www/ directory. There’s no sliderInput() or plotOutput(). The www/ directory contains the static assets for the React app: ui.js and ui.css (when available).
2. The output is data. reactive_output() has no matching UI function. This is a new concept for the Shiny ecosystem! renderPlot() sends an image for plotOutput() to place. reactive_output() sends plain JSON, here the histogram’s breaks and counts. Like any render function, reactive_output() re-executes each time its reactive dependencies change. The server sends facts and React decides how to present them.

Now the client:

// src/ui.tsx (which compiles to www/ui.js)
function App() {
  const [binCount, setBinCount] = useShinyInput("bin_count", 30);
  const bins = useShinyOutputValue("dist_data", null);

  return (
    <main className="layout">
      <label htmlFor="bin_count">Number of bins:</label>
      <input
        id="bin_count"
        type="range"
        min={1}
        max={50}
        value={binCount}
        onChange={(e) => setBinCount(Number(e.target.value))}
      />
      <Histogram bins={bins} />
    </main>
  );
}

If you’ve written React before, this is an ordinary component. Histogram is whatever you like: a hand-written SVG, a charting library, or a component from your design system. The only shinyreact-specific parts are two hooks:

• useShinyInput() works like React’s useState(), except that the value is also sent to the server as input$bin_count (or input.bin_count() in Python). Calling setBinCount() updates the UI and triggers the server’s reactive graph.
• useShinyOutputValue() reads the value of a reactive_output(). When the server recomputes dist_data, the component re-renders with the new data.

Those two hooks cover the vast majority of apps.

IDs and JSON are the contract

The client and server share exactly two things: IDs and JSON values. If you write the client in TypeScript, each hook takes an optional type for its value, such as useShinyInput<number>("bin_count", 30), and your editor will then flag a mismatch that Shiny.setInputValue() never could.

Here is the full round trip for the Old Faithful app:

1. The client calls useShinyInput("bin_count", 30), which sends {"bin_count": 30} to the server.
2. The server reads input$bin_count, runs its reactive graph, and computes dist_data using reactive_output().
3. The client receives the dist_data result as {"dist_data": {"breaks": [...], "counts": [...]}}, and useShinyOutputValue("dist_data") hands it to React.

That narrow boundary is what makes a shinyreact app easy to reason about. The server doesn’t know or care how the histogram is drawn, and the client doesn’t know how the bins are computed. Each side can be reviewed, tested, and rewritten independently, whether a person or an agent wrote it.

When you need more, a few other hooks are available. useShinyOutputStatus() tells you when an output is recalculating so you can show a skeleton, and useShinyMessageHandler() receives one-off messages pushed from the server with send_message(). See the JavaScript API reference for the full list.

You don’t have to write the React yourself

A fair reaction to all of this is, “but I chose Shiny so I wouldn’t have to write JavaScript!”. That’s still the goal. What’s changed is that today’s AI agents are very good at writing React, far better than they are at writing custom Shiny UI, because there is so much more React in the world for them to learn from.

With shinyreact, your job is to own the server, which is where your data and domain logic live, and to describe and review the UI. To make that concrete, both packages ship Agent Skills:

• shinyreact-build-app scaffolds a new shinyreact app from a description.
• shinyreact-convert-app opens an existing Shiny app in a browser, describes what it does in plain English, and then rewrites the UI in React against the same server.

The day-to-day loop is familiar. You edit src/ui.tsx (or ask an agent to), the build step writes www/ui.js, and you reload the running Shiny app to see the change. The server side is unchanged: runApp() or shiny run, exactly as before.

Node.js isn’t required, since a client can be a single www/ui.js file with no build step. However, we do strongly recommend it as it gives you a proper development environment: a build step gets you TypeScript, linting, and formatting.

Keep what you already have

shinyreact doesn’t ask you to throw away the rest of the Shiny ecosystem.

• Existing outputs. renderPlotly(), render.data_frame, and other render functions work as before. Drop a <ShinyOutput id="..." /> into your React tree, and the output’s JavaScript and CSS dependencies are delivered automatically.
• Modules. ShinyModuleProvider namespaces hook IDs to match a server-side module.
• Bookmarking. URL and server bookmarking seed the initial values of useShinyInput().

Testing at every layer

Because the client and server only share IDs and JSON, each layer can be tested on its own. The server is the layer most Shiny developers care about, and it needs no browser at all. Use shiny::testServer() in R, or the new local_server pytest fixture in Shiny for Python 1.8: set inputs and assert on the JSON that comes out.

def test_histogram(local_server):
    local_server.set_inputs(bin_count=10)
    data = local_server.get_output("dist_data")
    assert len(data["counts"]) == 10

The other layers have their own tools:

• The client. Ordinary JavaScript unit tests, with whichever test runner you (or your agent) prefer.
• The wire. wire_tap() for shinytest2 and WireTap for Playwright record the JSON crossing the websocket during a browser test. That gives you an end-to-end assertion on what the client actually sent and what the server actually returned, without reaching into the rendered DOM.
• The behavior. Each example app ships a FEATURES.md: a nested list where every leaf is one checkable claim about the app, written in plain English. A person can read it as a spec, and an agent with a browser can walk it and turn each claim into a deterministic check against the running app.

The testing article covers all of them.

In the wild: Plotomics Live

Over the summer, Shiny intern Samuel Bharti built a collection of bioinformatics Shiny apps. Most of them are plain Shiny and bslib. The one that reached for shinyreact did so because the visualizations demanded it.

Plotomics Live (source, DOI) is a 26-page gallery of GPU-accelerated genomics visualizations, from oncoplots to a one-million-point Xenium spatial view and an interactive 584,000-cell UMAP. Large data skips JSON entirely and moves as compact binary typed arrays straight to the GPU. Because React owns the component, a new selection updates the data in place without re-mounting the visualization or reallocating GPU buffers.

In Samuel’s words:

R stays the analysis engine, React becomes the visualization layer, and shinyreact removes the custom JavaScript bindings, manual message passing, and serialization code that used to sit between them.

What’s next

We’re working on two directions next:

• Embedding React components in existing apps, so you can adopt shinyreact one piece at a time without porting a whole app.
• Wrapping shinyreact in your own package, so you can build a component once and ship it the way bslib ships its components.

Learn more

• Documentation: posit-dev.github.io/shinyreact
• Source and example apps: github.com/posit-dev/shinyreact
• posit::conf(2026) talk slides: Beyond Bootstrap: Building Custom Shiny UI with React

Give shinyreact a try, and please let us know what you build and what breaks.

install.packages("querychat")

pip install -U querychat

This release adds several headline features, including support for multiple tables, data-dict.yml, a full-page chat layout, support for pins, and a new /handoff command. It also builds on shinychat’s recent momentum. As a result, querychat gets chat features like history and file attachments basically for free. querychat_app() provides a quick and useful way to start chatting with data and getting bespoke ggsql visualizations, and it now uses shinychat’s page_chat() for a full chat app experience.

See the R release notes and the Python changelog for the complete list, including a few changes for existing apps if you’re upgrading.

Full-page chat layout

querychat_app() / QueryChat.app() now put the chat front and center (built on shinychat’s page_chat()), leaving more breathing room for things you create within the chat.

library(palmerpenguins)

querychat_app(penguins)

from querychat import QueryChat
from palmerpenguins import load_penguins

qc = QueryChat(load_penguins(), "penguins")
qc.app()

A view of the actual data is always accessible via the data source drawer on the right-hand side. In the case of multiple tables, you’ll see the active table¹, as well as other available tables below it.

The new page() method brings this same full-page chat layout to your own apps. Your users get the chat front and center, and you can still add custom views on other pages, in the drawer, or in the sidebar.

Learn more about building custom apps in R and Python.

qc <- QueryChat$new(penguins, "penguins")
ui <- qc$page("Penguins Explorer")

from querychat.express import QueryChat
from palmerpenguins import load_penguins

qc = QueryChat(load_penguins(), "penguins")
qc.page("Penguins Explorer")

Conversation history

Another major improvement is persistent conversation history (mostly thanks to shinychat). In addition to starting new chats and returning to previous ones, conversations now persist across page reloads and timeouts. As a result, it is now much more difficult to lose your progress.

Also, now that shinychat supports editable messages, canceling responses, file attachments, and more, querychat does too.

Multiple tables

querychat now supports multiple tables in a single chat instance. If those tables reside in a singular source, like a database, you can add them all in one fell swoop with the add_tables() method.

library(querychat)

qc <- QueryChat$new()
qc$add_tables(db, c("customers", "orders", "order_items"))

from querychat import QueryChat

qc = QueryChat()
qc.add_tables(db, ["customers", "orders", "order_items"])

querychat’s query and visualization tools handle joins across these tables, so a single question can span all of them. To write a query like the one below, the LLM first needs to know what’s in each table: column names, types, and value ranges. So it starts by fetching the schema of each table it needs (“Fetch schemas”), then generates the query with that metadata in mind.

In a custom app, the new table() method gives your server code reactive access to any table, including whatever filters the LLM has applied to it. That means you can keep building your own plots and views in Shiny, and your users can drive them just by chatting.

output$order_price <- renderPlot({
  orders_tbl <- qc$table("orders")
  # LLM can perform filter queries on $df()
  orders_df <- orders_tbl$df()
  hist(orders_df$price)
})

@render.plot
def _():
  orders_tbl = qc.table("orders")
  # LLM can perform filter queries on .df()
  orders_df = orders_tbl.df()
  plt.hist(orders_df["price"])

Provide context: data-dict

querychat does its best to gather context from the data itself. When the LLM fetches a table’s schema, it gets whatever metadata querychat can compute from the data. That’s a good start, but in practice it often isn’t enough. Column names can be cryptic, coded values need decoding, and nothing in the data says what “active customer” means to your business or how tables relate. In the example above, the LLM had to infer from column names alone that orders.customer_id points to customers.id.

A data dictionary is how you fill in what the data can’t say about itself. It’s a YAML file that follows the data-dict spec. Alongside plain-English descriptions, it has its own fields for column types, allowed values, keys, and the relationships between tables. This is now the preferred way to describe your data:

tables:
  customers:
    description: One row per customer.
    columns:
      - name: acquisition_channel
        type: enum
        values: [organic, paid_search, social, referral]
        description: How the customer first found us.
  orders:
    description: One row per order.
    columns:
      - name: customer_id
        type: number(id)
        constraints: [foreign_key]
  order_items:
    description: One row per item in an order.
    columns:
      - name: price
        type: number(quantity)
        description: Item price in USD.

relationships:
  - description: Each order belongs to one customer.
    cardinality: many-to-one
    join: orders.customer_id = customers.id
  - description: Each order has one or more items.
    cardinality: many-to-one
    join: order_items.order_id = orders.id

Pass it in as data_dict = "dictionary.yml" (R) / data_dict="dictionary.yml" (Python). When the LLM fetches a table’s schema, any column you’ve documented comes straight from your dictionary, with nothing left to infer. querychat only computes metadata from the data for the columns your dictionary doesn’t cover.

Extract insights: /handoff

Over the course of a conversation, querychat tends to produce a pile of results, some more useful than others. The useful ones deserve to live on in a reproducible artifact that doesn’t depend on the chat app.

That’s the idea behind the new /handoff slash command. It’s available in every querychat app, with no setup required. When a user types /handoff into the chat input, a wizard opens where they select the results that matter, choose an output format (e.g., Quarto, marimo, Shiny, Jupyter), and add any presentation instructions for the LLM to follow when it generates the handoff document.

When the user finishes the wizard, the handoff document’s source code streams into a code editor, where they can revise it by hand or with AI assistance. A download button then gives them a zip bundle with the handoff document, a README file, and the data sources (if they’re small enough).

Chat with pinned data

querychat can now chat with data pinned to a pins board. Pass the board and the pin name, and querychat reads the pin (parquet, CSV, JSON, RDS, and more) and uses its title, description, and tags as the starting data description:

library(pins)
library(querychat)

board <- board_connect()

querychat_app(board, "my_pin")

pip install "querychat[pins]"

import pins
from querychat import QueryChat

board = pins.board_connect()

qc = QueryChat(board, "my_pin")
qc.app()

For more control, such as setting the table name used in SQL, use the new PinSource class directly. Multiple pins, or pins mixed with ordinary data frames, also work together in one chat. Everything is materialized into a shared DuckDB connection behind the scenes, so the LLM can join and filter across all of it. See the data sources guide for R and Python for details.

A few changes for existing apps

This release also includes a handful of breaking changes, mostly around how querychat manages connections and bookmarking now that history is built in. If you’re upgrading, skim the R NEWS or Python CHANGELOG breaking-changes sections before you do.

Learn more

• querychat documentation (R) — full guides on data sources, context, tools, and deployment
• data-dict — the data dictionary spec querychat now reads
• ggsql — the grammar of graphics for SQL that powers querychat’s visualizations
• shinychat (R) — the chat UI toolkit querychat builds on
• chatlas (ellmer) — the underlying LLM tool-calling libraries
• Source on GitHub — issues, discussions, and contributions welcome

Acknowledgements

We thank everyone who contributed to these releases, for opening issues, submitting pull requests, and providing feedback: @gadenbuie, @hadley, @iainwallacebms, @iamYannC, @jnhyeon, @kolabearafk, and @thisisnic.

We are absolutely thrilled to announce the release of ggsql 0.5.0, the first beta release of ggsql since the initial release back in April. While this release brings a lot of core improvements, the beta label marks the maturity of the project more than any specific feature in this release. That being said, the features included are exciting so let’s tell you all about them.

A new reader paradigm

ggsql is modular by design with reader modules taking care of interacting with the various backends where your data live. We want ggsql to not be a monolith but instead be able to integrate itself into whatever data setup you or your organization uses, and readers is our way of making this happen.

We already showed this flexibility in the first release that included both a DuckDB, a SQLite, and a generalized ODBC reader. Since then we have added support for the new and more performant ADBC driver spec. Between this and ODBC it’s fair to say that all widely used databases are accessible, though work still remains to take full advantage of each database’s strengths.

One thing that was missing from our initial design was support for read-only database connections. ggsql heavily caches calculations on the backend using TEMP TABLE but this requires write access which you may not have. To fix this use-case ggsql 0.5.0 now includes a hybrid-reader mode. In this mode the initial data query is read from the backend database and then immediately transferred to an in-memory database of your choosing (e.g. DuckDB or SQLite) for further processing. This obviously helps in the cases where you don’t have write access to the backend, but can also speed up execution if your backend is not optimized for analytical queries. On the flip-side, it does incur an overhead when the data being plotted is huge.

You can turn on the hybrid mode by passing a cache-compatible reader to the --cache arguments in the CLI, e.g. 

ggsql exec --reader odbc://... --cache duckdb` "VISUALIZE ..."

or by prefixing it to the reader url separated by a + in the kernel:

-- @connect: duckdb+odbc://...
VISUALIZE ...

We are excited by what this new setup offers, both in allowing more users to use ggsql, but also when looking ahead and thinking about interactivity in ggsql graphics where you might rightfully not want to hit your database backend every time a user hovers over your plot somewhere.

A new writer enters the stage

While the improvements in the reader setup may be largely invisible to the user, another foundational change will surely command attention. ggsql has since its inception relied on Vega-Lite for the actual rendering. This meant that ggsql converted the query into a json spec and handed it off to the Vega-Lite JavaScript library for further processing. This choice meant that we could iterate quickly on the core of ggsql without getting bogged down by the complexity of actual rendering. From the start we knew that Vega-Lite was not meant to be the only writer in ggsql, but as development progressed it became clear that it was unsuitable in general and had to be completely replaced. Thus, I have spent my summer creating a new writer, which in time will replace Vega-Lite completely. The benefits of this are already many (and we will go through them below), but the effort will also continue to pay dividends as we are more free to support the features we deem relevant without relying on underlying support from another library.

File type galore

Outputting a JSON spec for further JavaScript processing is reasonable if you target a live HTML document but otherwise a user would generally expect an image of some sort. With the new writer we are finally able to provide this out of the box.

And we haven’t stopped at PNG…

The new writer is capable of rendering PNG, JPEG, TIFF, WebP, SVG, and PDF documents out of the box, hopefully serving all your export needs. The SVG output is optimized for further editing in vector graphics software, while the PDF output is optimized for stable rendering across machines and thus automatically embeds the glyphs used in the document.

Output type is automatically deduced from the file extension in the CLI, so you can for instance create a PDF version of a plot directly with

ggsql exec --output plot.pdf "
VISUALIZE bill_dep AS x FROM ggsql:penguins
DRAW density"

In Positron, the new formats are available as export options from the plot pane.

A native viewer

While not an output format per se, the new renderer also allows to output to a native window for previewing, directly from the CLI. This functionality can be accessed with the new view command to ggsql, e.g.

ggsql view "
VISUALIZE bill_dep AS x FROM ggsql:penguins
DRAW density"

Plotting capabilities enabled by the new writer

While the different output modes are the direct effect of a writer that can render to more formats, the new writer also provides pure, dataviz bliss by raising the ceiling for what can be plotted. This was our main reason for moving away from Vega-Lite and the reason why we can’t keep the old writer around forever — it is simply not capable enough. We will continue to reap the benefits of this in the future, but we have already included some in this release:

Rich text support through extended markdown

Text is important in data visualizations. This position should come as no surprise to those who have followed my years of trying to improve the font and text rendering capabilities of R. Just because we have moved to SQL doesn’t mean that I have given up on that quest. Thus, the new writer has full support for markdown, along with modern font support including font features and font variations. As the latter two are still not reachable from ggsql we’ll focus on the markdown support here.

By default, markdown parsing is turned on in all titles and labels, but not in break labels. Once we settle on a theming system this will all be configurable, though. Lastly, markdown parsing can also be turned on for the text layer by setting parse => true. The markdown is heavily inspired by the flavor I developed in the R marquee package. This means that everything you expect from standard markdown is available, plus a number of enhanced features:

• Italic (*), Bold (**), Underline (_), Strikethrough (~~), _Subset (~), ^Superset (^), code (`), Links ([text](url))
• Headings 1 — 6 (# — ######)
• Quote blocks (>)
• Code blocks (```)
• Bullet lists and numbered lists (- or * for former, 1. for latter)
• Horizontal lines (* * *)
• Images (![alt text](url))

From marquee it gains the support for ad-hoc coloring and sizing through the custom span syntax: {.red I'm colored red} and {#0000FF I'm colored blue} allows for named and hex-encoded colors to be set on a piece of text, and {.40 I have big letters} lets you set a font size on the fly. The customization provided by the writer goes even deeper but again, the bottleneck right now is the theming system, not the renderer. Let’s see it all in action:

VISUALIZE species AS fill, species AS x FROM ggsql:penguins
DRAW bar
SCALE fill TO ('steelblue', 'goldenrod', 'forestgreen')
LABEL 
  title => '![](logo.png) Distribution of penguin (*Pygoscelis*) species',
  subtitle => 'This plot focuses on 3 species: {.steelblue *P. adeliae*}, {.goldenrod *P. antarcticus*}, {.forestgreen *P. papua*}'

Support for captions

A small but clear deficiency of Vega-Lite was the lack of support for captions. Captions are often used to provide source information for the data, so that it travels along with the visualization:

FROM ggsql:penguins
VISUALIZE species AS fill, bill_dep AS x, bill_len AS y 
DRAW point
LABEL 
  caption => 'Data source: [Gorman KB *et al.*](www.doi.org/10.1371/journal.pone.0090081)'

A render-specific side note. If you export the above to either SVG or PDF the included link will be live and take you to the article.

Minor breaks are now supported

Visible, but ignored in the two preceding examples is the appearance of minor breaks in the output. This concept doesn’t exist in Vega-Lite and we have thus waited for a new renderer to turn it on. The interface is much like the major breaks: provide a count or an array of exact locations for the minor break to appear:

FROM ggsql:penguins
VISUALIZE species AS fill, bill_dep AS x, body_mass AS y 
DRAW point
SCALE x
  SETTING minor_breaks => 3
SCALE y
  SETTING minor_breaks => (3200, 4200, 5200)

True variable line aesthetics

The old renderer, like ggplot2, supported varying width and color along a line by chopping it up in small segments. This pragmatically works, but the only way it can look correct is to use round end caps which both forces round corners and destroys transparency due to segment overlap. In the new renderer I’ve gone out of my way to make this look correct, by converting the line into a mesh and rendering it as triangles. This means that gradient and variable width lines are now fully supported at the low level and not through any hacks:

VISUALIZE Date AS x, Temp AS y FROM ggsql:airquality
DRAW line
  MAPPING Ozone AS stroke, Wind AS linewidth

(not endorsing the above visualization in any way)

Looking forward

We have covered a lot of ground in the 5 months or so since the first release, but we have much to add still and we can’t wait. Without really going into details with any of them, I see 3 major efforts leading up to ggsql exiting beta, along with the myriad of smaller enhancements that are sure to come along:

1. Support for table output. As recently showcased in my posit::conf(2026) talk we are actively working on bringing the table formatting features from gt great-tables. This will allow you to format publication quality tables directly from your SQL query and make pure (gg)SQL driven reports an obvious option for many use cases.
2. Plot composition. One plot is good, many plots are (sometimes) better. Inspired by what the R patchwork package has done for ggplot2 plots we want to allow composition of plots, tables, and perhaps more. Who knows if one day a single SQL query can create a beautiful dashboard. The good news is that the new renderer has all of the composition logic built in already (faceting is done through that API), so much of this is a question of landing the right syntax (something we take extremely seriously).
3. Interactivity. For certain tasks, interactivity is a superior solution (though not for all). ggsql does not aim to be a D3-like playground for highly customized interactive visualization, but it does want to allow visualizations to be interactive to the extent the syntax allows without collapsing. I’m really looking forward to this design work.

These are the main focus for us, but the writer switch has itself offered so much low-hanging fruit for us to pick, that there will be plenty of user visible additions over the next year.

pip install -U shiny

The highlights: * test_server() runs your app’s server logic in memory so you can test it without a browser, * ui.page_html() lets a complete HTML document (say, the index.html your JS bundler emits) be the app’s UI, and * session.allow_reconnect() lets the browser reconnect to a live session after a dropped connection.

Full details are in the Shiny for Python changelog.

In-memory server testing

Until now, testing a Shiny for Python app meant one of two things: unit-test the pure functions your server calls, or spin up the app and a browser with Playwright and test end to end. There was nothing in between for the part that actually makes an app a Shiny app: the reactive graph.

New in v1.8, shiny.testserver.test_server() runs a server function, Express app, or shiny.App against a mock connection. There’s no browser and no network server, and your test stays a plain synchronous function: test_server() drives the event loop for you, so you never write async def or await. (If your test already runs inside an event loop, use test_server_async() instead.) Set inputs, let the reactive graph settle, and assert on outputs, all in an ordinary pytest test. It’s the Python counterpart to Shiny for R’s testServer().

For the common case, an app.py next to your test file, the new local_server pytest fixture is the whole setup:

def test_doubling_app(local_server):
    local_server.set_inputs(name="Ada", n=10)

    assert local_server.is_ok
    assert local_server.get_output("greeting") == "Hello, Ada!"
    assert local_server.get_output("doubled") == "20"

    # Inputs you don't name keep their values, so `name` is still "Ada".
    local_server.set_inputs(n=21)
    assert local_server.get_output("doubled") == "42"

local_server is the in-memory sibling of the existing local_app fixture, but function-scoped: a session remembers the inputs set so far, so each test gets a fresh one.

Each output also reports how it turned out, which is what to reach for when the assertion isn’t about equality:

def test_reports_a_bad_value(local_server):
    local_server.set_inputs(n=-1)

    assert local_server.is_ok is False
    failed = local_server.get_output("doubled")
    assert failed.status == "error"
    assert "must be positive" in failed.error

Modules work too. Reach into one with its namespaced id ("counter-n"), or take a scope and use the bare ids the module’s own code uses:

def test_counter_module(local_server):
    counter = local_server.make_scope("counter")
    counter.set_inputs(n=7)
    assert counter.get_output("label") == "n=7"

And when you need something other than app.py, call test_server() directly as a context manager. It accepts a path, a shiny.App, or a bare server function (handy for testing a module’s server function on its own):

from shiny.testserver import test_server


def test_the_other_app():
    with test_server("other_app.py") as ts:
        ts.set_inputs(n=10)
        assert ts.get_output("tripled") == "30"

The bundled shiny-for-python Agent Skill has a new test-server topic as well, so coding agents reach for in-memory server tests instead of hand-built sessions or a browser when only server logic needs checking.

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

Bring your own HTML document

Shiny’s ui.page_*() functions build the HTML document for you. That’s usually what you want, but sometimes you already have one: the index.html a JS bundler like Vite emits, a hand-written template, or a page produced by another tool entirely.

ui.page_html() takes that document, as a string or a Path, and serves it as-is. Shiny’s own HTML dependencies (plus any you pass via extra_deps=) are inserted where you put a placeholder <meta> tag, and their files are served by the app:

<!doctype html>
<html>
  <head>
    <meta name="shiny-dependency-placeholder" content="">
    <script type="module" src="/assets/index.js"></script>
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>

from pathlib import Path

from shiny import App, ui

app_dir = Path(__file__).parent


def server(input, output, session):
    ...


app = App(ui.page_html(app_dir / "index.html"), server)

If your document marks the spot differently, set deps_replace_pattern=. And because ui.page_html() returns a regular UI object, you can return it from a UI function (App(ui=lambda request: ...)), which is what bookmarking requires.

In Express, pass the document to ui.page_opts(html=). The whole app is routed through ui.page_html(): top-level UI markup is dropped, since the document already is the page, but any HTML dependencies it brings along are kept.

This is the Python counterpart to Shiny for R’s shinyApp(ui = htmlTemplate("index.html", document_ = TRUE)) with attachDependencies().

Session reconnection

When the websocket between the browser and the server drops, Shiny shows the “Disconnected from server” overlay and the client gives up. If your hosting environment keeps sessions alive after a client disconnects (Posit Connect and Shiny Server both can), that’s a missed opportunity: the session is still right there.

session.allow_reconnect(True) tells the client to instead show a countdown dialog and try to reconnect. On success, the browser sends its current input values back to the server, and the server recalculates outputs and sends them down again. Users pick up right where they left off after a flaky Wi-Fi blip or a laptop lid closing.

from shiny import App, ui


def server(input, output, session):
    session.allow_reconnect(True)
    ...


app = App(ui.page_fluid(...), server)

Pass "force" to attempt the reconnect anywhere, which is useful for exercising the countdown UI on a local shiny run server (where the attempt starts a fresh session rather than resuming the old one). This is the Python counterpart to Shiny for R’s session$allowReconnect().

Deprecation: ui.output_text_verbatim()

ui.output_text_verbatim() now emits a ShinyDeprecationWarning. It has long been a leftover from Shiny for R’s verbatimTextOutput(), and Python has had clearer names for both jobs for a while:

• For code or other monospaced text, use ui.output_code() with @render.code.
• For plain text, use ui.output_text() with @render.text.

The matching Playwright controller, playwright.controller.OutputTextVerbatim, is deprecated alongside it; use playwright.controller.OutputCode instead.

Other improvements

A few more changes worth a quick mention. The full list is in the changelog:

• Closing a session no longer destroys the reactive values and calcs created in it. Since v1.6.1, refreshing the page while an @reactive.extended_task was in flight could raise DestroyedReactiveError once it settled. Values and calcs are now left readable at their last value and reclaimed by garbage collection; effects are still destroyed on close.
• ui.input_slider() and ui.update_slider() now encode datetime.date values as UTC midnight, matching Shiny for R, so they no longer shift by a day when the server runs in a timezone ahead of UTC. Naive datetime.datetime values round-trip unchanged too.
• @render.download_button and @render.download_link now honor @output(id=). Previously the URL and the registered handler disagreed on the id, so clicking the control returned a 404.
• @expressify and @render.express no longer fail with RuntimeError: Failed to find function '...' in AST when another decorator has changed the function’s __name__, a pattern often used to give each @render.express function in a loop a unique output id.
• Navsets created with an id now use it as their data-tabsetid, so tab panes get stable DOM ids instead of ones built from a random integer. This makes the markup reproducible and easier to target from custom CSS and JavaScript. (Thanks, @pevolution-ahmed!)
• ui.show_offcanvas() now accepts the id of an ui.offcanvas() panel already in the UI, matching ui.hide_offcanvas() and ui.toggle_offcanvas(). It also accepts bare tag content, wrapping it in a new anonymous panel.
• @render.data_frame now renders data frames whose column names are empty or not strings; column ids are positional and never derived from the name.
• @render.ui outputs inside a ui.popover() or ui.tooltip() without a title= no longer get stuck showing “recalculating”.
• shiny run --app-dir <dir> <app> now honors --app-dir for Shiny Express apps.
• ui.input_task_button(type=None) no longer drops the class its input binding needs, so the button is bound and clicking it works.
• playwright.controller.Offcanvas gains open(), loc_trigger, loc_title, loc_footer, and expect_title(), expect_footer(), and expect_placement().
• playwright.controller.InputSelectize no longer clicks the page body to close its dropdown, so a test can’t accidentally fire the app’s own click handlers.

In closing

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

Acknowledgements

A big thank you to all the folks who helped make this release happen by opening issues and contributing code:

@ambevill, @arabidopsis, @bealdav, @chernojagne, @ChidiebereNjoku, @cpsievert, @danieldebondt-tf, @drewe7192, @eeshsaxena, @ErdaradunGaztea, @FBruzzesi, @gadenbuie, @jat255, @jubilee2, @karangattu, @kramerrs, @MichielNoback, @mykolaskrynnyk, @nightcityblade, @nvelden, @pevolution-ahmed, @schloerke, @shawnboltz, @tjpalanca, @weichisyu, and @xiruizhao.

Last week, three packages in Posit’s open-source AI stack shipped significant releases. We introduced commons 0.1.0, and ellmer and shinychat both received substantial updates. These releases are part of a broader effort to make it as easy as possible to build modern chat applications in R and Python.

In this newsletter, we’ll take a quick tour of what’s new.

Introducing commons

commons, a new framework for building trustworthy self-service data analysis agents in R and Python, is now on CRAN. Read the full announcement here.

The Python package is currently in a pre-release beta stage, with more features arriving over the next few weeks.

If you’re a data analyst, data scientist, statistical programmer, or other data practitioner, you likely have extensive domain knowledge and a collection of trusted code that you already use in analyses, apps, reports, and packages. The core idea behind commons is that we can leverage this trusted code to improve an agent’s correctness.

A commons agent first searches for a trusted calculation. If it finds one that can answer the user’s question, it can run that vetted code and the answer is deterministically marked as verified.

If it doesn’t find a trusted calculation, the agent searches trusted context before writing custom R, Python, or SQL. The answer is either given a citation or marked as “untrusted,” depending on whether the agent provides a verified citation that supports its approach.

The model doesn’t decide how trustworthy its answer is. commons assigns each label deterministically based on the analysis path taken by the agent.

commons also ships with an agent skill to help you create a commons agent and functions for analyzing your users’ conversations.

shinychat v0.5.0 (R) and v0.7.1 (Python)

shinychat v0.5.0 for R and v0.7.1 for Python bring together more of what you need to build a complete chat application. Several of these shinychat updates also made commons possible!

Read the full blog post here. There are many more updates worth checking out.

page_chat()

Use page_chat() instead of the bslib page_*() functions when you want the chat to be the center of your application. page_chat() creates a full-window, chatbot-oriented layout with support for navigation pages, conversation history, an artifact drawer, and more.

Conversation history

Conversation history is enabled by default when you use chat_server() in R or Chat(client=...) in Python, allowing users to start a new conversation, switch between saved conversations, search them, rename them, and delete them.

Readable tool calls and citations

This shinychat release also includes several improvements for understanding how a model arrived at its response.

One such improvement is readable tool calls. By default, related tool calls are grouped into compact, single-line “activity rows”, keeping them from overwhelming the conversation. You can still inspect the individual tool calls by expanding a row.

shinychat also displays citations returned by providers’ built-in web-search and web-fetch tools.

ellmer 0.5.0

ellmer 0.5.0 is now on CRAN. ellmer makes it easy to work with LLMs from R.

Read the full announcement here. Many of the features made available in this release are also available in recent releases of chatlas, ellmer’s sibling package in Python.

Citations

When a model uses a supported built-in web tool, ellmer now returns and displays the provider-supplied citations. This works with claude_tool_web_search(), claude_tool_web_fetch(), google_tool_web_search(), and openai_tool_web_search(), helping you identify the sources behind the model’s answer.

chat <- chat_openai()
chat$register_tool(openai_tool_web_search())
chat$chat(
  "What is the most recent version of ellmer on CRAN? Look it up."
)
#> The most recent CRAN release of **ellmer** is **version 0.5.0**, published
#> **September 4, 2026**.
#> ([cran.r-project.org](https://cran.r-project.org/package%3Dellmer))[1]
#>
#> Sources
#> [1] CRAN: Package ellmer: https://cran.r-project.org/package%3Dellmer

Tokens and costs

Managing tokens and costs is an important part of working with LLMs.

Ever want to know how many tokens an input will take before sending it? For supported providers, you can now use chat$token_count() to estimate input token use. Instead of actually sending the request to the model, it sends the request to the provider’s token-counting API.

chat <- chat_openai(model = "gpt-5.6-luna")
prompt <- content_pdf_file("example-document.pdf")
chat$token_count(prompt)

#> [1] 252

This estimates only the tokens used by the input and does not predict the number of output tokens, so it won’t represent the total round-trip count.

Companies frequently release new models and change their prices. Use the new function models_update_prices() to download and cache the latest pricing data from the ellmer GitHub repo. Cost estimates reported by token_usage(), Chat$get_cost(), Chat$get_tokens(), and printed Chat objects use this data.

Send files to the model

It’s often useful to send files as part of a chat. You can now send CSV, Markdown, code, and other text-based files to a model with content_document_file() and content_document_url(). For large files or files reused across multiple turns, if you’re using chat_openai(), chat_anthropic(), or chat_google_gemini(), use chat$file_upload() instead. It uploads the file once and returns a reference for $chat(). This avoids repeatedly sending the file and reduces token usage and cost.

Solid improvements for custom agents

Taken together, these releases make it easier to build more complete custom agents. ellmer manages model interactions in R, shinychat provides the user-facing chat interface, and commons adds a framework for data analysis agents that builds upon these two.

We’re hootin’ and hollerin’ to share commons, an R and Python package that helps data scientists build trustworthy data analysis agents.

The package is built on ellmer, chatlas, and shinychat, Posit’s open source LLM stack. You can use whatever model you want from any of the providers supported by those packages with it.

To install the R package, run:

install.packages("commons")

To install the Python package from PyPI, run:

pip install commons

The Python package is currently in a pre-release beta stage, but you can install and play around with it today, with more features arriving over the next few weeks.

Design philosophy

AI agents for data analysis can range from overly cautious and narrowly correct to wildly and confidently incorrect. commons provides a framework for you to design more trustworthy analysis agents by providing them with access to existing trusted code, while still allowing them enough flexibility to answer novel, realistic questions.

If you are a data analyst, data scientist, statistical programmer, or other data practitioner, you likely have a deep understanding of your problem domain and a collection of trusted code you depend on for your analyses and use to create apps, reports, and packages. The core idea behind commons is that we can improve an agent’s correctness by giving it the right access and documentation to run this code that you have already vetted.

When answering questions, commons agents first search through a pool of trusted code. If the agent finds an appropriate piece of trusted code, it can invoke it directly, and its response will be tagged with a green shield icon . If it doesn’t, it will search through relevant context before writing its own SQL, R, or Python. If the agent can find trusted context that justifies its approach, it can provide a citation to it at the end of its answer, which will be deterministically checked by commons. Otherwise, the answer is marked with a small warning label .

Notably, the agent itself does not decide how to label a response. commons instead labels answers deterministically, based on the path the agent takes to get it to its answer.

Get started

To get started with the R package, check out the introductory vignette. The package ships with an agent skill to help you hook your trusted code and context up to the agent.

The Python package (although still in beta) is based on the same ideas, and the resulting apps will look very similar regardless of whether you use R or Python—they literally share the same CSS! Check out the Python package site to learn more.

shinychat is a toolkit for building complete, conversation-centered chat applications with Shiny. The R package pairs with ellmer, and the Python package pairs with chatlas. Install the latest releases from CRAN or PyPI:

install.packages("shinychat")

pip install -U shinychat

We cover a lot in this post, and there’s even more in the releases. See the R release notes and the Python changelog for the complete list of changes, including a few changes for existing apps if you’re upgrading.

Build a chat application

A useful chat application needs more than a text box and a streaming response. Your users need a way to return to an earlier conversation, start a new one, correct a question, compare answers, inspect sources, and see what the model is doing when it calls a tool. They may also need to upload a file, open a preview, or move between the chat and the rest of the application.

shinychat gives you sensible starting points for building that experience. Pair it with ellmer in R or chatlas in Python, and you can get a working chat app running with little setup. The chat application model has three layers:

1. page_chat() gives you a full-window chat app with space for navigation, history, tools, and supporting content.
2. chat_ui() lets you place chat wherever it fits best in your application.
3. chat_server() for R or Chat(client=...) for Python connects your app to an ellmer or chatlas client and enables the integrated chat features.

When you want a fully custom experience or need a model client other than ellmer or chatlas, the lower-level pieces are still available for you to assemble yourself.

Start with page_chat()

When chat is the center of your application, use page_chat(). It gives your users a full-window experience with a chat home, navigation pages, sidebars, toolbars, conversation history, and an artifact drawer. Users can move to a settings or sources page while their conversation keeps working and streaming. The Get started guide for R and the Page chat guide for Python walk through the full layout.

Create a chat app

Build a shinychat application starts similarly in both languages:

library(shiny)
library(shinychat)

ui <- page_chat(title = "Assistant", id = "chat")

server <- function(input, output, session) {
  client <- ellmer::chat_openai(
    system_prompt = "You are a helpful assistant."
  )

  chat_server("chat", client)
}

shinyApp(ui, server)

from chatlas import ChatAnthropic
from shinychat.express import Chat, page_chat

client = ChatAnthropic(system_prompt="You are a helpful assistant.")
chat = Chat(id="chat", client=client)

page_chat(title="Assistant", id="chat")

With just a few lines of code, you’ll have a working chat app backed by a live LLM. Passing a client to chat_server() in R, or to Chat() in Python, does all the hard work for you, fulling connecting your app to the model client and giving you a complete multi-user chat application¹.

For a personal chat UI you can use while you develop locally, pass an ellmer client to chat_app() in R, or a chatlas client to Chat(client=...), and then call .app() in Python.

Welcome users

When you’re app opens, don’t leave your users hanging with an empty chat canvas, gree them with chat_greeting() (R, Python)!

Greetings can be used to explain the application, set expectations, and give users a useful first step before they write their first message. By default, they disappear when the user starts chatting, but you can set persistent = TRUE in R or persistent=True in Python to keep one at the top of the conversation history.

Greetings are written in markdown and can even provide actionable suggestions. Users can click a suggestion to fill the input, ready to edit before sending, or send it immediately.

## Welcome!

What would you like to do?

* <span class="suggestion submit">Summarize my data</span>
* <span class="suggestion">Create a plot</span>
* <span class="suggestion">Explain this code</span>

You don’t have to greet your users with the same message every time, you can use LLMs to generate fresh custom greetings. To learn more, we’ll point you to the chat_greeting() documentation pages (R, Python), but it’s worth noting that dynamic greetings can stream into the chat like any other response.

Return to earlier conversations

One of the biggest features to arrive in this release is conversation history, giving your chat app the ability to save and return to previous conversations. It will also persist the current conversation across page reloads and other disconnects, virtually eliminating the possibility of losing your progress. As usual, when you connect shinychat with an ellmer or chatlas client, conversation history is wired up and enabled for you!

Save conversations

The history drawer lets users:

• Start a new conversation.
• Switch between saved conversations.
• Search conversations.
• Rename a conversation.
• Delete a conversation.
• Return to the conversation that was active when they last opened the app.

shinychat generates a short title once the conversation has enough content. Users can replace that title, and title generation never overwrites a manual rename.

• Rename
• Search

You can history_options() in R or HistoryOptions in Python to configure the conversations that shinychat saves. The main options are:

• restore_mode, which controls which conversation opens when a user returns to the app:
  • "browser" is the default. It returns that browser to its most recent conversation without changing the URL.
  • "url" puts the active conversation ID in the address bar, so users can bookmark or share a specific conversation.
  • "bookmark" restores the conversation with the rest of the app state when your app uses Shiny server bookmarking.
• store controls where shinychat saves conversations. Use "memory" for local development or tests, or "file" to save them on disk.
• title controls how the automated conversation titles are generated.

For example, this configuration stores conversations on disk and puts the active conversation ID in the URL:

history <- history_options(
  restore_mode = "url",
  store = "file"
)

chat_server("chat", client, history = history)

from shinychat import Chat
from shinychat.types import HistoryOptions

history = HistoryOptions(
    restore_mode="url",
    store="file",
)

chat = Chat("chat", client=client, history=history)

On Posit Connect, conversation history is included with the platform and is enabled automatically when you provide a model client. The default configuration uses Connect’s persistent storage and scopes conversations to the authenticated user. That gives every user a private conversation history without an additional history service or per-user setup.

In every restore mode, shinychat keeps the transcript in its configured store instead of putting the full conversation in the URL.

Edit a message and compare answers

Editing a message now creates a new conversation branch. When a user edits and resends an earlier message, shinychat forks the conversation at that point: the original question and its later messages remain on one branch, while the edited question begins another. Users can move between the answers with the branch controls in the message.

• Branch 1
• Branch 2

Branches help when a prompt is almost right or when a model takes an unhelpful direction, and they make comparing answers easy without starting over. And they are part of the saved conversation, so users return to their place in the conversation after a reload.

Add content and controls

When chat is part of a larger application, your users still need access to filters, settings, sources, and results. page_chat() gives you a place to put those alongside the conversation: a drawer for results, toolbars for controls, and offcanvas panels for settings you would rather keep off screen.

Artifact drawer

chat_drawer() gives you a place to show previews, rendered reports, tables, plots, or other bits of Shiny UI next to your chat. Your users can keep the conversation visible while they inspect a result.

See the drawer documentation for R or Python for the full API. The complete application example combines a drawer with the rest of the application layout.

Toolbars

Your app may need a Help button that works on every page, while the chat home needs an action that’s only relevant when you’re looking at the conversation. page_chat() gives each action a home through scoped toolbars, built on the toolbar components that bslib and Shiny shipped earlier this year.

If you want an action to follow users through the whole app — pass it to toolbar_global. Put chat-home actions in toolbar in page_chat(), and give a secondary page its own toolbar through chat_nav_panel(). toolbar_input puts related actions below the message box.

See the R get started guide or the Python Page chat guide for the full toolbar API.

Offcanvas panels

page_chat() pairs offcanvas panels with secondary content, such as an answer-length slider or citation setting, and a toolbar button can open an Answer settings panel from any page:

Complete application

As your app grows, page_chat() can grow around the conversation. You can add secondary pages and a sidebar for filters or other app UI and the application menu keeps those options available on narrow screens.

The following example brings the toolbars, sidebar, navigation, and drawer together.

ui <- page_chat(
  "Research assistant",
  id = "chat",
  toolbar = bslib::toolbar(
    bslib::toolbar_input_button(
      "clear_chat",
      "Clear conversation",
      icon = bsicons::bs_icon("arrow-counterclockwise")
    )
  ),
  toolbar_global = bslib::toolbar(
    bslib::toolbar_input_button(
      "help",
      "Help",
      icon = bsicons::bs_icon("question-circle")
    )
  ),
  sidebar = chat_sidebar(
    tags$p("Use filters to focus the results."),
    history = FALSE
  ),
  pages_navbar = list(
    chat_nav_panel(
      "Sources",
      tags$p("Sources selected during this session appear here."),
      toolbar = bslib::toolbar(
        bslib::toolbar_input_button(
          "refresh_sources",
          "Refresh",
          icon = bsicons::bs_icon("arrow-repeat")
        )
      )
    )
  ),
  drawer = chat_drawer(
    tags$p("Select a result to inspect it here."),
    title = "Latest result",
    open = FALSE
  )
)

from faicons import icon_svg
from shiny import ui
from shinychat import chat_drawer, chat_nav_panel, chat_sidebar
from shinychat.express import page_chat

page_chat(
    "Research assistant",
    id="chat",
    toolbar=ui.toolbar(
        ui.toolbar_input_button(
            id="clear_chat",
            label="Clear conversation",
            icon=icon_svg("arrow-counterclockwise"),
        )
    ),
    toolbar_global=ui.toolbar(
        ui.toolbar_input_button(
            id="help",
            label="Help",
            icon=icon_svg("question-circle"),
        )
    ),
    sidebar=chat_sidebar(
        ui.p("Use filters to focus the results."),
        history=False,
    ),
    pages_navbar=[
        chat_nav_panel(
            "Sources",
            ui.p("Sources selected during this session appear here."),
            toolbar=ui.toolbar(
                ui.toolbar_input_button(
                    id="refresh_sources",
                    label="Refresh",
                    icon=icon_svg("arrow-repeat"),
                )
            ),
        )
    ],
    drawer=chat_drawer(
        ui.p("Select a result to inspect it here."),
        title="Latest result",
        open=False,
    ),
)

Show how the model reached an answer

Understanding how an LLM arrived at an answer is just as — if not more — important than getting the answer from the model. A response can include ordinary text, thinking content, web activity, citations, tool calls, tool results, and custom UI. shinychat works hard to make the model’s work visible and presents each part in a way that helps users understand the answer and what produced it.

Keep tool calls readable

Tool calls are now shown as compact activity rows instead of letting them take over the conversation, refining the tool-call cards shinychat introduced last year. By default, related calls are grouped together into a single row, and users can still expand a group, open an individual call, and inspect the request and result when they need more detail.

Opening an individual call shows the request and the result in a card:

Grouping keeps the answer readable, and the request and result stay one click away. To customize grouping or register tools, see Tool UI in shinychat for R, Tools in Shiny for Python, tool/function calling in ellmer, or tool calling in chatlas.

Show citations for web search and fetch

Many LLM providers offer built-in web search and web fetch tools that let your agent search the web, and their APIs return citations when the model uses that content in a reply. shinychat now displays those citations automatically.

For example, here’s how to register Claude’s tools with an ellmer or chatlas client:

library(ellmer)

client <- chat_anthropic()
client$register_tool(claude_tool_web_search())
client$register_tool(claude_tool_web_fetch())

from chatlas import ChatAnthropic, tool_web_fetch, tool_web_search

client = ChatAnthropic(
    kwargs={
        "default_headers": {
            "anthropic-beta": "web-fetch-2025-09-10"
        }
    }
)
client.register_tool(tool_web_search())
client.register_tool(tool_web_fetch())

When this client is used with chat_server(), citations are connected directly to the portions of the assistant’s response that they support.

Custom retrieval applications, like the RAG systems you can build with ragnar or raghilda, can use the same citation UI by prompting the assistant to use a <shiny-aside> tag to attach a source to a claim.

Stream responses and show thinking

With chat_server() in R or Chat(client=...) in Python, shinychat streams responses and shows supported thinking content in a collapsible panel. Users can cancel a slow response with the stop button or the Escape key, and the partial response stays in the conversation.

Add files and shortcuts

Attach files

File attachments are now supported in shinychat! Your users can send images, PDFs, and text files through a file picker, drag and drop, or paste, and shinychat sends each file to the model alongside the user’s message. When you use chat_server() in R or Chat(client=...) in Python, your app gets that support for free.

Add slash commands

You can now register chat shortcuts, or slash commands, with chat$slash_command() in R or @chat.slash_command() in Python. The command palette appears when users type /, and they serve as a way to trigger server-side code, inject context or additional prompting, or even just take an action in your app, all from the chat input.

Check out the shinychat for R or shinychat for Python documentation for details.

More shinychat-powered apps

The next release of querychat will bring these chat features to data applications, including conversation history, attachments, tool displays, and citations. It will introduce a page-first querychat_app() workflow and a new page() API for adding querychat to an existing Shiny page.

btw 1.5.0 already uses shinychat 0.5.0 to give btw_app() a complete coding assistant for your R projects. It adds conversation history, a page_chat() layout, and slash commands to an assistant that can use your R session, project files, and package documentation.

A few changes for existing apps

Existing chat_ui() applications remain supported when chat shares a page with other top-level content. When the conversation should fill the application instead, choose page_chat() and use it as the outermost page container; nesting it inside another page layout breaks the full-window layout and history experience.

In R, chat_mod_ui() and chat_mod_server() are soft-deprecated in favor of pairing chat_ui() and chat_server() by ID. In both languages, a startup message no longer seeds a conversation when history is enabled; use a greeting or append messages through the chat object instead.

The release also protects users from unsafe model-authored Markdown, shows an error when a response fails before streaming starts, and preserves tool results, citations, attachments, and other rich content when users return to a conversation.

With page_chat(), chat_server() or Chat(client=...), and the history options, you can now give your users a complete chat application: saved conversations they can return to, messages they can edit into new branches, greetings and suggestions to start from, and responses with visible tool calls, citations, and thinking.

Read the shinychat for R documentation or the shinychat for Python documentation to explore the examples. For the complete list of changes, see the R release notes and the Python changelog.

Acknowledgements

We thank everyone who contributed to these releases, for opening issues, submitting pull requests, and providing feedback: @bastianolea, @bianchenhao, @christophsax, @cpsievert, @crissthiandi, @elnelson575, @gadenbuie, @Harshit28j, @JamesHWade, @jcheng5, @jlxAtNovozymes, @jnhyeon, @jose-c-milliman, @kaipingyang, @lucasrod16, @markmcd, @nbenn, @parmsam, @schloerke, @shea-parkes, @simonpcouch, @slupczynskim, @thisisnic, @wlandau, and @xx02al.

You can install the latest version from CRAN with

install.packages("ellmer")

This blog post covers the major changes in this release: a lifecycle update, updates to how you can work with files with ellmer, new ways to update model price data, returning citations when using web search tools, and new hooks for developers building on ellmer’s tool loop.

The full list of changes can be found in the release notes.

Lifecycle

chat_github() and models_github() are now defunct, since GitHub Models has been retired.

We’ve tightened up what a tool can return: a string, an atomic vector, a JSON string, or a Content object. Returning anything else, like a data frame or a list, now gives a deprecation warning. Previously ellmer converted these to JSON for you, but any problem with the conversion surfaced long after your function had finished, and it was easy to forget that the model can only read the result, not compute with it. For a data frame, convert it yourself:

get_weather <- tool(
  function(cities) {
    df <- weather_api(cities)
    jsonlite::toJSON(df, dataframe = "columns")
  },
  ...
)

New features

Sending files to the model

There are now two ways to give the model a file. New content_document_file() and content_document_url() send text-based documents like CSV, Markdown, and code files, just as content_pdf_file() and content_image_file() already do for PDFs and images. The contents go inline with your message, so this works with every provider:

penguins <- tempfile(fileext = ".csv")
readr::write_csv(
  data.frame(
    penguin = c(
      "Waddlesworth", "Flipper McGee", "Turbo Tuxedo",
      "Captain Blubber", "Sir Slidesalot"
    ),
    race_time_seconds = c(43.2, 38.7, 31.9, 45.1, 36.4)
  ),
  penguins
)

chat <- chat_anthropic()
chat$chat("Who won the race?", content_document_file(penguins))
#> Based on the race times, **Turbo Tuxedo** won the race with the fastest time of
#> **31.9 seconds**.

Inline contents are re-sent with every turn, which adds up over a long conversation, especially with a large file. For those cases, chat$file_upload() sends the file to the provider once and returns a reference you pass to $chat() instead. Because the file isn’t re-sent with every message, this also reduces your token usage and costs:

chat <- chat_google_gemini()
race <- chat$file_upload(penguins)
chat$chat("Who won the race?", race)
#> **Turbo Tuxedo** won the race with the fastest time of **31.9 seconds**.
chat$chat("And who came last?")
#> **Captain Blubber** came in last with the slowest time of **45.1 seconds**.

You can manage your uploads with chat$file_list(), $file_get(), $file_download(), and $file_delete(). File management works with chat_openai(), chat_anthropic(), and chat_google_gemini(), and replaces the now-deprecated claude_file_upload() and google_upload().

Citations

When a model answers using a built-in web search or fetch tool, the provider usually reports which sources back the answer. ellmer 0.5.0 captures citations from Claude, Google, and OpenAI.

chat <- chat_anthropic()
chat$register_tool(claude_tool_web_search())
chat$chat("What are the current stable versions of R and Python? Look them up, one line each, no commentary.")
#> R: R version 4.6.1 (Happy Hop) has been released on 2026-06-24[1]
#>
#> Python: Python 3.14.7 / 5 August 2026[2]
#>
#> Sources
#> [1] R: The R Project for Statistical Computing: https://www.r-project.org/
#> [2] Python (programming language):
#> https://en.wikipedia.org/wiki/Python_(programming_language)

Citations are also kept in the chat history and included in streamed output, so apps built on ellmer can display them as well.

Counting tokens and keeping prices current

Two additions make it easier to know what a conversation will cost before you commit to it. Chat$token_count() asks the provider how many tokens some input would use, without actually sending it to the model.

chat <- chat_anthropic()
prompt <- "Tell me a joke about an R programmer"
chat$token_count(prompt)
#> [1] 19

Token counting is currently supported by chat_anthropic(), chat_openai(), chat_google_gemini(), chat_google_vertex(), and chat_posit().

Providers change their prices more often than we release ellmer. You can now update in between releases with models_update_prices(), which downloads the latest pricing data from GitHub and caches it locally.

Other improvements

• Default models have been updated across providers: chat_anthropic(), chat_aws_bedrock(), chat_databricks(), chat_posit(), and chat_snowflake() now use Claude Sonnet 5; chat_openai() and chat_openrouter() use GPT 5.6 Terra; and chat_google_gemini() and chat_google_vertex() use Gemini 3.7 Flash. We update the default models regularly, so if you’d prefer to pin your code to a specific model, you should specify it using the model parameter.
• chat_aws_bedrock() now supports Bedrock Mantle, the newer endpoint that serves models like Claude Mythos and the GPT-5 family through the Anthropic Messages and OpenAI Responses APIs, rather than only the Converse API. ellmer picks the right API from the model name, so this should just work. If you’re using a model it doesn’t recognize, you can set the new api argument yourself.
• You can now stream structured output. Chat$stream() and $stream_async() gain a type argument, which works the same way as in $chat_structured(), for providers that support it.

Developer updates

Two new features help developers building on ellmer’s tool loop.

Inside a tool, tool_context() returns the request that triggered it and the conversation so far, so a tool can make decisions, not just the model. Here, a query tool stops after three calls:

run_query <- tool(
  function(sql) {
    # count_tool_results() is a stand-in for your own helper
    if (count_tool_results(tool_context()$turns) >= 3) {
      tool_reject("Query budget used up. Answer with what you have.")
    }
    jsonlite::toJSON(DBI::dbGetQuery(con, sql), dataframe = "columns")
  },
  name = "run_query",
  description = "Run a SQL query",
  arguments = list(sql = type_string())
)

Chat also gains $on_request_start() and $on_request_end(), which fire before and after every request to the model, including each round of the tool loop. For example, to time each request:

chat <- chat_anthropic()
chat$register_tool(run_query)

started <- NULL
chat$on_request_start(\(turns) started <<- Sys.time())
chat$on_request_end(\(turn) message("Request took ", round(Sys.time() - started, 1), "s"))

chat$chat("Find the mean of every column in mtcars, one query at a time.")
#> Request took 3.6s
#> ◯ [tool call] run_query(sql = "SELECT * FROM mtcars LIMIT 5")
#> ● #> [{"mpg":21,"cyl":6,"disp":160,"hp":110,"drat":3.9,"wt":2.62,"qsec":16.46,…
#> Now I'll compute the mean of each column one query at a time, as requested.
#> Request took 2.7s
#> ◯ [tool call] run_query(sql = "SELECT AVG(mpg) AS mean_mpg FROM mtcars")
#> ● #> [{"mean_mpg":20.0906}]
#> Request took 1.9s
#> ◯ [tool call] run_query(sql = "SELECT AVG(cyl) AS mean_cyl FROM mtcars")
#> ● #> [{"mean_cyl":6.1875}]
#> Request took 2s
#> ◯ [tool call] run_query(sql = "SELECT AVG(disp) AS mean_disp FROM mtcars")
#> ■ #> Error: Tool call rejected. Query budget used up. Answer with what you
#> have.
#> It looks like the query budget has been used up, so I can only report the means
#> I was able to compute before being cut off:
#>
#> | Column | Mean |
#> |--------|------|
#> | mpg | 20.0906 |
#> | cyl | 6.1875 |
#> Request took 3.4s

$on_request_start() also receives the turns about to be sent, so an agent can compact its history with chat$set_turns() before the context window fills up.

Acknowledgements

A big thanks to the 73 people who helped make this release possible by filing issues, contributing code, and asking questions: @1beb, @abiyug, @aclink88, @AdaemmerP, @alesanGreat, @Apollo7777777, @arnavchauhan7, @arunrajes, @atheriel, @awunderground, @bakaburg1, @bastianolea, @bshor, @cerebrixos, @CoryMcCartan, @cpsievert, @D-M4rk, @dareneiri, @debruine, @diegomsg, @diegoperoni, @dipterix, @earthcli, @etiennebacher, @feddelegrand7, @FrancescoMonti-source, @frankiethull, @gadenbuie, @hadley, @hectorgray, @hopessugar, @hswerdfe, @JamesHWade, @jamesinottawa, @jcheng5, @jcrodriguez1989, @jeroenjanssens, @JosiahParry, @jrosell, @kaipingyang, @karawoo, @kbenoit, @kchou496, @klin333, @kolabearafk, @ksr-zguo, @lazasaurus-ai, @lionel-, @MLiedgens, @n8layman, @nbenn, @neil-bray, @nrineausanofi, @ntentes, @omorante, @petzi53, @rajabzadehalidip, @rempsyc, @Sade154, @sarahsdao, @scjohannes, @simonpcouch, @Sirhubi007, @SokolovAnatoliy, @sounkou-bioinfo, @stefanlinner, @t-kalinowski, @Tazinho, @thisisnic, @thoov08, @trangdata, @WvdH-Novus3, and @xmarquez.

This post is about the R package. There is also a Python version of orbital that works on scikit-learn pipelines.

You can install both from CRAN with:

install.packages(c("orbital", "tidypredict"))

This post covers the highlights of these releases. You can see the full list of changes in the orbital release notes and the tidypredict release notes.

A lot more models

Previously orbital and tidypredict supported a handful of useful models. This included linear models, decision trees, random forests, and boosted trees models. This release adds discriminant analysis, naive Bayes, neural networks, support vector machines, partial least squares, and several more rule and ensemble methods. This fills in the gaps of most of the known models that can be made to work with orbital.

Newly supported for regression:

• bart(engine = "dbarts")
• boost_tree(engine = "h2o_gbm")
• linear_reg(engine = "glm")
• mlp(engine = "nnet")
• null_model()
• pls(engine = "mixOmics")
• rand_forest(engine = "aorsf")
• rand_forest(engine = "partykit")
• rule_fit(engine = "h2o")
• svm_linear(engine = "kernlab")
• svm_linear(engine = "LiblineaR")

Newly supported for classification:

• bag_tree(engine = "rpart") and bag_tree(engine = "C5.0")
• boost_tree(engine = "C5.0")
• boost_tree(engine = "h2o_gbm")
• C5_rules(engine = "C5.0")
• decision_tree(engine = "C5.0")
• discrim_linear(engine = "MASS"), discrim_quad(engine = "MASS")
• discrim_linear() with the "mda", "sda", and "sparsediscrim" engines
• logistic_reg(engine = "LiblineaR")
• mlp(engine = "nnet")
• multinom_reg(engine = "nnet")
• naive_Bayes(engine = "klaR") and naive_Bayes(engine = "naivebayes")
• null_model()
• pls(engine = "mixOmics")
• rule_fit(engine = "h2o")
• rule_fit(engine = "xrf")
• svm_linear(engine = "kernlab")
• svm_linear(engine = "LiblineaR")

One thing worth noting for models with “h2o” in their engine value, is that you need a running H2O cluster to build the orbital object. Prediction and SQL generation from the orbital object stays dependency free.

Here is an example of linear discriminant analysis model, which was not supported before this release, fit on the penguins data and then run in DuckDB.

library(tidymodels)
library(discrim)
library(orbital)
library(duckdb)

data(penguins, package = "modeldata")
penguins <- tidyr::drop_na(penguins)

rec_spec <- recipe(species ~ ., data = penguins) |>
  step_dummy(all_nominal_predictors()) |>
  step_normalize(all_numeric_predictors())

mod_spec <- discrim_linear(engine = "MASS")

wf_spec <- workflow(rec_spec, mod_spec) |>
  fit(penguins)

orb <- orbital(wf_spec, type = c("class", "prob"))

con <- DBI::dbConnect(duckdb::duckdb())
penguins_db <- dplyr::copy_to(con, penguins, "penguins")

predict(orb, penguins_db)

# A query:  ?? x 4
# Database: DuckDB 1.5.5 [root@Darwin 25.6.0:R 4.6.1/:memory:]
   .pred_class .pred_Adelie .pred_Chinstrap .pred_Gentoo
   <chr>              <dbl>           <dbl>        <dbl>
 1 Adelie             1.000        6.43e- 9     4.64e-25
 2 Adelie             1.000        5.25e- 6     8.81e-16
 3 Adelie             1.000        1.97e- 4     2.61e-17
 4 Adelie             1.000        2.99e- 8     1.93e-23
 5 Adelie             1.000        8.34e- 9     4.42e-29
 6 Adelie             1.000        1.60e- 6     4.14e-20
 7 Adelie             1.000        6.03e-10     1.45e-18
 8 Adelie             0.999        6.47e- 4     4.16e-20
 9 Adelie             1.000        9.56e-10     1.97e-30
10 Adelie             1.000        6.73e-14     9.13e-27
# ℹ more rows

We have documented the list of supported models. If there is a model you need that is still missing, let us know so we can prioritize it.

When a model has no probability

While we added these new methods we ran into a problem we didn’t have before. For many classification models you get both predicted probabilities and hard class predictions. This release has added models where that is not the case. A number of newly added models only produce hard class predictions.

Instead of trying to invent class probabilities, we produce an informative error for the affected models.

c5_wf <- workflow(
  species ~ .,
  decision_tree(mode = "classification", engine = "C5.0")
) |>
  fit(penguins)

orbital(c5_wf, type = "prob")

Error in `orbital()`:
! "prob" predictions are not available for this model.
ℹ It predicts a class directly, with no probability behind it.
ℹ Use `type = "class"` instead.

tidypredict is now a toolkit, not just a function

We have talked a lot about orbital so far. This is because we think that it is the ideal interface compared to tidypredict, if your goal is to generate SQL expressions for a fitted model or workflow.

orbital and tidypredict work together to generate the expression that you need. We have expanded tidypredict with a number of generics, which are all developer focused. With the goal that packages other than orbital can benefit from the work we have done. Three of them describe what a model’s fitted expressions compute:

• tidypredict_output_type() returns "numeric", "prob", "decision", or "class"
• tidypredict_outcome_levels() returns the outcome levels in model order
• tidypredict_normalized() reports whether per-level probabilities already sum to one

Below we see two of the generics in action.

library(tidypredict)

svm_fit <- svm_linear(mode = "classification", engine = "LiblineaR") |>
  fit(sex ~ bill_length_mm + body_mass_g, data = penguins)

tidypredict_output_type(svm_fit$fit)

[1] "decision"

tidypredict_outcome_levels(svm_fit$fit)

[1] "female" "male"  

The other five expose the per-tree pieces that tidypredict_fit() assembles, so a package generating its own code can split an ensemble apart and put it back together:

• tidypredict_trees() returns per-tree expressions
• tidypredict_n_trees() returns the number of trees
• tidypredict_combine_trees() turns per-tree expressions back into a prediction
• tidypredict_class_trees() returns per-tree expressions for each outcome level
• tidypredict_class_exprs() returns one finished expression per outcome level

rf <- rand_forest(mode = "regression", trees = 5, engine = "ranger") |>
  fit(body_mass_g ~ bill_length_mm + flipper_length_mm, data = penguins)

tidypredict_n_trees(rf$fit)

[1] 5

tidypredict_combine_trees(rf$fit, rlang::syms(paste0("tree_", 1:5)))

(tree_1 + tree_2 + tree_3 + tree_4 + tree_5)/5

A lot of this logic was hardcoded inside orbital on a model by model basis, it is now formalized in such a way that you can easily use just the bits you need.

Acknowledgements

Many thanks to all the people who contributed to orbital and tidypredict since the last release!

@EmilHvitfeldt, @jannikbx, and @RAMitchell.

Welcome back to another edition of our monthly Positron updates! Each month we share highlights from our latest release and useful resources. Last release we told you about new Data Connections sources, a round of polish for inline output in Quarto documents, and help installing missing packages. This milestone brings a redesigned welcome page, a first version of Import Data, new Posit Assistant features, expanded Data Connections, package vulnerability scanning, and a more responsive Console.

Welcome page refresh and interpreter setup

We redesigned the Positron welcome page. It now leads with an environment setup card that checks whether Python and R are ready to use, with actions to help resolve any problem it finds. The Positron badge and name now come with a Help button that opens the Help pane, and a banner links to the walkthroughs, including a new “Get Started with Positron” walkthrough that covers the Positron panes, keyboard shortcuts, built-in extensions, and Git.

The environment setup theme continues into interpreter selection itself. When you select a Python managed by your operating system or a package manager, Positron now offers to create a virtual environment for your workspace instead of installing packages into that shared interpreter. With no folder open, the environment Positron creates now lives at ~/.virtualenvs/positron rather than ~/.venv, so it stays in the interpreter picker after a restart, and Positron asks before creating an environment in your home directory. We also removed the confusing startup notification that reported no interpreters were found while linking to documentation saying no setup was needed, and interpreters installed under /opt/python are now labeled Global instead of Unknown in the interpreter picker.

Import Data

Before we started work this month, importing data via the Positron UI was our most upvoted feature request and this release now delivers a first version. When you view a CSV or TSV file in the Data Explorer, a new Import Data button in the action bar opens a dialog. The dialog shows the code to load that file into a data frame. You can copy the code, or click Import to run it in the console, starting a session if one is not already running.

Import Data supports CSV and TSV files in Python with pandas and in R with the readr package, as well as Excel workbooks and Parquet files (with readxl and nanoparquet in R). The generated code can reproduce the filters and sorts you have applied in the Data Explorer, and it names the file by a workspace-relative path when the file is inside your workspace, so the code is easier to share and rerun. You can open the dialog from the Data Explorer, the File menu, the Variables pane, or the File Explorer context menu.

Posit Assistant

This release brings a new Agent Layout that opens Posit Assistant in the editor area with a compact Session pane, giving you more visibility into the agent’s actions as it works alongside your code. Configuring language model providers also gets a redesign. Our new Configure LLM Providers modal groups providers by connection state, so you can see at a glance which providers are ready to use. If you have trouble with the new dialog and need to switch back, set assistant.newProviderModal to false.

You can now configure multiple custom providers, each with its own name, type, endpoint, credential, and model list; the previous single “Custom Provider” option is now called “OpenAI Compatible” to better match what it actually does. Amazon Bedrock users get a smoother experience as well. An expired AWS SSO session can be renewed right from the provider modal instead of requiring aws sso login in a terminal, and the AWS profile and region can now be set in the configuration dialog rather than only through environment variables or a hand-edited providers.json. Speaking of which, providers.json now accepts comments, and your comments survive edits that Positron makes to the file.

Data Connections

The Data Connections preview keeps growing. A new ODBC data connection driver lets you browse any database with an installed ODBC driver in the Connections pane and open it in the Data Explorer. Data sources already configured on your machine appear automatically. Databricks gains OAuth sign-in on desktop and reads DATABRICKS_TOKEN, DATABRICKS_HOST, and DATABRICKS_CONFIG_FILE credentials managed by Posit Workbench automatically. A Disconnect option in the context menu closes a connection and any Data Explorers opened from it, and each data connection driver now gets its own log output channel.

Smaller improvements round out the preview. You can now set dataConnections.enabled per workspace, so a repository can turn on the Connections pane for anyone who opens it. The tree is shallower so table and column names get more of the panel’s width, and a new dataConnections.tree.indent setting controls the indentation. DuckDB connections now default to read-only, so the Connections pane and a Python or R session can have the same database open at once; when a lock conflict does happen, the error now explains that another session has locked the database.

Package security vulnerabilities

The Packages pane now shows known security vulnerabilities (Common Vulnerabilities and Exposures scoring) for installed Python and R packages, so you can see at a glance whether something in your environment has a known CVE. The data comes from your environment’s own Posit Package Manager repository when it has one, and from the public Posit instance otherwise, so what you see reflects the same package source your organization already governs.

A more responsive Console

Console code submission is now faster, always shows visual feedback, and can be canceled while a completeness check is in flight; the Console no longer waits indefinitely with no feedback when a kernel is slow or unreachable. The Console breaks multi-statement input into complete expressions and executes them statement by statement for languages that support it. A new console.promptWhenIncomplete setting runs submitted code immediately without a completeness check.

A few more Console fixes are worth knowing about. The Console no longer takes focus at runtime startup when you are working in another view or editor, Interrupt stays visible after switching between busy consoles, and session names now ellipsize to fit as the console tab list narrows.

What’s coming next

• posit::conf(2026) is next week! Our team will have several sessions on Positron, and there is still time to register to join us virtually from anywhere in the world.
• Meet Posit at CDAO Government on September 22-23 in Washington, D.C. Stop by our booth to talk data modernization and where agentic AI fits in government.

Recently, there’s been a lot of talk about fine-tuning models. The reasoning usually goes something like this:

• There’s some task that needs to be done regularly.
• Today’s frontier models can do it quite reliably, but it’s expensive and the bills are starting to rack up.
• Cheaper models can’t quite do the task reliably, but a fine-tuned variant of a small, open-weights model might be able to just as cheaply.
• Therefore, you should fine-tune models for tasks that your organization does.

I’ve seen a number of blog posts cited in support of this idea.

It makes sense that fine-tuning is appealing! AI is getting expensive, many players in the space cannot make the privacy guarantees we’d hope, and just as you start to rely on one proprietary model, it’s phased out in favor of a newer release. That said, my reaction is that this approach seems more engineering-intensive and, likely, more expensive than alternative approaches. I’ll try to make that case here.

What is fine-tuning?

Before we go further, it’s probably worth quickly outlining what I mean by fine-tuning. In short, fine-tuning means training an existing model further to improve its performance on a particular task.

Large language models contain huge arrays of parameters. Input, usually in the form of text, is turned into arrays of numbers, and those arrays get multiplied a bunch of times to form the output, which is then typically converted back into text. Those multiplications are quite computationally intensive, and the array of parameters is itself quite large. For example, the smallest models that are beginning to be able to reliably complete basic agentic work contain 8 billion parameters (in short, “8B”).

Fine-tuning changes a model’s behavior, either by updating the existing parameters, or by training a smaller set of additional parameters that work alongside the originals. The goal of fine-tuning is, broadly, to increase the performance of a model on a given task while minimizing the impact on the model’s ability to do other tasks.

Fine-tuning is hard

It is very, very difficult to successfully fine-tune a model. I don’t claim that it’s impossible, but it is a substantial engineering effort, requiring the careful attention of dedicated scientists with access to today’s frontier models across several weeks, just for the first edition of the model. To show why, let’s revisit each step of that process.

What model should you start with? In short, you want the smallest possible model that has the ability to learn to do the task reliably while retaining sufficient general intelligence. It is very hard to predict when or how capabilities will emerge during fine-tuning without first fine-tuning, meaning that the choice will need to be revisited several times once you’ve made a first go at the remaining steps.

What data gets used for training? Once you’ve chosen a model, you need to find some training data to fine-tune it with. What should you use? Ideally, you would use the real data that represents the task and its inputs. However, in order to train on that real data, you typically need the user’s consent, and it’s likely that you won’t have that consent.

And then, when you do have user consent and choose to train on that data, you now have a mandate not to overfit. This is because if the model you’re fine-tuning internalizes the data you’re training on and is able to (even hazily) recollect it, you’ve now exposed that data to any users of the model.

The other approach, then, is synthetic data, created by asking a model to generate a bunch of scenarios that resemble the real inputs and then demonstrate how to carry out the task in those scenarios. But this type of synthetic data has its own problems: notably, the models creating the data have their own set of tics that make the data unrepresentative of real-world data. The Elias in the Lighthouse effect is a notable example of this phenomenon. A wide variety of models will, when asked to write a story, write about a lighthouse keeper named Elias Thorne. On its own, the story of Elias Thorne might be informative training data. However, 1,000 stories about a lighthouse keeper Elias Thorne are not.

How do you nudge the weights? Let’s assume you do have a diverse, representative set of training data to work with. You’ll now need to decide how, mechanistically, to change the behavior of the model—do you need a full fine-tune, or will a LoRA be sufficient?

Next, you’ll need to tune a set of 5-10 hyperparameters. Notably, because they are hyperparameters, there is no generally good “magic number” for them, and instead you’ll need to try a bunch of values and see what works. You’d make some guesses, see what happens, then generate some hypotheses on what a given change to those parameters might do, then try out a different number and see if it has the desired effect. Every time you’re figuring out what to try next, you’ll be reading a ton of test cases and trying to observe general failure modes exhibited in this intermediate draft of your fine-tuned model. That might change the initial choice of model you’re fine-tuning, and it might change which subsets of the training data you’re exposing to the training process.

How do you measure success? You need a reliable way to tell whether each version of your model is actually improving. That is especially tricky for free-text tasks, because two answers can be equally good even when they differ syntactically. Because of this, you’ll probably want an LLM-as-a-judge system, where another model compares the responses to a target and grades according to a rubric you’ve supplied. LLM-as-a-judge systems are themselves quite hard to design correctly, and you’ll be reading a bunch of that judge’s grading transcripts, too.

It’s also worth mentioning that getting your fine-tuned model to score well on your own benchmark is not the hard part. Many of these fine-tuning writeups include a plot along these lines:

When I see that a single-digit-billion-parameter fine-tuned model scores better than Fable 5.1 or GPT 5.6 Sol on an evaluation, I interpret that as evidence that the evaluation is not meaningful. In my own experience, it is not (comparatively) hard to get a small model to score very well on any given benchmark. What’s much more difficult is preserving the broad intelligence of a model while driving the evaluation score up. A meaningful evaluation can do both at once, measuring task performance under a realistic, broad distribution of possible task configurations. It is very hard to author meaningful evaluations, especially for models as capable as those that exist today.

But let’s say you’ve made it this far! You found a good model to start from, a diverse set of training data that you’ve obtained consent to train on, and a meaningful way to measure progress. Now, it’s time to put it in production.

Fine-tuning is expensive

Fine-tuning can seem appealing because the actual fine-tuning part of the process can be relatively inexpensive, likely on the order of a few dollars to a few hundred dollars.¹

However, actually deploying the model to do the task you trained it to do is likely to be substantially more expensive.

…because hosting is expensive

Hosting a model yourself is more expensive than using a similarly capable model hosted by someone else unless you have extraordinary volume. Frontier-model providers like Anthropic and OpenAI serve extraordinarily large volumes, keeping their compute almost always near max capacity. It’s likely that the same won’t be true for your fine-tuned, self-hosted model.

As an example, let’s say I host Gemma 4 26B A4B on a single H100. I can rent a high-availability H100 GPU instance at $0.0833 a minute, or $44,000 a year. Assuming a coding-agent-like workload,² that would buy about 96 billion Sonnet 5 tokens, and Sonnet 5 is a much more capable model. To break even, this fine-tuned model would need to serve about 182,000 tokens per minute, 24/7, throughout the year.

It might be possible to serve that many tokens. The hard part is finding enough demand for one task to keep the model busy, and that demand needs to be relatively smooth. If the model sits idle, you’re still paying for it. If demand spikes, you either rent a second GPU or accept worse performance for users.

…and you must host

The other suggestion here is that, if the model is small enough, users who need to do the task can just download the weights and run it on their laptop or a dedicated workstation.

The effectiveness of this argument depends on the kind of task to be done. However, it’s worth considering the potential for this to be a very unpleasant user experience compared to just using a model that someone else hosts. For example, let’s say my colleague does some task for an hour every week and there’s some model small enough to run on my laptop that’s capable of doing the task. In order to use the model for that task, my colleague would need to download the 4GB or 8GB or 100GB or whatever of weights. That user would also need to be capable of configuring the serving of the model, and they’d need to make that happen every time they started the task. If that model was accessed through a tool that the user was using regularly anyway—Claude Code pointed at a local ollama model, for instance—they’d need to remember to switch the model over in the application’s settings. If that model was accessed through a different interface, the user would need to use a different interface than they normally use LLMs with for that task specifically. Neither of these are good UX.

Even if the software for locally serving models got much more pleasant than it currently is, it’s hard to compete with the experience of pay-as-you-go for the Everything Tool that wraps the Everything Model.

Your fine-tune will quickly fall behind

Let’s say you successfully fine-tune a model based on some fictional model Kuen 3. Then, the following week, Kuen 3.5 is released. 3 of the 100 most capable LLM scientists on this planet worked on it. It’s almost as good as your fine-tune on that specific task, and it’s also broadly capable at a very broad array of tasks.

Fine-tuning is not a boat that is lifted by the rising tide of broader AI progress—in order to take advantage of the Kuen 3.5 release with your fine-tune, you’d need to restart that process of choosing parameters and observing fine-tuning runs. The underlying architecture of the model may have changed, and thus the approaches that you used to fine-tune Kuen 3 might not work for Kuen 3.5 on your first try.

What you should do instead

Instead, the boat that is lifted by a rising tide in this context is plain old prompt engineering. (POPE, as Joe Cheng calls it.) Choose a model that’s available to you, that fits your price point, and seems broadly capable across a wide variety of public benchmarks. (Extra points if the vibes on the model from people you trust are good, and extra points if someone else is serving it.)

Then, put together a short prompt telling the model how to do the task, perhaps inside of some coding agent harness like Claude Code (or, hey, Posit Assistant), and see what it does. Adjust the prompt to tell it how to do things correctly that it tends to trip up on, and iterate from there. If you’ve already put together an evaluation as part of your fine-tuning process, you could even reuse that! My colleague Sara and I have written about prompt engineering in the past if you’re interested in learning more, once about the more specific task of POPE for teaching LLMs about R packages but in relatively generalizable ways, and once focused on deciding between the popular ways to deliver context to coding agents.

Recent past newsletters

• How to choose a model
• Keep track of your data exploration with Posit Assistant’s EDA log

Subscribe via RSS

To install the newest release, run the following in R:

install.packages("vitals")

The package includes two new helpers, claude_code() and codex(), which allow you to compare your own ellmer-built agents with leading coding agents. This release also ships another new helper, vitals_log_read(), which supports reading log files back into tibbles, including columns of resumable ellmer Chats. Finally, the release includes several performance improvements; log files are much smaller, and the log viewer that reads them is now substantively faster.

To read the full list of changes, see the changelog.

Agent solvers

vitals is a port of Inspect, a well-adopted Python framework for LLM eval from Posit’s own JJ Allaire. One of the concepts that vitals borrows from Inspect is the concept of a “solver,” or the LLM-powered system that sets out to solve some task. The simplest solver is just the LLM itself, with no system prompt or tools, like what you’d get from running chat_anthropic() from ellmer. Solvers can gain all sorts of prompts and tools, which allows vitals users to test the effect of a change in their prompt or the addition of a new tool.

In the last year or so, the dominant interface to solvers in Inspect has become “agent solvers”: interfaces to the popular coding agents Claude Code and Codex. You call the helper claude_code() or codex(), and Inspect will proxy traffic through the real coding agent harness.

vitals now has first-class support for these two helpers, allowing users to compare their own agents built with ellmer to popular coding agents like Claude Code and Codex. You provide the set of tasks and grading guidance, and vitals will take care of the communication with Inspect.

Read eval logs back into ellmer Chats

One of the big annoyances I’ve had in my own usage of vitals is log storage. So that users can use Inspect’s log viewer directly, we write evaluation logs to a JSON format that Inspect can read.^[1] However, I often want to write R code against the original R objects—ellmer Chats especially—that the logs were generated from. Loading in the ellmer Chats would especially be helpful for inspecting (ha!) the conversation histories in the same interface that users of the ellmer application would see.

Because of this, I’ve often saved both the JSON logs and .rda logs, the latter of which contain the ellmer Chats. These files are large on their own, and it feels even more silly passing around duplicates of them.

The new release of vitals introduces vitals_log_read(), which reads an eval log file back into a tibble of samples. (It’s almost exactly what you’d get if you ran the get_samples() method on a vitals Task object.) That tibble includes reconstructed solver (and, for model-graded scorers, scorer) chats as ellmer Chat objects. For some providers, the chats will even be resumable; you can load in a solver from a JSON file into an R session and ask that solver a question yourself.

Performance improvements

The long and the short of this section is just to say that:

1. Logs will take up less storage space than they did before. Roughly, logs written with the new vitals version will be 4x smaller than before, and the magnitude of savings increases with the complexity of the log.
2. We now display logs (with vitals_view()) much more quickly. The log viewer should feel very snappy for almost all uses of the package.

I’m really excited to have this release on CRAN! Take it for a spin and let me know if you run into issues on the package repository.