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.

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.

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.

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

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

Welcome to this month’s roundup of the latest open-source developments from Posit! Our update list is slightly shorter this time around, because our team is hard at work putting the final touches on posit::conf!

In this special feature, we are spotlighting a few presentations that will be broadcast live throughout the conference. Be sure to register today if you’d like to tune in live. And, if you enjoy being chronically online like me, I’ll be hanging out in the Discord community server throughout the event, alongside your 1000+ closest data pals 👾

Key product updates and new releases

Positron August Release Highlights

The Positron 2026.08 Release blog post highlights several key updates and improvements to Posit’s next-generation data science IDE, including expanded Data Connections (preview), more polished Quarto inline output, centralized AI provider configuration, and performance and reliability upgrades.

• Read more in the Positron August Release Highlights blog post.

Kimi K3 and GLM 5.2 are now in Posit AI

Posit has added two new open-weights models, Kimi K3 and GLM 5.2, to the Posit AI platform. Both models stream tokens nearly twice as fast as Anthropic’s models in internal testing and offer lower cost-per-token rates (partly due to more efficient tokenizers and no extra charge for cache writes).

• Read more in the Kimi K3 and GLM 5.2 are now in Posit AI blog post.
• Learn how to pick your models in the AI Newsletter: How to choose a model blog post.

cuda.ml 0.4.0

cuda.ml is an R package that brings NVIDIA GPU-accelerated machine learning directly to R workflows. This release introduces streamlined setup and developer experience and expanded tree-ensemble inference.

• Read more in the cuda.ml 0.4.0: GPU-accelerated machine learning from R blog post.

Orbital 0.6.0

Orbital converts Scikit-learn pipelines into SQL queries so that they can run in your database. Orbital 0.6.0 adds PyTorch neural network support, enabling trained torch.nn.Sequential models to compile directly to SQL for database-native inference without requiring a Python runtime, ONNX Runtime, or separate model server.

• Read more in the Neural networks in Orbital for Python 0.6.0: PyTorch straight to your database blog post.

recipes 1.4.0

recipes lets you create a pipeable sequence of feature engineering steps. Recipes 1.4.0 introduces a new way to look inside a recipe partway through, a substantial speedup for steps that are applied to many columns, and multi-column support in step_regex() and step_count().

• Read more in the recipes 1.4.0 blog post.

themis 1.1.0

themis contains extra steps for the recipes package for dealing with unbalanced data. Version 1.1.0 adds eleven new sampling steps for handling unbalanced data. It also adds setting sampling targets per class and more distance metrics.

• Read more in the themis 1.1.0 blog post.

New cheatsheets

We’ve refreshed our cheatsheets page, which now features three brand-new additions!

• Python Polars: Developed in partnership with Polars, Inc., this cheatsheet introduces Polars core concepts and key expressions.
• tidymodels: Updated cheatsheets detailing practical workflows across the entire tidymodels ecosystem.
• yardstick: Guidance on using yardstick within tidymodels to evaluate model predictive performance.

Check them below:

Python Polars: The Definitive Cheatsheet

Quick reference guide for transforming, analyzing, and visualizing data with Python Polars

Jeroen Janssens, Thijs Nieuwdorp

Great Tables plotnine

Machine learning with tidymodels

A map of the tidymodels packages, grouped by where each one fits in the machine learning workflow

Edgar Ruiz

tidymodels

Measure model performance with yardstick

Quick reference guide for measuring how well a model predicts with yardstick

Edgar Ruiz

yardstick

posit::conf(2026) talk sneak peeks

With over 100 talks, it’s impossible to feature all of them in this newsletter (but you can explore the complete lineup on the event schedule!). I wanted to give a quick preview of topics you can look forward to (whether you tune in live during the conference or catch up on demand).

1. Positron in prime time

It’s been about two years since the public release of Positron, and 🎵this IDE is on fire 🎵

The lineup of conf talks proves it. From Quarto notebooks in Positron (did you know inline output is available?!), to using Positron in education, to how it treats SQL as a first-class language, to delightful workflows in Python and R, come see what people are cooking up with Positron.

2. What can’t you do with Quarto?

The best way of discovering what Quarto can do is seeing how others are using it!

