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.

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.

Orbital’s whole pitch is that a trained model becomes SQL, so a database can run predictions on its own, with no Python process anywhere near it. Until 0.6.0, “trained model” meant scikit-learn: pipelines, trees, linear models, all .fit() in Python and then turned into a SELECT statement. It never covered what a lot of teams are actually training now: PyTorch models, not scikit-learn pipelines.

Orbital 0.6.0 closes that gap. A torch.nn.Sequential network, trained exactly the way you already train it, now compiles to the same kind of SQL a linear regression would.

No ONNX Runtime. No model server. No separate inference service to keep alive next to the database. Just a query.

Why does that work at all, for a framework Orbital was never written for? Because of a decision made long before PyTorch was ever on the table.

Why this isn’t a bolt-on

Orbital was never really a scikit-learn tool. Underneath, it converts a scikit-learn pipeline to ONNX (Open Neural Network Exchange, a standard graph format for trained models) using the skl2onnx library, then walks that graph node by node to produce SQL. Scikit-learn was always one hop removed from what Orbital actually translates.

Adding PyTorch meant taking the same hop from a different starting point. torch.onnx.export turns a torch.nn.Sequential model into that same kind of graph. Feed it into the translator that already existed, and the translator doesn’t know or care whether the graph came from PyTorch or scikit-learn.

The proof is in how little new code that took. The entire engine for running a feed-forward network in SQL is three small classes: a Gemm translator for Linear layers, ReLU, Sigmoid. Everything else (the translator base class, the optimizer, the per-dialect SQL compiler) already existed, built earlier for trees and linear models.

When I first thought of support for PyTorch, I put it this way: “the underlying translation works on ONNX graphs… the same value proposition orbital already provides for scikit-learn models can apply as it is to pytorch networks exported to ONNX.” That sentence turned out to be the whole implementation plan.

If you want the fuller picture of how a graph becomes SQL, parser, then translator, then optimizer, the architecture docs walk through all three stages in order.

That architecture is also why I keep calling this multiple frameworks, not two frameworks. Relu, Sigmoid, Tanh, and Softmax are single translators, not one per framework. Scikit-learn’s MLPClassifier and MLPRegressor reach them through MatMul and Add, PyTorch’s nn.Sequential reaches the exact same translators through Gemm. One implementation, two entry points, and no reason it has to stop at two.

Scikit-learn and PyTorch are both real and shipping today, which is enough on its own to call this “multiple frameworks.” But the dependency story is already moving that direction: issue #113 proposes turning scikit-learn itself into an optional dependency, the same way PyTorch already is, so the core stops assuming any particular framework at all.

Making it actually usable

Neural networks are layered, and every neuron in layer two reads every output of layer one. If Orbital just inlines those outputs at each place they’re read, instead of naming them once, that repetition compounds from one layer to the next. Two layers doubles the inlined text. Five layers is a different order of magnitude.

That’s not theoretical: the issue that tracked the fix measured scikit-learn’s own default MLPClassifier(hidden_layer_sizes=(100,)), the first thing anyone reaches for, at 53MB of generated SQL and roughly 894 seconds just to generate it. A hundred neurons in one hidden layer, and the query was already unusable.

PyTorch’s Gemm translator never had this problem. It has called preserve(), materializing its output as a real SQL column, since the day it was written. Scikit-learn’s MLPClassifier and MLPRegressor compile through different ONNX ops though: MatMul then Add, because that’s what skl2onnx emits, not Gemm. Neither of those translators called preserve() at all.

The fix, Optimizer.preserve_referenced_outputs(), runs after every single node in the translation loop, for every translator, not just MatMul and Add, and checks how many times that node’s output is actually referenced downstream. Referenced more than once, it gets materialized as a named column. Referenced once or not at all, it stays inlined, no extra column, no extra noise.

None of this is new machinery either. Tree ensembles already lean on the same trick: preserve() materializes per-tree votes, or the whole ensemble’s aggregated vote so it isn’t re-emitted everywhere it’s read, as real SQL columns. preserve_referenced_outputs() generalizes that same idea automatically, for every translator, whether it’s part of an ordinary pipeline or a neural network.