We’re starting off strong, with the first session of Virtual Day (September 14th) being “Quarto, R + Python”, where Björn Fisseler will discuss creating accessible reports and Wasim Lorgat sharing the history of notebooks. The Quarto theme continues on the 15th and 16th with talks on designing influential and scalable reports, creating learning ecosystems, teaching bilingual data science, developing wiki chatbots, and developing unreasonably effective dashboards and slides — all in Quarto.

3. I’ll definitely be joining…

   • Positron and the Three Bears: Teaching Python with Positron (presented by Marc Dotson) - Practical lessons from an educator navigating Python instruction and finding the sweet spot with Positron
   • First Impressions Matter: Styling Data Products That People Actually Want to Use (presented by Shelby Level) - Shelby creates visually striking data products, and I can’t wait to pick up some design inspiration and techniques from her session
   • A Grammar of Graphics for SQL (presented by Thomas Lin Pedersen) - We’ll hear the developer of ggsql share the story of bringing ggplot2-style visualization concepts to SQL
   • Outgrowing Spreadsheets: Rebuilding Research Data Collection with Shiny and Posit Connect (presented by Kelsey Chalmers) - Kelsey shares the before-and-after architecture and how their research team transformed a fragile, spreadsheet-based data collection process into a sustainable system using Shiny and Posit Connect

Of course, this is just the tip of the conf iceberg. One of my favorite things about conf is the diversity of talks, from real-world data science implementation, to insights from the field, to creative and whimsical experiments. I hope to see you there!

If you can’t wait til conf (or if you’re reading after conf is over!), there are other events that you can join us at:

• Data Science Lab, every Tuesday at 12pm ET
• Data Science Hangout, every Thursday at 12pm ET
• Building Repeatable AI Workflows with Custom MCP Servers, September 30
• Our next conference appearance

Have a lovely September, and reach out anytime! isabella [dot] velasquez [at] posit [dot] co

This release brings 3 main improvements that are worth your attention: a new way to look inside a recipe partway through, a substantial speedup for steps that are applied to many columns, and multi-column support in step_regex() and step_count().

You can install it with:

install.packages("recipes")

Seeing a recipe partway through

A recipe is constructed using a series of pipes. Since it is prepped as a unit, it can be a little hard to look into the internals and see what happens at each stage of the recipe. If you wanted to know what the data looked like after the second recipe step you would need to write out a separate recipe with just those steps.

This is no longer the case as bake() now takes a stop_at argument, which applies only the steps up to and including the one you specify. Below we write out a small recipe on the ames data set.

data(ames, package = "modeldata")

ames <- ames |>
  select(Sale_Price, Neighborhood, Bldg_Type, Year_Built, Gr_Liv_Area) |>
  mutate(Sale_Price = log10(Sale_Price))

ames_rec <- recipe(Sale_Price ~ ., data = ames) |>
  step_other(Neighborhood, threshold = 0.05) |>
  step_dummy(all_nominal_predictors()) |>
  step_normalize(all_numeric_predictors()) |>
  prep()

The three steps each do a job that the next one depends on. Neighborhood has 29 levels, many of them rare, so step_other() pools every level accounting for less than 5% of the data into a single "other" level, which keeps the next step from producing near-empty indicator columns. step_dummy() then turns the remaining factors (Neighborhood and Bldg_Type) into 0/1 indicator columns, since most models need numeric predictors. Finally, step_normalize() puts every predictor on the same scale (mean 0, standard deviation 1), which matters for regularized and distance-based models.

Now let’s first see the data before we apply the recipe on it.

tail(ames) |> 
  glimpse()

Rows: 6
Columns: 5
$ Sale_Price   <dbl> 5.117271, 5.153815, 5.117271, 5.120574, 5.230449, 5.274158
$ Neighborhood <fct> Mitchell, Mitchell, Mitchell, Mitchell, Mitchell, Mitchell
$ Bldg_Type    <fct> OneFam, OneFam, OneFam, OneFam, OneFam, OneFam
$ Year_Built   <int> 1960, 1984, 1983, 1992, 1974, 1993
$ Gr_Liv_Area  <int> 1224, 1003, 902, 970, 1389, 2000

If we now wanted to see what happened after the first step, we pass in stop_at = 1 to bake().

bake(ames_rec, new_data = tail(ames), stop_at = 1) |>
  glimpse()