Here’s what that fix was worth, measured on three shapes while it was being built:

Generation time collapsed just as hard: the 20→64→64→1 network above went from about 185 seconds to about 3.6 seconds. Running the resulting SQL got faster too, if less dramatically: on 200,000 rows, an MLP(32,32) query dropped from 0.43s to 0.35s, and an MLP(100,100) from 3.58s to 3.31s.

Same hyperparameters. Same defaults everyone actually reaches for. The difference is entirely in how the SQL gets built, not in what the network computes.

What it can do today

Neural network support in 0.6.0 covers binary classification, multiclass classification, and regression, for both scikit-learn and PyTorch. Five new or updated examples in the repo prove it out: pytorch_fraud_detector.py, pytorch_maintenance_classifier.py, pytorch_demand_regressor.py, pipeline_mlp_classifier.py, pipeline_mlp_regressor.py.

The one worth walking through is the fraud detector, since it’s the shape most teams actually need: a handful of numeric features, a binary “is this fraud” output, trained the same way this kind of model always is.

FEATURES = {
    "amount": orbital.types.DoubleColumnType(),
    "hour": orbital.types.DoubleColumnType(),
    "v1": orbital.types.DoubleColumnType(),
    "v2": orbital.types.DoubleColumnType(),
}

model = torch.nn.Sequential(
    torch.nn.Linear(len(FEATURES), 16),
    torch.nn.ReLU(),
    torch.nn.Linear(16, 8),
    torch.nn.ReLU(),
    torch.nn.Linear(8, 1),
    torch.nn.Sigmoid(),
)

# ... train model normally: Adam, BCELoss, a plain training loop ...

orbital_pipeline = orbital.parse_pytorch_model(model, FEATURES)

From that one orbital_pipeline, two engines:

duckdb_sql = orbital.export_sql("transactions", orbital_pipeline, dialect="duckdb")
postgres_sql = orbital.export_sql("transactions", orbital_pipeline, dialect="postgres")

I ran both, against a real DuckDB and a real Postgres, not just read the generated text. Same four test transactions, three ways to compute a prediction (PyTorch itself, the DuckDB query, the Postgres query), and all three agree to within 1e-5. Both queries land around 10KB, not the tens of megabytes a naive translation would have produced before 0.6.0’s optimizer fix.

That works because Sigmoid and ReLU both compile to plain arithmetic: EXP, a division, a CASE WHEN. Every SQL engine has those. It’s not an accident which activation this example uses, either: Tanh compiles to a native TANH() call instead, and not every dialect implements that the same way, so it’s the one activation in Orbital’s NN support with an actual portability caveat attached.

DuckDB and Postgres are two of the three dialects Orbital actively tests in CI. SQLite is the third. But that’s a testing choice, not an architecture boundary: Orbital doesn’t write dialect-specific SQL at all. Translation ends at ibis. export_sql just hands the finished expression to whichever of ibis’s own backend compilers matches the dialect you ask for, and ibis ships about twenty of those: Snowflake, BigQuery, Trino, MySQL, and so on.

Limits, honestly

What Orbital 0.6.0 handles is feed-forward, fully connected networks: stacks of Linear layers with ReLU, Sigmoid, Tanh, or Softmax in between. That already covers real use cases people put into production: fraud scoring, churn, demand forecasting, risk models. None of those need a CNN or a transformer.

What it doesn’t do yet is exactly what that shape excludes: no convolutions, no recurrence, no attention, no embedding layers for categorical features. If your model needs any of those, Orbital isn’t there yet.

SQL size still grows with the network. A few hidden layers of 64 to 128 neurons land comfortably in the KB range. Wider or deeper than that, it’s worth checking the generated SQL against whatever statement-size limit your engine has, before you deploy it.

That headroom exists at all thanks to Optimizer.preserve_referenced_outputs(), and that mechanism helps every translator in Orbital, not just neural networks. It’s a big enough story on its own that I’ll get back to in a future post.

Try it

pip install orbital[pytorch]

From there, the getting-started guide walks through this same fraud-detector shape end to end, and the examples directory has five more, covering classification and regression in both frameworks.

Orbital speaks PyTorch now. Scikit-learn too. Same query either way.

There are more frameworks already in the works. I won’t name them here, only that the architecture was built for exactly this.

How do you know which model to use and when? Often, it’s not a question of which model is best, but of which model suits your task and needs at a given time. You might switch between models for different projects (package development vs. data analysis), or even within a single project (planning vs. implementation). Different tasks require a different mix of cost, token usage, speed, intelligence, and capabilities.

If you want our most durable, high-level advice: start with the most expensive model you have access to from either OpenAI or Anthropic.¹ Then, once you have a sense of the “ceiling,” try less expensive models and see how they compare. Developing a feel for what’s possible with LLMs will help you make better decisions about trade-offs.

That said, we’ll try to tackle this question more thoroughly in this post.

The model landscape

Currently, Anthropic and OpenAI set the bar for AI capabilities. Google is often discussed as a third frontier lab, though its current model lineup is less competitive.

Anthropic and OpenAI each release a “family” of models: Claude and GPT, respectively. The most capable models in both families are also the slowest and most expensive. Conversely, the least capable models are the cheapest and quickest. Other labs tend to follow this same pattern, releasing a set of models with different trade-offs along the cost-performance curve.

Models within a given family tend to share a similar shape of intelligence, with related capabilities (relative to model size), shortcomings, and idiosyncrasies. For example, Claude Fable 5, Claude Opus 5, and Claude Sonnet 5 often use the same turns of phrase and are quite good at writing code and debugging it. Models from different families can have different shapes of intelligence even when their benchmark scores and prices are very similar. For example, GPT-5.6 Terra and Claude Sonnet 5 are priced similarly and comparably capable at agentic coding, but Terra doesn’t “see” data visualizations as well as Sonnet, while Sonnet doesn’t communicate as clearly as Terra.

Other labs release models that score nearly as high as models from Anthropic and OpenAI on benchmarks. However, these evaluation scores can be deceiving. Labs can now train models to optimize for benchmarks (“benchmaxxing”). These models score well on benchmark-shaped tasks, which tend to be highly autonomous and “tricky,” but can fail to generalize to real-world tasks, which often involve more ambiguous requests. Kimi K3 and GLM 5.2 offer a counterexample: they score well on benchmarks, and we’ve also found them exceptionally well-rounded and intuitive. We recently introduced both models to Posit AI.

In previous newsletters and blog posts, we’ve shared results from targeted evaluations. Here, instead, we offer an approximate and entirely vibes-based comparison of these model families’ characteristics.

For data science applications broadly, you can loosely think of the relevant score as the average of the agentic coding and vision scores we’ve assigned here. Beyond writing R and Python code, models need to be able to interpret plots accurately and faithfully.

Find the model that fits your task

Much of model choice is constrained by the models you have access to. Your organization may only allow a certain provider, or you might not want to pay multiple (possibly expensive!) subscriptions just to have access to all the top models.

If you do have your pick, however, here are some quick guidelines, partially shaped by what models are currently available through Posit AI.

The best open-weights model, especially for data analysis: Kimi K3.

As Simon wrote in the Kimi K3 and GLM 5.2 in Posit AI announcement post, “Kimi K3 is currently the most capable open weights model out there. In our internal testing, it feels somewhere between Opus 5 and Fable 5, and is notably well-rounded compared to other open weights releases.”

It also ranks near the top in bluffbench2 (13.46%, compared with 16.35% for the tied top scorers, Gemini 3.5 Flash and Claude Fable 5), which evaluates models’ abilities to spot subtle data quality issues in visualizations.²

A highly autonomous model for a complex coding or data task when cost and speed aren’t a concern: Claude Opus 5, Claude Fable 5, or GPT-5.6 Sol.

These are the top-of-the-line models from Anthropic and OpenAI. They are expensive and relatively slow, but can be worth using for ambitious or highly autonomous work.

A strong open-weights model for coding when you don’t need vision: GLM 5.2 (from Z.ai).

“GLM 5.2 excels at agentic coding and less so at data analysis tasks.” It is much less expensive than the proprietary models it resembles for coding tasks, but it does not natively support image inputs.