Rows: 6
Columns: 5
$ Neighborhood <fct> other, other, other, other, other, other
$ Bldg_Type    <fct> OneFam, OneFam, OneFam, OneFam, OneFam, OneFam
$ Year_Built   <int> 1960, 1984, 1983, 1992, 1974, 1993
$ Gr_Liv_Area  <int> 1224, 1003, 902, 970, 1389, 2000
$ Sale_Price   <dbl> 5.117271, 5.153815, 5.117271, 5.120574, 5.230449, 5.274158

And we see that Mitchell was collapsed into "other" by step_other(). Next we set stop_at = 2 to see the result of step_other() followed by step_dummy().

bake(ames_rec, new_data = tail(ames), stop_at = 2) |>
  glimpse()

Rows: 6
Columns: 15
$ Year_Built                      <int> 1960, 1984, 1983, 1992, 1974, 1993
$ Gr_Liv_Area                     <int> 1224, 1003, 902, 970, 1389, 2000
$ Sale_Price                      <dbl> 5.117271, 5.153815, 5.117271, 5.120574, 5.…
$ Neighborhood_College_Creek      <dbl> 0, 0, 0, 0, 0, 0
$ Neighborhood_Old_Town           <dbl> 0, 0, 0, 0, 0, 0
$ Neighborhood_Edwards            <dbl> 0, 0, 0, 0, 0, 0
$ Neighborhood_Somerset           <dbl> 0, 0, 0, 0, 0, 0
$ Neighborhood_Northridge_Heights <dbl> 0, 0, 0, 0, 0, 0
$ Neighborhood_Gilbert            <dbl> 0, 0, 0, 0, 0, 0
$ Neighborhood_Sawyer             <dbl> 0, 0, 0, 0, 0, 0
$ Neighborhood_other              <dbl> 1, 1, 1, 1, 1, 1
$ Bldg_Type_TwoFmCon              <dbl> 0, 0, 0, 0, 0, 0
$ Bldg_Type_Duplex                <dbl> 0, 0, 0, 0, 0, 0
$ Bldg_Type_Twnhs                 <dbl> 0, 0, 0, 0, 0, 0
$ Bldg_Type_TwnhsE                <dbl> 0, 0, 0, 0, 0, 0

And we can see the dummies created on Neighborhood and Bldg_Type.

Much faster on wide data

Many of the steps such as step_normalize(), step_unknown(), and step_impute_mean() work by modifying the data frame in place. No new columns are created and no columns are removed. This type of step is quite common throughout recipes. It was found that these steps could have their performance improved, especially if applied to a lot of columns. Regardless of how many columns you have, you will get the same results as before, at the same speed or faster depending on the number of columns.

library(recipes)

set.seed(1)
df <- as.data.frame(matrix(rnorm(200 * 5000), nrow = 200))

rec <- recipe(~ ., data = df) |>
  step_normalize(all_numeric_predictors()) |>
  step_YeoJohnson(all_numeric_predictors())

system.time(prepped <- prep(rec))
system.time(bake(prepped, new_data = df))

On my machine I get roughly these numbers.

prep() got about 3× faster here and bake() over 20×, and the gap widens as you add columns.

Over 40 steps benefited from this change. See the changelog for the complete list. You don’t have to change any code to get this. Existing recipes are just faster.

If you write your own steps, the helper behind this is exported as recipes_map_cols().

step_count() and step_regex() take multiple columns

The two steps step_count() and step_regex() were always the odd ones out as they could not be applied to more than one column. This has been fixed in this release, where the steps can now be applied to any number of columns, putting them in line with the rest of the steps in the tidymodels ecosystem.

ice_cream <- tibble(
  flavor = c("rocky road", "stony brook", "vanilla"),
  notes  = c("a rock in there", "no match", "rock and stone")
)

recipe(~ ., data = ice_cream) |>
  step_count(flavor, notes, pattern = "rock", result = "rocks") |>
  prep() |>
  bake(new_data = NULL)

# A tibble: 3 × 4
  flavor      notes           flavor_rocks notes_rocks
  <fct>       <fct>                  <int>       <int>
1 rocky road  a rock in there            1           1
2 stony brook no match                   0           0
3 vanilla     rock and stone             0           1

When more than one column is selected, the new columns are named {column}_{result} rather than just {result}, so they stay distinguishable.

Acknowledgements

Many thanks to all the people who contributed to recipes since the last release!

@EmilHvitfeldt, @instantkaffee, @LeonidasZhak, and @topepo.

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

Install from CRAN

For most users, setup is two commands:

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

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

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

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

Use familiar modeling interfaces

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

library(cuda.ml)
library(parsnip)

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

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

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

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

Work directly with cuda.ml

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

library(cuda.ml)
library(ggplot2)

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

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

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

Run tree ensembles on a GPU or CPU

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

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

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

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

Save and deploy fitted models

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

The simplest file workflow passes a path directly:

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

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

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

library(cuda.ml)

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

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

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

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

Highlights for users upgrading from cuda.ml 0.3

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

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

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

The guides cover first steps and more complete examples:

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

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

Data Connections

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

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

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

Inline output for Quarto

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

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

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

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

AI model providers

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

Install missing packages

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

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

Performance and memory

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

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

What’s coming next

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

install.packages("themis")

This release provides a substantial amount of new features. We will cover the highlights in this blog post, which include: 11 new steps, setting sampling targets per class, and more distance metrics. See the news file for a complete list of changes in this release.

To get started, load the tidymodels and themis packages:

library(tidymodels)
library(themis)

set.seed(1234)

New sampling steps

This release adds support for 11 new steps for under- and over-sampling of data. Making for a more complete picture of the commonly discussed methods in this category. Each step also ships a direct-implementation counterpart (enn(), smogn(), and so on) for use outside a recipe.

The new steps fall into four groups.

Cleaning-based under-sampling removes observations that sit in the wrong neighborhood:

• step_enn() applies the Edited Nearest Neighbors rule.
• step_ncl() applies the Neighborhood Cleaning Rule.
• step_cnn() uses Condensed Nearest Neighbors.
• step_oss() uses One-Sided Selection.

Selection-based under-sampling picks a smaller set of representatives instead:

• step_cluster_centroids() replaces each class with one representative per k-means cluster.
• step_instance_hardness() removes the observations that are hardest to classify.

Over-sampling gains three new variants:

• step_kmeans_smote() generates new examples only inside clusters where the minority class dominates.
• step_svmsmote() concentrates them near the decision boundary found by a support vector machine.
• step_smoten() handles data where every predictor is categorical.

Lastly we have a step that applies the SMOTE idea to regression:

• step_smogn() over-samples rare regions of a numeric outcome and under-samples the common ones.

The new “Methods overview” article lays out the full taxonomy.

Sampling targets per class

The over_ratio and under_ratio arguments used by many of the steps in themis previously only took a single value. We now accept a named vector, such that you can specify the value for each level of the outcome.

The penguins data set has three species of unequal size. A few penguins have missing measurements, which we drop up front so the counts below are easier to follow:

data(penguins, package = "modeldata")

penguins <- penguins |>
  drop_na()

count(penguins, species)

# A tibble: 3 × 2
  species       n
  <fct>     <int>
1 Adelie      146
2 Chinstrap    68
3 Gentoo      119

The names of the vector should correspond to the levels of the outcome. So over_ratio = c(Chinstrap = 0.8, Gentoo = 1) brings Gentoo up to the size of the majority level, and Chinstrap up to 80% of it:

recipe(species ~ bill_length_mm + bill_depth_mm + flipper_length_mm + body_mass_g,
       data = penguins) |>
  step_smote(species, over_ratio = c(Chinstrap = 0.8, Gentoo = 1)) |>
  prep() |>
  bake(new_data = NULL) |>
  count(species)

# A tibble: 3 × 2
  species       n
  <fct>     <int>
1 Adelie      146
2 Chinstrap   117
3 Gentoo      146

Levels you don’t name are left untouched, as are rows with a missing outcome. Two things to keep in mind: supplying a vector means the argument can no longer be tuned, and step_rose() still requires a single number, because its over_ratio scales the size of the total generated sample rather than setting a per-class target. The new article on over_ratio and under_ratio walks through both arguments in more detail.

Tracking synthetic rows

Every up-sampling step gains an indicator_column argument. Give it a name and the final data gets a logical column marking which rows the step added:

smote_res <- recipe(class ~ x + y, data = circle_example) |>
  step_smote(class, indicator_column = "synthetic") |>
  prep() |>
  bake(new_data = NULL)

count(smote_res, class, synthetic)

# A tibble: 3 × 3
  class  synthetic     n
  <fct>  <lgl>     <int>
1 Circle FALSE        58
2 Circle TRUE        284
3 Rest   FALSE       342