A middle-tier generalist for coding or data analysis: Claude Sonnet 5 or GPT-5.6 Terra. Both are capable across coding and routine data analysis, support vision, and are less expensive than their respective labs’ higher-tier models.

Good plot or image interpretation: One of the Gemini 3.x Flash models (3.7 was released on August 13).

This model series is particularly strong at vision and has performed well on bluffbench (3.5 Flash) and bluffbench2 (3.5 and 3.6 Flash).

Fast answers from an Anthropic model for a task that is not particularly complex: Claude Haiku 4.5.

Fast answers from an open-weights model for a task that is not particularly complex: Gemma 4.

Assorted notes from August 2026

In late summer 2026, a few developments feel notable, but, as with much in the AI world, who knows how long these observations will hold.

• Google Gemini currently does not have any models that perform near the frontier. With the releases of Gemini 2.5 Pro (June 2025) and the Gemini 3 series (November 2025), Google seemed positioned as a third frontier lab. However, it’s been quite a while since they released a frontier model, and they’re now meaningfully behind. As of the time of writing, Google says Gemini 3.5 Pro is still testing with partners. Meanwhile, the company has begun training Gemini 4 and says it is excited by the progress.

• For a year or so, it seemed like Anthropic was solidly ahead of OpenAI in agentic coding. However, since the Claude 4.6 releases, it has become less clear that Anthropic is meaningfully ahead of OpenAI. For one, Anthropic’s current high-end models use newer tokenizers that, according to Anthropic, produce roughly 35% more tokens for the same text than their predecessors. This means the same listed price per token does not necessarily translate to the same cost for comparable text. Further, in our experience, the Claude series has become increasingly token-hungry and difficult to communicate with. At the same time, OpenAI’s models have a notably clear, concise communication style compared with the Claude 5 series. Anthropic is still likely ahead on autonomous, long-horizon coding, but OpenAI no longer feels behind for day-to-day software engineering and data science.³

• There are now a number of balanced, well-rounded open-weights models relatively close to the closed-weights frontier. Kimi K3 and GLM 5.2, in particular, combine strong capabilities with a more pleasant, intuitive feel than their predecessors. While earlier open-weights models were just as close to the frontier in benchmark scores, some newer releases are notably more well-rounded and respond to prompts about as effectively as proprietary models. These releases are also priced at a steep discount compared with the proprietary models they most resemble.

Recent past newsletters

• Keep track of your data exploration with Posit Assistant’s EDA log
• Which models are best at spotting subtle data quality problems?

Subscribe via RSS

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

Data Connections

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

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

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

Inline output for Quarto

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

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

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

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

AI model providers

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

Install missing packages

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

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

Performance and memory

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

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

What’s coming next

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

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

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

Pricing

The models in Posit AI today, at a glance:

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

Get started

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

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

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

Why we made this

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

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

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

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

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

Details

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

At a high level:

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

Recent past newsletters

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

Subscribe via RSS

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

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

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

How the eval works

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

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

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

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

plot bmi vs cholesterol

Tool: Run R code

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

Designing the eval

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

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

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

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

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

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

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

• Previous
• Current

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

Exploring the eval’s results

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

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

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

More bluffbench

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

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

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

1: Understand how Positron discovers your environment

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

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

2. Use the Interpreter Selector

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

3. Install Python with uv

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

4. Manage packages with the Packages Pane

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

5. View package documentation

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

6. Start projects with New Folder from Template

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

7. Make use of the Command Palette

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

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

8. Let Posit Assistant help manage your environment

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

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

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

Positron Notebook Editor

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

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

Packages pane

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

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

Posit Assistant

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

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

Data Explorer

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

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

R language intelligence

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

What’s coming next

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

To install the package, run:

install.packages("mcptools")

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

library(mcptools)

Images in tool results

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

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

library(ellmer)

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

Running that function:

tools$fetch_reference_image()

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

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

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

MCP Servers on Posit Connect

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

engine: mcptools
tools: tools.R

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

Fetch tools as R functions from authenticated MCP servers

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

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

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

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

Now looks like:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posit news

Posit Assistant in Positron

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

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

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

Package updates

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

This post walks through the major additions. The package’s fundamentals have not changed (stores, chunkers, retrievers, and the pattern for connecting to chatlas all work as before), but the surface area for building and maintaining stores in production has grown substantially.

The crawl and ingest API

The largest change in v0.2 is a new API for crawling sources and ingesting them into a store. In v0.1, building a store meant calling read_as_markdown() on individual URLs, chunking each result, and upserting them one by one. That works for a handful of pages, but it becomes unwieldy for larger collections, where you also want caching (to avoid re-fetching unchanged content) and concurrency (to finish in minutes rather than hours).

The new API introduces a clean separation between crawling and storage. On the crawl side, a crawler object produces MarkdownDocument objects from a defined scope. On the store side, store.ingest() consumes those documents lazily, applies an optional preparation step (typically chunking), and writes them to the store with configurable parallelism. The pipeline looks like this:

from raghilda.chunker import MarkdownChunker
from raghilda.crawl import CrawlScope, WebCrawler
from raghilda.embedding import EmbeddingOpenAI
from raghilda.store import DuckDBStore

crawler = WebCrawler(cache_dir=".cache/crawl", max_workers=4)

scope = CrawlScope(
    roots=["https://example.com/docs"],
    include_patterns=["https://example.com/docs/**"],
    depth=2,
)

documents = crawler.markdown_documents(scope)

store = DuckDBStore.create(
    location="raghilda.duckdb",
    embed=EmbeddingOpenAI(),
    overwrite=True,
)

summary = store.ingest(
    documents,
    prepare=MarkdownChunker(chunk_size=1000).chunk,
    max_workers=4,
)

print(summary)

IngestSummary(inserted=142, replaced=0, skipped=0)

The CrawlScope dataclass defines the traversal policy: root URLs, include/exclude patterns, depth limits, and page count caps. The crawler handles the mechanics of fetching and converting pages to Markdown, while the scope tells it where to go. This separation means you can change the backend (swap WebCrawler for CloudflareCrawler, for instance) without redefining the scope, and vice versa.

Three concrete crawlers ship with v0.2. DirectoryCrawler walks local file trees and converts supported formats to Markdown. WebCrawler fetches pages over HTTP using requests and converts them locally. CloudflareCrawler delegates both fetching and rendering to Cloudflare’s Browser Rendering API (the right tool for sites that load content through JavaScript). All three implement the same interface: origins() to discover pages, fetch_raw() and fetch_markdown() for single-page access, and markdown_documents() for the full pipeline.

Caching is built into the crawler layer. When you pass cache_dir=True (or an explicit path), each crawler stores fetched content and converted Markdown in a flat directory of files with metadata sidecars. On subsequent runs, cached entries are reused if they are still fresh. For WebCrawler and CloudflareCrawler, freshness is controlled by cache_stale_after=, a timedelta that defines how long a cached entry remains valid. This makes interrupted workflows resumable without any explicit checkpoint logic: rerun the script and the cache supplies everything that was already fetched, while only new or stale pages trigger network requests.

Concurrency operates on both sides of this boundary independently. The crawler can fetch and convert pages in parallel (controlled by max_workers= on the crawler constructor), and store.ingest() can write to the store concurrently (controlled by its own max_workers= argument). For WebCrawler, the breadth-first frontier is explored concurrently while preserving stable output order, so results come back in a consistent sequence regardless of which pages respond first.

CloudflareCrawler

The CloudflareCrawler moves the work of a crawl off the local machine. Instead of fetching pages and converting them to Markdown with local processes, it hands both jobs to Cloudflare’s Browser Rendering API, so a long crawl over a large site runs on Cloudflare’s distributed infrastructure rather than competing for local CPU and bandwidth. For collections large enough that concurrent local requests become the bottleneck, this is the primary reason to reach for it: the slow, sustained part of building a store happens remotely, and what returns is ready-to-chunk Markdown. The same arrangement resolves a problem that defeats a plain HTTP fetch, because the API renders each page in a real browser, executing JavaScript and waiting for the DOM to settle before extracting content. Sites built with React, Vue, or Angular, which an ordinary request reduces to an empty shell, are therefore handled without extra configuration or a locally installed headless browser.