This will mostly be useful as a diagnostic tool, or to help visualize how these methods work in practice.

smote_res |>
  ggplot(aes(x, y, color = synthetic)) +
  geom_point(alpha = 0.7) +
  labs(
    title = "Synthetic minority observations created by step_smote()",
    color = "Synthetic"
  ) +
  theme_minimal()

More distance metrics

Most of the steps in this package are built on some calculation that has to do with nearest neighbors. And so far all of them had been using Euclidean distances. We have added a distance argument to every step that deals with neighbors, letting you choose a different distance metric.

manhattan_res <- recipe(class ~ x + y, data = circle_example) |>
  step_smote(class, distance = "manhattan", indicator_column = "synthetic") |>
  prep() |>
  bake(new_data = NULL)

count(manhattan_res, class, synthetic)

# A tibble: 3 × 3
  class  synthetic     n
  <fct>  <lgl>     <int>
1 Circle FALSE        58
2 Circle TRUE        284
3 Rest   FALSE       342

The class counts are unchanged, since those are set by over_ratio rather than by the metric. What changes is where the synthetic observations land, because a different metric picks different nearest neighbors to interpolate between.

Acknowledgements

A big thank you to everyone who has contributed issues, pull requests, and discussion since the last release! @3styleJam, @Dodothereal, @EmilHvitfeldt, @FvD, @jeroenjanssens, @SAY-5, and @topepo.

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

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

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

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

Announcements

Register for posit::conf(2026)

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

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

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

Migrating to Connect Cloud

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

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

Key product updates and new releases

httr2 1.3.0

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

• Read more in the httr2 1.3.0 blog post.

ir 0.1.0

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

• Read more in the ir 0.1.0 blog post.

lorax

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

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

mcptools 1.0.0

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

• Read more in the mcptools 1.0.0 blog post.

Quarto 1.10

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

• Read more in the Quarto 1.10 blog post.

raghilda v0.2

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

• Check out the raghilda v0.2 blog post.

roxygen2 8.1.0

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

• Check out the roxygen2 8.1.0 blog post.

Shiny updates

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

• Read more in the Shiny updates blog post.

Positron learning resources

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

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

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

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

Let’s learn about AI

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

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

Do you want event recordings? You got them!

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

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

Jun 30, 2026 | 12 min | 2.7k views

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

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

Teun Van den Brand

ggsql

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

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

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

Rich Iannone

Great Docs pkgdown

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

Jul 24, 2026 | 51 min | 1.1k views

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

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

dplyr ggplot2 Shiny systemfonts

Jul 23, 2026 | 56 min | 3.8k views

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

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

Emil Hvitfeldt

Positron Quarto revealjs

We hope you learn a lot from these resources!

Showcases from the community

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

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

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

• Forum discussion
• About the skill
• SKILL.md

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

• Check out the spotlight

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

• Forum discussion
• Shiny app

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

What’s next

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

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

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

install.packages("roxygen2")

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

Merged importFrom() directives

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

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

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

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

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

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

Faster documenting with rdtools

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

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

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

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

Acknowledgements

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

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

pip install -U shiny

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

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

Agent skills

Shiny for Python only — coming to R soon.

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

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

uvx library-skills --claude

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

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

Non-blocking apps

Shiny for R only.

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

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

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

# Stop the app
handle$stop()

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

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

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

Offcanvas panels

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

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

library(shiny)
library(bslib)

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

from shiny.express import ui

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

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

library(shiny)
library(bslib)

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

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

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

shinyApp(ui, server)

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

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

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


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


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

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

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

Module cleanup

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

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

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

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

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


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

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

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

Test mode

Shiny for Python only.

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

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

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

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


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


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


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

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

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

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

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

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

Other improvements

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

R

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

Python

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

In closing

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

Acknowledgements

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

Shiny for R v1.14.0

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

bslib v0.12.0

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

Shiny for Python v1.7.0

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

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

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

Accessibility Checking Improvements

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

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

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

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

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

Learn more at HTML Accessibility.

Localized Strings in Templates

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

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

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

Learn more at Localized Strings in Templates.

Other Important Fixes

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

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

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

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

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

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

Dependency updates:

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

Acknowledgements

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

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

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

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

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

Environment management

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

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

Interactive data exploration

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

Streamlined version control

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

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

AI assistance

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

Get started

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

For the full feature reference, check out our documentation.

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

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

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