The usage looks almost identical to WebCrawler, because both share the same crawl interface. The key difference is that the constructor takes Cloudflare credentials instead of an HTTP session, and Cloudflare’s infrastructure handles the rendering remotely (so there is no need to install Playwright, Selenium, or any other local headless browser):

import os
from raghilda.crawl import CloudflareCrawler, CrawlScope

crawler = CloudflareCrawler(
    account_id=os.environ["CLOUDFLARE_ACCOUNT_ID"],
    api_token=os.environ["CLOUDFLARE_API_TOKEN"],
    cache_dir=True,
    render=True,
    max_workers=4,
)

scope = CrawlScope(
    roots=["https://my-spa-docs.example.com/"],
    depth=2,
    include_patterns=["https://my-spa-docs.example.com/**"],
    limit=500,
)

documents = crawler.markdown_documents(scope)

Iterating the result performs the crawl lazily, yielding one MarkdownDocument per page. Each document exposes the page’s origin alongside its rendered Markdown content, so a quick pass confirms that the JavaScript-rendered pages came back with real text rather than the empty shells a plain HTTP fetch would have produced:

for doc in documents:
    print(doc.origin, f"({len(doc.content):,} chars)")

https://my-spa-docs.example.com/ (3,214 chars)
https://my-spa-docs.example.com/guide/install (5,902 chars)
https://my-spa-docs.example.com/guide/config (8,477 chars)
https://my-spa-docs.example.com/api/reference (12,043 chars)

The render=True default tells Cloudflare to execute JavaScript before extracting content. For server-rendered sites where JavaScript execution is unnecessary, setting render=False reduces crawl time and API usage. The source= parameter controls how pages are discovered: "all" (the default) combines multiple discovery methods, "sitemap" reads from the site’s sitemap.xml, "crawl" follows links from the rendered DOM, and "urls" processes only the explicitly provided roots.

For stores that need regular updates, the modified_since= parameter restricts the crawl to pages modified after a given Unix timestamp, keeping refresh jobs lightweight. Combined with the crawl cache and the store’s own deduplication (identical documents are not re-embedded), an incremental update script can run daily without redundant work:

import time
from datetime import timedelta

one_week_ago = int(time.time()) - (7 * 24 * 60 * 60)

crawler = CloudflareCrawler(
    account_id=os.environ["CLOUDFLARE_ACCOUNT_ID"],
    api_token=os.environ["CLOUDFLARE_API_TOKEN"],
    cache_dir=True,
    cache_stale_after=timedelta(days=1),
    modified_since=one_week_ago,
)

The tradeoff is cost: CloudflareCrawler requires a Cloudflare account with Browser Rendering access. For static HTML sites where a plain HTTP fetch returns the full content, WebCrawler remains the simpler and free option. Both crawlers share the same interface, so switching between them requires only a constructor change.

PostgreSQL store

raghilda v0.1 shipped with three store backends: DuckDB (local, zero-config), ChromaDB, and OpenAI Vector Stores. v0.2 adds PostgreSQLStore, backed by psycopg2 and pgvector. This is the natural choice for production deployments where the store needs to be shared across services, or where you already have PostgreSQL infrastructure.

from raghilda.store import PostgreSQLStore
from raghilda.embedding import EmbeddingOpenAI

store = PostgreSQLStore.create(
    connection="postgresql://user:pass@localhost:5432/mydb",
    embed=EmbeddingOpenAI(),
    name="docs_store",
    overwrite=True,
)

The store supports full-text search via PostgreSQL’s native tsvector/tsquery with a pre-computed column and GIN index, vector similarity search via pgvector with HNSW indexes (supporting cosine, L2, and inner product distance metrics), and combined retrieval that merges both result sets with deoverlap support.

Retrieval uses the same interface as every other backend: a single retrieve() call returns a ranked list of chunks, each carrying its similarity score under metrics and its heading-hierarchy context. Running a query against a store populated with the raghilda documentation returns the most relevant chunks first:

results = store.retrieve("How are vector indexes configured?", top_k=2)

for r in results:
    print(f"Score: {r.metrics[0].value:.4f}")
    print(r.context)
    print(r.text)
    print("---")

Score: 0.5142
# PostgreSQL store
Vector similarity search runs through pgvector with HNSW indexes,
supporting cosine, L2, and inner product distance metrics. Call
build_index() after ingestion to create them.
---
Score: 0.4417
# PostgreSQL store > Combined retrieval
Combined retrieval merges the vector and full-text result sets and
applies deoverlap to drop redundant overlapping chunks, returning a
single ranked list from one retrieve() call.
---

Attributes work as expected: scalar types map to columns, struct types map to JSONB, and attribute filters can query into JSONB fields using the ->> operator. The build_index() method creates HNSW indexes after ingestion, and the vss_index= parameter on create() controls the default index type.

Connection strings are accepted directly in create() and connect(), so you can point the store at any PostgreSQL instance with pgvector installed. If the pgvector extension is missing, the store raises an informative error rather than failing cryptically on the first vector operation.

NVIDIA NIM embeddings

The embedding layer gains a new provider: EmbeddingNVIDIA, which connects to NVIDIA’s OpenAI-compatible embedding API. The default model is nvidia/llama-nemotron-embed-1b-v2, a compact embedding model suitable for retrieval workloads. The provider reads its API key from the NVIDIA_API_KEY environment variable.

from raghilda.embedding import EmbeddingNVIDIA

embedding = EmbeddingNVIDIA()

One notable feature of NVIDIA’s embedding API is differentiated input types: queries and documents are embedded with different prefixes ("query" and "passage"), which can improve retrieval quality for asymmetric search where the query is short and the documents are long. raghilda handles this distinction automatically when the store calls the embedding provider during ingestion and retrieval.

The provider includes built-in rate limit handling with exponential backoff. NVIDIA’s 429 responses carry no Retry-After header or rate limit metadata, so backoff is the only viable strategy. For users who want to keep embedding computation entirely local, NVIDIA NIM can also be self-hosted, in which case you point the provider at your local endpoint with a base_url= override.

Improved DuckDB error messages

A smaller but practical improvement: DuckDBStore now raises clear, actionable errors when BM25 retrieval is attempted before the index has been built, or after writes have made the index stale. Previously, this produced a cryptic CatalogException from DuckDB about a missing match_bm25 function. The new message tells you exactly what to do:

RuntimeError: DuckDBStore retrieval requires a current BM25 index.
Call `store.build_index("bm25")` after inserting or updating documents
and before calling `retrieve_bm25()` or `retrieve()`.

The store now tracks BM25 freshness internally: the index is marked stale after any upsert() call and marked current after build_index("bm25"). This tracking happens off the retrieval hot path, so there is no per-query overhead. HNSW indexes are unaffected because DuckDB maintains them across writes automatically.

Why even use raghilda?

raghilda is a retrieval library, not an orchestration framework. Larger projects like LangChain and LlamaIndex offer composable retrieval components too, but they also ship agent runtimes, chain abstractions, prompt management, and memory systems. If all you need is the retrieval pipeline (crawl, chunk, embed, store, retrieve), raghilda gives you that without the surrounding framework. The API surface is small: plain dataclasses, iterators, and direct function calls. There are fewer layers of indirection between your code and the underlying operations, which makes the pipeline easier to debug and reason about.

raghilda v0.2 makes that focused scope practical at scale. The crawl API adds caching and concurrency while keeping each step a separate, inspectable call. The storage layer lets you start with a local DuckDB file and move to PostgreSQL or OpenAI Vector Stores later without changing retrieval code. And every backend provides hybrid retrieval (semantic search, BM25, and attribute filtering combined in a single retrieve() call) out of the box, without assembling separate retriever classes or configuring a pipeline graph.

Getting started

raghilda v0.2 is available now on PyPI (pip install raghilda). The raghilda documentation site covers all of the features described here in more detail. The Getting Started guide walks through building a store from scratch, and the Crawling and Ingestion guide covers the new crawl API in depth. A dedicated CloudflareCrawler guide explains browser rendering, page discovery, caching, and incremental updates. The GitHub repository has the source, issue tracker, and full changelog. If you run into problems or have feature requests, open an issue there.