Toolbars

Toolbars are a new set of compact components designed to fit controls into tight spaces — card headers and footers, input labels, and text areas. They’re perfect for dashboards that are running out of room, or for AI chat interfaces where you want to add controls without cluttering the layout.

The core components are:

Each input also has a corresponding ui.update_toolbar_input_*() function for updating it dynamically.

from faicons import icon_svg
from shiny.express import input, render, ui

with ui.card(full_screen=True):
    with ui.card_header():
        "Header"
        with ui.toolbar(align="right"):
            ui.toolbar_input_button(
                id="action1",
                label="Refresh",
                icon=icon_svg("arrows-rotate"),
            )
            ui.toolbar_divider()
            ui.toolbar_input_select(
                id="options",
                label="Filter",
                choices=["ABC", "CDE", "EFG"],
            )

    @render.text
    def toolbar_status():
        return f"Button clicks: {input.action1()}, Selected: {input.options()}"

from faicons import icon_svg
from shiny.express import ui

with ui.card():
    ui.card_header("Data Settings")
    ui.input_slider(
        "threshold",
        label=ui.toolbar(
            ui.toolbar_input_button(
                "threshold_info",
                label="About this setting",
                icon=icon_svg("circle-info"),
                tooltip="Standard deviations from the mean before a value is flagged as an outlier.",
            ),
            "Outlier threshold",
            align="left",
        ),
        min=1,
        max=5,
        value=2,
        step=0.5,
    )
    ui.input_numeric(
        "sample_size",
        label=ui.toolbar(
            ui.toolbar_input_button(
                "sample_info",
                label="About this setting",
                icon=icon_svg("circle-info"),
                tooltip="Number of observations to draw from the dataset for each analysis run.",
            ),
            "Sample size",
            align="left",
        ),
        value=100,
        min=10,
        max=1000,
        step=10,
    )

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

ui.page_opts(fillable=False)

messages = reactive.value([])

with ui.card(full_screen=True, height="250px"):
    ui.card_header("Message Composer")
    with ui.card_body():
        ui.input_submit_textarea(
            "message",
            label="Message",
            placeholder="Compose your message...",
            rows=4,
            toolbar=ui.toolbar(
                ui.toolbar_input_select(
                    "priority",
                    label="Priority",
                    choices=["Low", "Medium", "High"],
                    selected="Medium",
                    icon=icon_svg("flag"),
                ),
                ui.toolbar_divider(),
                ui.toolbar_input_button(
                    "attach",
                    label="Attach",
                    icon=icon_svg("paperclip"),
                ),
                align="right",
            ),
        )

with ui.card(full_screen=True, height="250px"):
    ui.card_header("Sent Messages")

    with ui.card_body():
        @render.ui
        def messages_output():
            msg_list = messages.get()
            if not msg_list:
                return ui.p("No messages sent yet.", style="color: #888;")

            return ui.div(
                *[
                    ui.p(
                        f"[{msg['priority']}] {msg['text']}",
                        style="margin: 4px 0;",
                    )
                    for msg in reversed(msg_list)
                ]
            )

@reactive.effect
@reactive.event(input.message)
def _():
    message_text = input.message()
    if message_text and message_text.strip():
        current_messages = list(messages.get())
        current_messages.append(
            {"text": message_text, "priority": input.priority()}
        )
        messages.set(current_messages)

OpenTelemetry

Starting with Shiny v1.6.0, OpenTelemetry support is built directly into the framework.

OpenTelemetry (OTel) is a vendor-neutral observability standard that lets you collect telemetry data — traces, logs, and metrics — and send it to any compatible backend. For Shiny apps, this means you can finally answer questions like:

• Why is my app slow for certain users?
• Which reactive expressions are taking the most time?
• How long does it take for outputs to render?
• What sequence of events occurs when a user interacts with my app?

pip install logfire
logfire auth

export SHINY_OTEL_COLLECT=reactivity

pip install "shiny[otel]"

In closing

We’re excited to bring you these new features in Shiny v1.6. As always, if you have questions or feedback, join us on Discord or open an issue on GitHub. Happy Shiny-ing!

Hello, querychat

In short, querychat makes it easy to query data using natural language. It offers a drop-in component for Shiny, a console interface, and other programmatic building-blocks. You ask questions, querychat translates it to a SQL query, executes it, and returns the results. The results are available as a reactive data frame, which makes it easy to display or further process the data.

querychat would solve the problem we encountered earlier. We can ask it any question we can imagine without constantly adding filters or other analysis. No country filter? No problem. And yes, that sounds as cool as it is!

So, what do we need?

querychat is powered by a Large Language Model (LLM), so you need access to a model. You first need to register at an LLM provider that provides those models. You can choose any model you like, with two little “restrictions”: chatlas (Python) or ellmer (R) supports it (which shouldn’t be hard, because all the major models are) and the model has the ability to do tool calls.

Once you’ve made your choice and registered, you can get an API key. You need this key to authenticate with the LLM provider. One important note: never, ever hardcode the key directly into your script. You’ll be amazed how many keys are publicly available on GitHub repos. Don’t be that developer. As always with secrets, store it as an environment variable. Just note that the exact name of the key depends on the provider. For example, Anthropic expects ANTHROPIC_API_KEY=yourkey, while OpenAI uses OPENAI_API_KEY=yourkey.

ANTHROPIC_API_KEY=yourkey

from dotenv import load_dotenv
load_dotenv()

ANTHROPIC_API_KEY=yourkey

Of course we can’t use querychat without installing it, so that’s the next step:

pip install querychat

uv add querychat

import querychat

install.packages("querychat")

pak::pak("posit-dev/querychat/pkg-r")

library(querychat)

Wouldn’t it be great if you can use querychat straight away without much code? Just to see what it’s all about? Luckily you can with the “quick launch” Shiny app! You can simply call app() which spins up an app with querychat chat interface. Let’s try it out for our diamonds dataset:

from seaborn import load_dataset
from querychat import QueryChat

diamonds = load_dataset("diamonds")
qc = QueryChat(diamonds, "diamonds", client="anthropic/claude-sonnet-4-5")
app = qc.app()

shiny run --reload diamonds-app.py 

library(ellmer)
library(ggplot2)

querychat_app(diamonds, client = "claude/claude-sonnet-4-5")

library(ellmer)
library(ggplot2)

qc <- QueryChat$new(
  diamonds,
  "diamonds",
  client = "claude/claude-sonnet-4-5"
)

qc$app()

The result: a Shiny app that allows users to interact with a data source using natural language queries.

You can ask the diamonds dataset some surprisingly rich questions, and querychat handles them with ease. A simple place to begin is something like “show the 10 most expensive diamonds”. It produces straightforward SQL and updates the table in the app instantly.

SELECT * FROM diamonds ORDER BY price DESC LIMIT 10

The question may be simple, but it already highlights the convenience of querychat. Without it, users would need to sort the table manually or rely on a picker, slider or some other input that filters the data for this very specific request.

Things get more interesting when we introduce a calculation. Asking “can you show the 20 biggest diamonds, based on volume?” still results in simple SQL, but the output now includes an extra column, volume, which appears neatly in the app.

-- Calculate volume (x * y * z) and sort by largest volume
SELECT *, 
       x * y * z AS volume
FROM diamonds 
ORDER BY volume DESC 
LIMIT 20

From there, we can try some grouping and window functions. “Within each cut, what is the most expensive diamond?” works perfectly, showing the grouped results along with the necessary window function behind the scenes.

-- Find the most expensive diamond for each cut type
SELECT 
    cut,
    MAX(price) AS max_price,
    -- Get the details of the diamond with the max price for each cut
    ARG_MAX(carat, price) AS carat,
    ARG_MAX(color, price) AS color,
    ARG_MAX(clarity, price) AS clarity,
    ARG_MAX(depth, price) AS depth,
    ARG_MAX("table", price) AS table_pct
FROM diamonds
GROUP BY cut
ORDER BY max_price DESC

        cut max_price carat color clarity depth table_pct
1   Premium     18823  2.29     I     VS2  60.8        60
2 Very Good     18818  2.00     G     SI1  63.5        56
3     Ideal     18806  1.51     G      IF  61.7        55
4      Good     18788  2.80     G     SI2  63.8        58
5      Fair     18574  2.01     G     SI1  70.6        64

Now, for a grand finale, we can throw in a more analytical question: “are larger physical dimensions always associated with higher price?” This one generates a slightly more complex SQL query, but it also comes with a clear and helpful explanation.

-- Calculate correlation between physical dimensions and price
-- Also look for outliers where small diamonds cost more than large ones
WITH dimension_stats AS (
  SELECT 
    carat,
    x, y, z,
    -- Calculate volume as a proxy for overall size
    x * y * z AS volume,
    price,
    -- Rank by volume and price separately
    RANK() OVER (ORDER BY x * y * z DESC) AS volume_rank,
    RANK() OVER (ORDER BY price DESC) AS price_rank
  FROM diamonds
  WHERE x > 0 AND y > 0 AND z > 0  -- Exclude malformed records
)
SELECT 
  CORR(x, price) AS x_price_correlation,
  CORR(y, price) AS y_price_correlation,
  CORR(z, price) AS z_price_correlation,
  CORR(volume, price) AS volume_price_correlation,
  -- Count cases where rank differences are significant (outliers)
  COUNT(CASE WHEN volume_rank - price_rank > 1000 THEN 1 END) AS large_cheap_diamonds,
  COUNT(CASE WHEN price_rank - volume_rank > 1000 THEN 1 END) AS small_expensive_diamonds
FROM dimension_stats

x_price_correlation        : 0.8872314
y_price_correlation        : 0.8678642
z_price_correlation        : 0.8682064
volume_price_correlation   : 0.9042547
large_cheap_diamonds       : 21082
small_expensive_diamonds   : 21065

The conclusion?

Answer: No, larger physical dimensions are NOT always associated with higher price

While there's a strong positive correlation (~0.90 for overall volume), quality factors can override size.

Correlation Analysis
Volume ↔ Price: 0.90 correlation
X dimension ↔ Price: 0.89 correlation
Y dimension ↔ Price: 0.87 correlation
Z dimension ↔ Price: 0.87 correlation
This means physical size explains about 80-90% of price variation, but not all of it.

The Key Finding
I found over 21,000 cases where small diamonds are more expensive than much larger ones, and vice versa. This happens because quality factors (cut, color, clarity) matter significantly.

Concrete Example
Here's a smaller diamond that costs more per unit volume than typical large diamonds:

Small, premium diamond: 74mm³ volume, 1.41 carat, $9,752 (Ideal cut, H color, VS1 clarity)
This costs $131 per mm³ of volume
Compare this to larger diamonds with lower quality that sell for much less per unit volume due to poor cut, color, or clarity grades.

To encourage further exploration, querychat presents suggestions such as comparing how cut quality affects the price to carat ratio, finding diamonds where clarity has the biggest impact on price, or checking the price difference between the best and worst colour grades for similar sized stones. Yeah, that’s right, you don’t even have to come up with questions yourself.

Some questions result in a filtered table, others result in an explanation with results in the chat window. querychat figures out, based on your question, whether you want an answer straight away, or want to inspect the filtered data yourself. Pretty cool that this only took a few lines of code.

Why this matters: reliability, transparency, reproducibility

What makes the “quick launch” app so powerful is that it is far more than a chat window sitting on top of a dataset. Think back to the questions we explored earlier. We filtered, sorted, computed new columns, grouped data and used window functions. We also looked at analytical relationships without writing a single line of code. And that is only the beginning. If you want to go further, you can hunt for anomalies, create categories, build benchmarks or explore almost any analysis you can imagine. The key is that you never have to think about how to do it. You just ask.

And yes, you could ask all those questions in a typical LLM chat tool. But querychat is different. You are not relying on the model to invent answers or reason about the data internally. Instead, every single question is translated into SQL, executed on the actual dataset and returned exactly as the data dictates. And crucially, the SQL is always shown, so you can see precisely what is being run.

This brings four important benefits:

• Reliability: the LLM does not analyse or transform the raw data itself. It only generates SQL text. querychat handles the execution of that SQL via tool calling so all results come from the real data engine, not from the model’s internal guesswork.
• Transparency: every query reveals the full SQL statement. Nothing is hidden, nothing is adjusted, and you always know how the answer was produced.
• Reproducibility: since every SQL query is visible, analyses can be reused, shared, and audited.
• Safety: querychat’s tools are designed with read-only actions in mind, meaning the LLM is essentially unable to perform destructive actions. However, to fully guarantee no destructive actions on your production database, make sure querychat’s database permissions are read-only!

How it works: tool calling

If you read The Shiny Side of LLMs blog series, you already know a bit about tool calling. In that series we explored how LLMs can call external tools instead of trying to do everything themselves, and querychat is a very practical example of this idea in action.

Tool calling is essentially a bridge between an LLM and your Python or R session. The model does not execute code. Instead, it requests your Python or R session execute a certain function with certain inputs (e.g., a SQL statement). Once Python or R performs the execution, the result is then passed back to the model for interpretation.

So how does tool calling help us here? Well, LLMs have their strengths and weaknesses. They are not great at counting things, creating data summaries or doing basic calculations. But they are excellent at taking natural language and turning it into structured code. SQL that is. This SQL is then executed through a tool call: a function that executes the (read only) SQL. In both Python and R this means the LLM can express your question as a request to call a function with precise arguments, and the host language performs the real work. This makes it all reliable, reproducible, and safe (read only SQL).

Given that, generally speaking, LLMs are very good at writing SQL, it makes perfect sense to ask one to translate your natural language questions into SQL queries. In order to generate SQL that can be executed, the LLM does need to know something about your data: which columns are there, what do they mean, and what type are they? This schema information is shared with the model, but not the raw data. With this information, it produces an SQL query as a tool call. Now, to run SQL you need a database engine. querychat’s weapon of choice: DuckDB. Basically, our diamonds dataset gets turned into a DuckDB database, and generated SQL queries are executed on this database. Then the results are passed back to the LLM so it can say some interesting things about it.

To summarise:

prompt → SQL query → tool call → execute SQL query → return results¹

Tool calling is worth emphasising because it gives us a controlled and predictable interface between LLMs and real code execution. Instead of writing and maintaining your own custom tools, you can turn to querychat. It already provides the functions needed to turn natural language into reliable SQL that Python or R can execute with confidence.

Customising querychat: from chat to toolkit

Alright, enough talking. You now know what querychat can do, and how it does it (high-level). You might even have brilliant ideas for your next app… In that case it would be nice to know how to build your own app with querychat. The Diamonds “quick launch” app from earlier, that you run with qc.app() (Python) or qc$app() (R), consists of a handful of methods that you can find in querychat, and we’re going to use them directly.

The main component is the QueryChat object, which has different arguments and methods.

qc = QueryChat(...)

qc <- QueryChat$new(...)

qc.cleanup()

qc$cleanup()

Beyond chat: bespoke interfaces

Now you know everything there is to know about the QueryChat object. You know how to add a greeting, additional context, and your favourite LLM. However, it’s time to dream bigger and time to get building! Because chatting with your data safely is one thing, but if you truly want to amaze your users you can build an entire dashboard around it. Plots, maps, tables, and value boxes that all update based on the user’s questions. Your own bespoke interface. Before we dive into that, let’s first take a step back and see if we can reconstruct the “quick launch” app.

You need two things if you want to build a Shiny app with querychat:

• The UI component (the chat window)
• A server method that deals with the results

For the UI component, there are two choices: sidebar() or ui(). The difference? ui creates a basic chat interface, while sidebar wraps the chat interface in a (bslib, for the R lovers) sidebar component designed to be used as the sidebar argument to page_sidebar.

If we want to do something with the results that get returned by querychat, we need to make use of the server() method. The server method returns:

• sql: a reactive that returns the current SQL query. And, if you want to run your own queries, you can also call the $sql() method on the QueryChat object to run queries.
• title: a reactive that returns the current title.
• df: a reactive that returns the data frame, filtered and sorted by the current SQL query.

Let’s take a look at a minimal example that rebuilds the “quick launch” app:

from shiny import App, render, ui
from seaborn import load_dataset
from querychat import QueryChat
from pathlib import Path

# ===============================
# Setup
# ===============================
# 1. Initialize QueryChat with custom files
diamonds = load_dataset("diamonds")
diamonds_greeting = Path(__file__).parent / "diamonds_greeting.md"
diamonds_data_description = Path(__file__).parent / "diamonds_data_description.md"
diamonds_extra_instructions = Path(__file__).parent / "diamonds_extra_instructions.md"

qc = QueryChat(
    diamonds,
    "diamonds",
    client="anthropic/claude-sonnet-4-5",
    greeting=diamonds_greeting,
    data_description=diamonds_data_description,
    extra_instructions=diamonds_extra_instructions,
)

# ===============================
# UI
# ===============================
app_ui = ui.page_sidebar(
    # 2. QueryChat sidebar UI component
    qc.sidebar(),
    ui.card(
        ui.card_header("SQL Query"),
        ui.output_text_verbatim("sql_output"),
        fill=False,
    ),
    ui.card(
        ui.card_header(ui.output_text("title")),
        ui.output_data_frame("data_table"),
        fill=True,
    ),
    fillable=True,
    theme=ui.Theme.from_brand(__file__),
)

# ===============================
# Server
# ===============================
def server(input, output, session):
    # 3. QueryChat server component
    vals = qc.server()

    # 4. Use the filtered/sorted data frame reactively
    @render.data_frame
    def data_table():
        return vals.df()

    @render.text
    def title():
        return vals.title() or "Diamonds"

    # 5. Display the generated SQL query
    @render.text
    def sql_output():
        return vals.sql() or "SELECT * FROM diamonds;"

app = App(app_ui, server)

ui.output_ui("sql_output")

@render.ui
def sql_output():
    sql_value = vals.sql() or f"SELECT * FROM {table_name}"
    sql_code = f"```sql\n{sql_value}\n```"
    return output_markdown_stream(
        "sql_code",
        content=sql_code,
        auto_scroll=False,
        width="100%",
    )

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

# ===============================
# Setup
# ===============================
# 1. Initialize QueryChat with custom files
qc <- QueryChat$new(
  diamonds,
  "diamonds",
  client = "claude/claude-sonnet-4-5",
  greeting = "diamonds_greeting.md",
  data_description = "diamonds_data_description.md",
  extra_instructions = "diamonds_extra_instructions.md"
)

# ===============================
# UI
# ===============================
ui <- page_sidebar(
  title = "Diamonds Explorer",
  # 2. QueryChat sidebar UI component
  sidebar = qc$sidebar(),
  card(
    card_header("SQL Query"),
    verbatimTextOutput("sql_query")
  ),
  card(
    card_header(textOutput("title")),
    DT::DTOutput("data_table")
  )
)

# ===============================
# Server
# ===============================
server <- function(input, output, session) {
  # 3. QueryChat server component
  vals <- qc$server()

  # 3. Display generated SQL query
  output$sql_query <- renderText({
    if (is.null(vals$sql())) {
      return("SELECT * FROM diamonds;")
    }
    vals$sql()
  })

  # 4. Display data table based on user query
  output$data_table <- DT::renderDT({
    vals$df()
  })

  # 5. Dynamic title based on user query
  output$title <- renderText({
    if (is.null(vals$title())) {
      return("Diamonds Data")
    }
    vals$title()
  })
}

shinyApp(ui, server)

Looks pretty similar to the quick launch app, right?! So that’s how it was build. Note that there a few aesthetic differences though. The quick launch app has a few extra sparks here and there, and our app makes use of custom theming with brand.yml.

So far in our diamonds adventure we have only looked at a simple table, but we can extent this idea much further and build an entire dashboard around it: value boxes, graphs, tables, maps, you name it! This is also what sidebot does, and this template is available to get you started quickly. A nice touch is the inclusion of the ✨ icon, which sends a screenshot of the visuals to the LLM for an explanation. How cool is that!

Adding querychat to your existing Shiny app

The idea of sidebot is certainly interesting: why build a dashboard with all kind of filters when you can just add a chat window with access to a smart LLM. You ask it questions, querychat returns some SQL and reactive filtered data, and you make sure you update the entire dashboard. Unlimited filter possibilities. And it doesn’t have to be complicated to achieve that.

To demonstrate how easy it is, we are going to use an existing dashboard (SheScores), that currently has a number of filters in it: a slider for the year(s), a dropdown for the continent where the matches took place, the tournaments that took place on those continents, and a switch that filters the data to include only data with known scorers, or not.

So what does SheScores look like behind the scenes? We’re not going into the nitty gritty details of the SheScores dashboard, and we don’t have to if we want to add querychat to it. The most important bit of logic is stored in a reactive that contains the filtered data. It reacts to changes in any of the inputs (year, continent, tournament, scorer only or not).

The reactive, filtered_data(), forms the basis for all the elements in the dashboard: the value boxes, the map, the graph, and the table.

# ===============================
# Setup
# ===============================
results_with_scorers = pd.read_csv(
    Path(__file__).parent.parent / "data/results_with_scorers.csv"
)

results_with_scorers["date"] = pd.to_datetime(results_with_scorers["date"])

results_with_scorers = results_with_scorers[
    (results_with_scorers["tournament"] != "Friendly")
    & (results_with_scorers["date"] >= "2000-01-01")
]

# ===============================
# UI
# ===============================
app_ui = ui.page_sidebar(
    ui.sidebar(
        ui.h4("Filters"),
        ui.input_slider(
            "year_filter",
            "Select year range:",
            min=int(results_with_scorers["date"].dt.year.min()),
            max=int(results_with_scorers["date"].dt.year.max()),
            value=[
                int(results_with_scorers["date"].dt.year.min()),
                int(results_with_scorers["date"].dt.year.max()),
            ],
            sep="",
        ),
        ui.input_selectize(
            "continent_filter",
            "Select continents:",
            choices=sorted(
                results_with_scorers["continent"].dropna().unique().tolist()
            ),
            selected="Europe",
            multiple=True,
        ),
        ui.input_select(
            "tournament_filter",
            "Select tournaments:",
            choices=[],
            selected=[],
            multiple=True,
        ),
        ui.input_switch(
            "scorer_only", "Show matches with scorer data only", value=False
        ),
        width="30%",
    ),
    # Other UI content
    # ...
    title="She Scores ⚽️: Women's International Soccer Matches",
    fillable=False,
    theme=ui.Theme.from_brand(__file__),
)

# ===============================
# Server
# ===============================
def server(input, output, session):
    # Reactive filtered data based on inputs
    @reactive.calc
    def filtered_data():
        req(len(input.continent_filter()) > 0)
        req(len(input.tournament_filter()) > 0)

        data = results_with_scorers.copy()
        data = data[
            (data["date"].dt.year >= input.year_filter()[0])
            & (data["date"].dt.year <= input.year_filter()[1])
            & (data["continent"].isin(input.continent_filter()))
            & (data["tournament"].isin(input.tournament_filter()))
        ]

        if input.scorer_only():
            data = data[data["scorer"].notna()]

        return data
    
    # Other server logic
    # ...
    
app = App(app_ui, server)

# ===============================
# Setup
# ===============================
results_with_scorers <- read.csv("../data/results_with_scorers.csv") |>
  filter(tournament != "Friendly", date >= "2000-01-01")

# Other setup
# ...

# ===============================
# UI
# ===============================
ui <- page_sidebar(
  fillable = FALSE,
  title = "She Scores ⚽️: Women's International Soccer Matches",
  sidebar = sidebar(
    title = "Filters",
    width = "30%",
    # Year filter
    sliderInput(
      inputId = "year_filter",
      label = "Select year range:",
      min = year(min(as.Date(results_with_scorers$date))),
      max = year(max(as.Date(results_with_scorers$date))),
      value = c(
        year(min(as.Date(results_with_scorers$date))),
        year(max(as.Date(results_with_scorers$date)))
      ),
      sep = ""
    ),
    # Continent filter (dropdown)
    pickerInput(
      inputId = "continent_filter",
      label = "Select continents:",
      choices = sort(unique(results_with_scorers$continent)),
      selected = sort(unique(results_with_scorers$continent)),
      options = pickerOptions(
        actionsBox = TRUE,
        selectedTextFormat = "count > 1",
        countSelectedText = "{0} continents selected"
      ),
      multiple = TRUE
    ),
    # Tournament filter (dropdown)
    pickerInput(
      inputId = "tournament_filter",
      label = "Select tournaments:",
      choices = NULL,
      selected = NULL,
      options = pickerOptions(
        actionsBox = TRUE,
        liveSearch = TRUE,
        liveSearchPlaceholder = "Search for a tournament",
        selectedTextFormat = "count > 1",
        countSelectedText = "{0} tournaments selected"
      ),
      multiple = TRUE
    ),
    # Switch to show data with scorers only
    input_switch(
      id = "scorer_only",
      label = "Show matches with scorer data only",
      value = FALSE
    ),
  )
  # Other UI content
  # ...
)

# ===============================
# Server
# ===============================
server <- function(input, output, session) {
  # Reactive filtered data based on inputs
  filtered_data <- reactive({
    req(length(input$continent_filter) > 0)
    req(length(input$tournament_filter) > 0)

    results_with_scorers |>
      mutate(date = as.Date(date)) |>
      filter(
        year(date) >= input$year_filter[1],
        year(date) <= input$year_filter[2],
        continent %in% input$continent_filter,
        tournament %in% input$tournament_filter,
        if (input$scorer_only) {
          !is.na(scorer)
        } else {
          TRUE
        }
      )
  })

  # Other server logic
  # ...
}

shinyApp(ui, server)

Now we want to get rid of all those filters. We want a chat window instead. What do we need to change in order to use querychat? Spoiler alert: not much.

Of course we need to initialise our QueryChat object. And since we’re not talking about diamonds, we need to make sure to provide a proper soccer-themed greeting, a data description, and extra instructions:

shescores_greeting.md:

# Welcome to SheScores! ⚽

I'm here to help you explore international women's soccer match data. 
You can ask me to filter and sort the dashboard, answer questions about the data, 
or provide insights about teams, players, tournaments, and more.

## Here are some ideas to get started:

**Explore match data:**
  * <span class="suggestion">Show me the highest-scoring matches in World Cup tournaments</span>
  * <span class="suggestion">Which teams have played the most matches against each other?</span>
  * <span class="suggestion">Filter to matches from the 2025 UEFA Euro</span>
  * <span class="suggestion">Which team has the best win rate in the Canada vs United States rivalry?</span>
  
**Analyze player performance:**
  * <span class="suggestion">Who are the top scorers in World Cup history?</span>
  * <span class="suggestion">Which players have scored the most penalty goals?</span>
  * <span class="suggestion">Which matches had the most own goals?</span>

What would you like to explore?

shescores_data_description.md:

# Dataset description
This dataset contains international women’s football match results. 
It includes match metadata (date, location, teams), outcomes (scores), 
plus optional event-level information such as individual scorers. 
Not all friendly matches are represented; 
major tournaments are mostly complete.

# Column descriptions
- date (string, YYYY-MM-DD): The calendar date on which the match was played.
- home_team (string): Name of the home team.
- date (string, YYYY-MM-DD): The calendar date on which the match was played.
- home_team (string): Name of the home team.
- away_team (string): Name of the away team.
- home_score (integer): Goals scored by the home team at full time (extra time included, - penalty shoot-outs excluded).
- away_score (integer): Goals scored by the away team at full time (extra time included, - penalty shoot-outs excluded).
- tournament (string): Name of the competition or event.
- city (string): City or administrative area where the match was played.
- country (string): Country where the match was played.
- neutral (boolean): Indicates whether the match took place at a neutral venue.
- team (string, optional): Team associated with a recorded scoring event.
- scorer (string, optional): Player who scored the goal.
- minute (integer, optional): Match minute in which the goal occurred.
- own_goal (boolean, optional): Indicates whether the goal was an own goal.
- penalty (boolean, optional): Indicates whether the goal was scored from a penalty kick.
- country_flag_home (string): Emoji or symbol representing the home country.
- country_flag_away (string): Emoji or symbol representing the away country.
- continent (string): Continent associated with the home country.
- country_code (string): Country code associated with the home team (e.g., ISO-like).
- latitude (float): Latitude of the match location.
- longitude (float): Longitude of the match location.
- match_id (string): Unique identifier for the match, typically based on date and team names.

shescores_extra_instrucions.md:

- Maintain consistent spelling in British English.
- Don't add any extra columns to the dataset. You may use them internally 
  for calculations, but the final output should only include the original 
  columns with the original column names.
- Soccer terminology should be used throughout the analysis 
  (e.g., "goal" instead of "point").

Now, adding querychat into the mix is as simple as replacing our inputs in the sidebar with the querychat sidebar component (sidebar()), and our reactive with the results of server().

# ===============================
# Setup
# ===============================
results_with_scorers = pd.read_csv(
    Path(__file__).parent.parent / "data/results_with_scorers.csv"
)

results_with_scorers["date"] = pd.to_datetime(results_with_scorers["date"])

results_with_scorers = results_with_scorers[
    (results_with_scorers["tournament"] != "Friendly")
    & (results_with_scorers["date"] >= "2000-01-01")
]

# 1. Initialize QueryChat with custom files
shescores_greeting = Path(__file__).parent / "shescores_greeting.md"
shescores_data_description = Path(__file__).parent / "shescores_data_description.md"
shescores_extra_instructions = Path(__file__).parent / "shescores_extra_instructions.md"

qc = QueryChat(
    results_with_scorers,
    "results_with_scorers",
    client="anthropic/claude-sonnet-4-5",
    greeting=shescores_greeting,
    data_description=shescores_data_description,
    extra_instructions=shescores_extra_instructions,
)

# Other setup
# ...

# ===============================
# UI
# ===============================
app_ui = ui.page_sidebar(
    qc.sidebar(),
    # Other UI components
    # ...
    title="She Scores ⚽️: Women's International Soccer Matches",
    fillable=False,
    theme=ui.Theme.from_brand(__file__),
)

# ===============================
# Server
# ===============================
def server(input, output, session):
    # Reactive filtered data based on query
    filtered_data = qc.server()
    
    # Other server logic
    # ...
    
app = App(app_ui, server)

# ===============================
# Setup
# ===============================
results_with_scorers <- read.csv("../data/results_with_scorers.csv") |>
  filter(tournament != "Friendly", date >= "2000-01-01")

# 1. Initialize QueryChat with custom files
qc <- QueryChat$new(
  results_with_scorers,
  "results_with_scorers",
  client = "claude/claude-sonnet-4-5",
  greeting = "shescores_greeting.md",
  data_description = "shescores_data_description.md",
  extra_instructions = "shescores_extra_instructions.md"
)

# Other setup
# ...

# ===============================
# UI
# ===============================
ui <- page_sidebar(
  fillable = FALSE,
  title = "She Scores ⚽️: Women's International Soccer Matches",
  sidebar = qc$sidebar(),
  # Other UI components
  # ...
)

# ===============================
# Server
# ===============================
server <- function(input, output, session) {
  # Reactive filtered data based on query
  filtered_data <- qc$server()

  # Other server logic
  # ...
  
}

shinyApp(ui, server)

It results in a lot less code and logic too. Win-win. Thanks querychat !

Database options

So far we’ve only worked with simple datasets: the diamonds dataset that ships with a package, and our soccer data loaded from a .csv. But here’s how it works under the hood: even in those examples, you weren’t really querying a data frame directly. querychat hands everything off to DuckDB, which becomes the engine that executes all generated SQL. And DuckDB does so quickly and efficiently. Your data frame or .csv is effectively registered inside DuckDB, and every answer comes from real SQL running on that engine.

But what if you don’t want to work with in-memory tables at all? What if you already have a database you want to query directly? Maybe a DuckDB file, a SQLite database, Postgres, or even BigQuery? That’s exactly what the data_source argument is for. Earlier we used it with plain data frames, but it also accepts database connections. In Python, that means any SQLAlchemy-supported database; in R, anything that DBI can handle. querychat will inspect the schema of whatever you connect, and from that moment on the workflow is identical as before, only now you’re interacting with your own database.

Let’s take a look at how to set up querychat with another backend (SQLite) using the data_source argument.

from pathlib import Path
from sqlalchemy import create_engine

# From results_with_scorers.csv, create a SQLite database named shescores.db
df_path = Path(__file__).parent.parent / "data/results_with_scorers.csv"

df = pd.read_csv(df_path)

# Create the SQLite database and store the DataFrame in it
# Save database in top-level /data directory
df.to_sql(
    "results_with_scorers",
    con=create_engine(
        "sqlite:///" + str(Path(__file__).parent.parent / "data/shescores.db")
    ),
    if_exists="replace",
    index=False,
)

from pathlib import Path
from sqlalchemy import create_engine
from querychat import QueryChat
from dotenv import load_dotenv

load_dotenv()

# Custom files for SheScores
shescores_greeting = Path(__file__).parent / "shescores_greeting.md"
shescores_data_description = Path(__file__).parent / "shescores_data_description.md"
shescores_extra_instructions = Path(__file__).parent / "shescores_extra_instructions.md"

# Now create a QueryChat instance to interact with the database
db_path = Path(__file__).parent.parent / "data/shescores.db"
engine = create_engine(f"sqlite:///{db_path}")

qc = QueryChat(
    engine,
    "results_with_scorers",
    client="anthropic/claude-sonnet-4-5",
    greeting=shescores_greeting,
    data_description=shescores_data_description,
    extra_instructions=shescores_extra_instructions,
)

app = qc.app()

library(DBI)

# From results_with_scorers.csv, create a SQLite database named shescores.db
results_with_scorers <- read.csv("data/results_with_scorers.csv")

# Create a connection to a new SQLite database
# Save database in top-level /data directory
conn <- dbConnect(RSQLite::SQLite(), "data/shescores.db")

# Write the data frame to a table named results_with_scorers
dbWriteTable(
  conn,
  "results_with_scorers",
  results_with_scorers,
  overwrite = TRUE
)

dbDisconnect(conn)

library(querychat)
library(DBI)

# Create a connection to a SQLite database
conn <- dbConnect(RSQLite::SQLite(), "data/shescores.db")

# Write the data frame to a table named results_with_scorers
dbWriteTable(
  conn,
  "results_with_scorers",
  results_with_scorers,
  overwrite = TRUE
)

# Now create a QueryChat instance to interact with the database
qc <- QueryChat$new(
  conn,
  "results_with_scorers",
  client = "claude/claude-sonnet-4-5",
  greeting = "shescores_greeting.md",
  data_description = "shescores_data_description.md",
  extra_instructions = "shescores_extra_instructions.md"
)

qc$app()

querychat knows how to deal with databases, and it has some convenient features for it too, especially when things go wrong: it validates whether tables actually exist and handles any issues gracefully (without cryptic error messages).

One thing to keep in mind when you move from in-memory data to real databases, especially inside Shiny apps, is proper connection management. Whenever your app opens a database connection, it also needs to close it. In Python that usually means calling engine.dispose() when the app shuts down. In R you would use dbDisconnect(conn), or rely on a connection pool. SQLAlchemy already provides pooling on the Python side, but in R you’ll want the pool package to handle this in a nice manner.

For the curious: how does querychat know what to do?

You’ve seen what querychat can do, and you know a bit how it works conceptually. But behind all those concepts is of course some real code. So, for the curious amongst us, here’s a little peek into the querychat code!

To talk with an LLM you need a good prompt: prompt design is crucial for a good outcome. A prompt contains context and instructions that an LLM will use to come up with its answer. querychat has a set of instructions for the LLM too, the system prompt, which is stored in a Markdown file (prompt.md).

print(qc.system_prompt)

print(qc$system_prompt())

So, what’s in this prompt? Let’s highlight a few bits:

You have access to a {{db_type}} SQL database with the following schema:

<database_schema>
{{schema}}
</database_schema>

{{#data_description}}
Here is additional information about the data:

<data_description>
{{data_description}}
</data_description>
{{/data_description}}

For security reasons, you may only query this specific table.

{{#extra_instructions}}
## Additional Instructions

{{extra_instructions}}
{{/extra_instructions}}

The prompt is a Mustache template. It’s a fill-in-the-blanks template: the {name} parts get replaced with real values, and the {#something} ... {{/something}} blocks only appear if that “something” actually exists. When you call QueryChat with corresponding arguments, everything gets filled in.

We talked about tool calling earlier, and there was a little note that said that there’s not just one tool. There are multiple, for different tasks. You can see that back clearly in the prompt, where we instruct the LLM to call a certain tool (e.g. querychat_update_dashboard) when it receives a request:

You can handle three types of requests:

### 1. Filtering and Sorting Data

...

- Call `querychat_update_dashboard` with the query and a descriptive title

...

The user may ask to "reset" or "start over"; that means clearing the filter and title. Do this by calling querychat_reset_dashboard().

### 2. Answering Questions About Data

...

- Use the `querychat_query` tool to run SQL queries

...

### 3. Providing Suggestions for Next Steps

...

There are three tools in querychat:

• querychat_query: used whenever the user asks a question that requires data analysis, aggregation, or calculations.
• querychat_update_dashboard: used whenever the user requests filtering, sorting, or data manipulation on the dashboard with questions like “Show me…” or “Which records have…”. Basically any request that involves showing a subset of the data or reordering it.
• querychat_reset_dashboard: if the user asks to reset the dashboard

All the tools are written as chatlas or ellmer tools. As a user, you don’t have to worry about this though. The LLM makes sure to use the rights tools, which will make sure the SQL gets executed and the data gets filtered accordingly. But hey, this section was for the curious amongst us!

Safety, control, and confidence

At some point, everyone asks the same question: is this safe? And it’s a fair one. Luckily, querychat is designed entirely around control. The LLM never executes anything itself, never touches your data(base) and never sees raw data. Its only job is to propose read-only SQL.

Remember the moment we asked it to drop a table? It refused. Not because it’s polite, but because it’s instructed to do so. Combine that with an underlying database (the built-in DuckDB temporary database or your own) that only provides read-only access, and your data will always be left untouched. 

It’s not a black box either: every generated query can be logged, inspected or audited at any time. In Shiny v1.12.0 this becomes even easier thanks to built in OpenTelemetry support via otel. If you’re curious about what that looks like in practice, you can read more in this article.

The safety, control, and (hopefully) the confidence you’ve gained by now, make it also suitable for enterprise and regulated environments. If you need to use private or managed LLMs, you’re covered: Azure, AWS Bedrock and Google Vertex AI all provide versions of popular models that support tool calling and can work with querychat.

Other querychat apps in the wild

It’s always nice to see what others have done with querychat. So here are few sources of inspiration:

• Do you like trail running? This Race Stats dashboard is for you!
• Is the American football league more your thing? This Shiny for Python app shows you a lot of stats.
• Joe Cheng and Garrick Aden-Buie hosted a workshop at posit::conf(2025) called “Programming with LLMs” that also contains some examples.
• And one that we mentioned before: sidebot, a dashboard analysing restaurant tipping, which is a template you can use very easily.

Whether you’re playing with a small example dataset or building something much bigger, querychat can be the companion in your app that you’re users will love. Build a whole dashboard around the chatbot, or add a touch of LLM magic for those extra side questions. With all this knowledge under your belt, you can build it all!

Understanding OpenTelemetry

Before we dive into what’s new in Shiny, let’s talk about OpenTelemetry—a topic that might sound intimidating but is actually quite straightforward once we cover the basics.

OpenTelemetry in Shiny

If you’ve ever wondered…

• “Why is my app slow for some users when hosted? Which reactive expressions are causing the slowdown?”
• “How long does it take for my plot to render? Is it the data or the plotting code that is taking longer to calculate?”
• “What’s the sequence of events leading up to when a user clicks that button?”
• “How often are errors occurring in my app, and under what conditions?”

Normally, we can attempt to answer these questions using {reactlog} (a package to replay the recording of a reactive graph) or {profvis} (a package to profile R code in the main R process). However, both of these packages are not built for production use. These debugging tools are only to be used locally as they would be considered a memory leak in production.

OpenTelemetry allows us to record information at scale with minimal overhead, helping you answer previously impossible questions about your production environment. OpenTelemetry provides visibility into your app’s performance and behavior, helping you identify bottlenecks, debug issues, and optimize user experience—especially crucial when your app is deployed in production with real-world usage.

pak::pak(c("shiny", "otel", "otelsdk"))

.Renviron

# Enable OpenTelemetry by setting Collector environment variables
OTEL_TRACES_EXPORTER=http
OTEL_LOGS_EXPORTER=http
OTEL_LOG_LEVEL=debug
OTEL_METRICS_EXPORTER=http

OTEL_EXPORTER_OTLP_ENDPOINT="https://logfire-us.pydantic.dev"
OTEL_EXPORTER_OTLP_HEADERS="Authorization=<your-write-token>"

app.R

library(shiny)

# Create tool that grabs the weather forecast (free) for a given lat/lon
# Inspired from: https://posit-dev.github.io/shinychat/r/articles/tool-ui.html
get_weather_forecast_basic <- ellmer::tool(
  function(lat, lon) {
    weathR::point_tomorrow(lat, lon, short = FALSE)
  },
  name = "get_weather_forecast",
  description = "Get the weather forecast for a location.",
  arguments = list(
    lat = ellmer::type_number("Latitude"),
    lon = ellmer::type_number("Longitude")
  )
)

ui <- bslib::page_fillable(
  shinychat::chat_mod_ui("chat", height = "100%")
)
server <- function(input, output, session) {
  # Set up client within `server` to not _share_ the client for all sessions
  client <- ellmer::chat_claude("Be terse.")
  client$register_tool(get_weather_forecast_basic)

  chat_server <- shinychat::chat_mod_server("chat", client, session)

  # Set chat placeholder on app init
  observe({
    chat_server$update_user_input("What is the weather in Atlanta, GA?")
  }, label = "set-default-input")
}

shinyApp(ui, server)

# Only trace session lifecycle, not every reactive calculation
options(shiny.otel.collect = "session")

# Do not trace _Shiny_ reactive expressions within this block
# All other otel spans/logs will still be recorded
withOtelCollect("none", {
  expensive_calculation <- reactive({
    # Start a custom span for this calculation
    otel::start_local_active_span("my custom span", tracer = "my_tracer")
    Sys.sleep(2)  # Simulate a long calculation
    rnorm(1e6)
  })
  output$plot <- renderPlot({
    hist(expensive_calculation())
  })
})

In summary

Whether you’re developing apps locally or managing production deployments, OpenTelemetry support in Shiny now gives you visibility into your applications:

• Developers can debug complex reactive flows
• Performance engineers can identify and eliminate bottlenecks
• Data scientists can understand how users interact with their applications

We’re excited to see how the community uses this powerful new capability. Try it out, and let us know what you think!

While OpenTelemetry support is the star of this release, Shiny v1.12 includes several other nice improvements. For a complete list of changes, check out the NEWS entries for Shiny v1.12.0 and Shiny v1.12.1.

Learn more

For more details on OpenTelemetry in Shiny, check out our dedicated article on OpenTelemetry + Shiny article.

What’s next?

We have big plans for OpenTelemetry in Shiny and the broader R ecosystem. Existing and upcoming enhancements include:

• {mirai} v2.5.0
• {promises} v1.5.0
• {plumber2} (via {fiery} v1.4.0, {reqres} v1.1.0, and {routr} v1.1.0)
• {httr2} v1.2.2
• {knitr} (yihui/knitr)
• {ellmer} (tidyverse/ellmer#526)
• {DBI} (r-dbi/dbi#551)
• {testthat} (r-lib/testthat#2282)

In addition, the Shiny Team’s focus will be shifting to add OpenTelemetry integration to Shiny for Python. Be sure to be on the lookout for the future announcement!

Acknowledgements

A big thank you to all [the folks/everyone] who [helped make this release happen/contributed to this release]:

@andriygm, @BajczA475, @bedantaguru, @billdenney, @chendaniely, @Copilot, @cpsievert, @csgillespie, @deadbytesus, @dempsey-CMAR, @dleopold, @federiva, @federivaFirebird, @fzenoni, @gadenbuie, @gsmolinski, @ismirsehregal, @janxkoci, @JohnADawson, @karangattu, @marcozanotti, @Mkranj, @mm225022, @mmuurr, @nicholasdavies, @r2evans, @schloerke, @shikokuchuo, @simon-smart88, @vedhav, and @wch.

Have questions or feedback? Join the conversation on the Shiny Community forum or GitHub.

Shiny + AI & Intelligent Automation

Speakers	Title	Link
Winston Chang (Shiny Team)	Web applications with Shiny and React (and AI)
Karan Gathani (Shiny Team)	Old Apps, New Tricks: How AI can write Automated Tests for Shiny
Regis A. James	AskRADS: An AI Recommendation Agent for Maximizing Shiny Development

Shiny Architecture, Performance & Data

Speakers	Title	Link
Alex Chisholm	Keeping Data Alive: Persistent Storage Options for Shiny
Melissa Albino Hegeman	Get your ducks in a row… faster Shiny apps with DuckDB
Barret Schloerke (Shiny Team)	Observability at scale: Monitoring Shiny Applications

Shiny UX, UI Design & Accessibility

Speakers	Title	Link
Cameron Race; Sarah Wong-Brown	shinyGovStyle – accessible government design in Shiny
Casey Aguilar-Gervase; Maya Gans	Design of Everyday Shiny Apps
Jeremy Winget, PhD	Death by Dropdown? Engineer Insightful Shiny Apps
Kim Schouten	Modular, layout-as-code approach for customizable Shiny dashboards

Applied Shiny Case Studies

Speakers	Title	Link
Marcus Beck	Shiny for ecological data workflows
Hugo Fitipaldi	Building a Real-Time COVID-19 Surveillance System with Shiny

Closing

We hope you enjoy this roundup of Shiny talks from posit::conf(2025). The Shiny community continues to explore new patterns—AI-assisted development, real-time analytics, performance tooling, design systems, and more. We hope to see you next year at posit::conf—and maybe even see your Shiny work up on stage.

Tool calling UI

Tool calling lets you extend an LLM’s capabilities by giving it access to functions you define. When you provide a tool to the LLM, you’re telling it “here’s a function you can call if you need it.” The key thing to understand is that the tool runs on your machine (or wherever your Shiny app is running) — the LLM doesn’t directly run the tool itself. Instead, it asks you to run the function and return the result.

Both ellmer and chatlas make it easy to define tools and register them with your chat client¹, and they also handle the back-and-forth of tool calls by receiving requests from the LLM, executing the tool, and sending the results back. This means you can focus on what you do best: writing code to solve problems.

Any problem you can solve with a function can become a tool for an LLM! You can give the LLM access to live data, APIs, databases, or any other resources your app can reach.

When the LLM decides to call a tool, shinychat displays the request and result in the chat interface. Users can see which tools are being invoked, what arguments are being passed, and what data is being returned. The tool display is designed to be customizable, so shinychat developers can customize the appearance and display of tool calls to best serve their users.

library(shinychat)
library(ellmer)
library(weathR)

get_weather_forecast <- tool(
  function(lat, lon) {
    point_tomorrow(lat, lon, short = FALSE)
  },
  name = "get_weather_forecast",
  description = "Get the weather forecast for a location.",
  arguments = list(
    lat = type_number("Latitude"),
    lon = type_number("Longitude")
  )
)

# Register the tool with your chat client
chat <- ellmer::chat("openai/gpt-4.1-nano")
chat$register_tool(get_weather_forecast)

from chatlas import ChatOpenAI
import requests

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

# Register the tool with your chat client
chat = ChatOpenAI(model="gpt-4.1-nano")
chat.register_tool(get_weather_forecast)

chat$chat("Will I need an umbrella for my walk to the T?")
#> ◯ [tool call] get_weather_forecast(lat = 42.3515, lon = -71.0552)
#> ● #> [{"time":"2025-11-20 16:00:00 EST","temp":42,"dewpoint":0,"humidity":67,"p_rain":1,"wi…
#>
#> Based on the weather forecast, there is a chance of rain around 4 to 5 PM,
#> with mostly cloudy to partly sunny skies. It seems there might be some rain
#> during this time, so carrying an umbrella could be a good idea if you plan
#> to go out around that time. Otherwise, the weather looks relatively clear
#> in the evening.

server <- function(input, output, session) {
  client <- ellmer::chat("openai/gpt-4.1-nano")
  client$register_tool(get_weather_forecast)

  observeEvent(input$chat_user_input, {
    stream <- client$stream_async(input$chat_user_input, stream = "content")
    chat_append("chat", stream)
  })
}

app.py

from chatlas import ChatOpenAI
from shiny.express import ui
from shinychat.express import Chat

client = ChatOpenAI(model="gpt-4.1-nano")
client.register_tool(get_weather_forecast)

chat = Chat(id="chat")
chat.ui()

@chat.on_user_submit
async def handle_user_input(user_input: str):
    response = await client.stream_async(user_input, content="all")
    await chat.append_message_stream(response)

app.py

from chatlas import ChatOpenAI
from shiny import App, ui
from shinychat import Chat

client = ChatOpenAI(model="gpt-4.1-nano")
client.register_tool(get_weather_forecast)

app_ui = ui.page_fluid(
    Chat(id="chat").ui()
)

def server(input, output, session):
    chat = Chat(id="chat")

    @chat.on_user_submit
    async def handle_user_input(user_input: str):
        response = await client.stream_async(user_input, content="all")
        await chat.append_message_stream(response)

app = App(app_ui, server)

get_weather_forecast <- tool(
  function(lat, lon) {
    point_tomorrow(lat, lon, short = FALSE)
  },
  name = "get_weather_forecast",
  description = "Get the weather forecast for a location.",
  arguments = list(
    lat = type_number("Latitude"),
    lon = type_number("Longitude")
  ),
  annotations = tool_annotations(
    title = "Weather Forecast",
    icon = bsicons::bs_icon("cloud-sun")
  )
)

get_weather_forecast <- tool(
  function(lat, lon, location_name) {
    forecast_data <- point_tomorrow(lat, lon, short = FALSE)
    forecast_table <- gt::as_raw_html(gt::gt(forecast_data))

    ContentToolResult(
      forecast_data,  # This is what the LLM sees
      extra = list(
        display = list(
          html = forecast_table,  # This is what users see
          title = paste("Weather Forecast for", location_name)
        )
      )
    )
  },
  name = "get_weather_forecast",
  description = "Get the weather forecast for a location.",
  arguments = list(
    lat = type_number("Latitude"),
    lon = type_number("Longitude"),
    location_name = type_string("Name of the location")
  ),
  annotations = tool_annotations(
    title = "Weather Forecast",
    icon = bsicons::bs_icon("cloud-sun")
  )
)

from chatlas import ToolResult
import pandas as pd

def get_weather_forecast(lat: float, lon: float, location_name: str):
    """Get the weather forecast for a location."""
    # Get forecast data
    data = fetch_weather_data(lat, lon)

    # Create a DataFrame for the LLM
    forecast_df = pd.DataFrame(data)

    # Create HTML table for users
    forecast_table = forecast_df.to_html(index=False)

    return ToolResult(
        value=forecast_df.to_dict(),  # LLM sees this
        display={
            "html": forecast_table,  # Users see this
            "title": f"Weather Forecast for {location_name}"
        }
    )

tool_with_intent <- tool(
  function(`_intent`) {
    runif(1)
  },
  name = "random_number",
  description = "Generate a random number.",
  arguments = list(
    `_intent` = type_string(
      "Explain why you're generating this number"
    )
  )
)

def random_number(_intent: str) -> float:
    """Generate a random number.

    Args:
        _intent: Explain why you're generating this number
    """
    import random
    return random.random()

Bookmarking support

When a Shiny app reloads, the app returns to its initial state, unless the URL includes bookmarked state.² Automatically updating the URL to include a bookmark of the chat state is a great way to help users return to their work if they accidentally refresh the page or unexpectedly lose their connection.

Both shinychat for R and Python provide helper functions that make it easy to restore conversations with bookmarks. This means users can refresh the page or share a URL and pick up right where they left off.

library(shiny)
library(shinychat)

ui <- function(request) {
  page_fillable(
    chat_ui("chat")
  )
}

server <- function(input, output, session) {
  chat_client <- ellmer::chat_openai(model = "gpt-4o-mini")

  # Automatically save chat state on user input and responses
  chat_restore("chat", chat_client)

  observeEvent(input$chat_user_input, {
    stream <- chat_client$stream_async(input$chat_user_input)
    chat_append("chat", stream)
  })
}

# Enable URL-based bookmarking
shinyApp(ui, server, enableBookmarking = "url")

from chatlas import ChatOllama
from shiny.express import ui

chat_client = ChatOllama(model="llama3.2")

chat = ui.Chat(id="chat")
chat.ui(messages=["Welcome!"])

chat.enable_bookmarking(
    chat_client,
    bookmark_store="url", # or "server"
    bookmark_on="response", # or None
)

from chatlas import ChatOllama
from shiny import ui, App

app_ui = ui.page_fixed(
    ui.chat_ui(id="chat", messages=["Welcome!"])
)

def server(input):
    chat_client = ChatOllama(model="llama3.2")
    chat = ui.Chat(id="chat")

    chat.enable_bookmarking(
        chat_client,
        bookmark_on="response", # or None
    )

app = App(app_ui, server, bookmark_store="url")

Other improvements in shinychat for R

Beyond tool calling UI and bookmarking support, shinychat for R v0.3.0 includes several other enhancements.

server <- function(input, output, session) {
  chat <- chat_mod_server("chat", ellmer::chat_openai())

  # React to user input
  observe({
    req(chat$last_input())
    print(paste("User said:", chat$last_input()))
  })

  # React to assistant responses
  observe({
    req(chat$last_turn())
    print("Assistant completed response")
  })

  # Programmatically control the chat
  observeEvent(input$suggest_question, {
    chat$update_user_input(
      value = "What's the weather like today?",
      submit = TRUE  # Automatically submit
    )
  })

  observeEvent(input$reset, {
    chat$clear()  # Clear history and UI
  })
}

library(bsicons)

# Set a custom icon for a specific response
chat_append(
  "chat",
  "Here's some helpful information!",
  icon = bs_icon("lightbulb")
)

# Or set a default icon for all assistant messages
chat_ui("chat", icon_assistant = bs_icon("robot"))

Learn more

The tool calling UI opens up exciting possibilities for building transparent, user-friendly AI applications. Whether you’re fetching data, running calculations, or integrating with external services, users can now see exactly what’s happening.

To dive deeper:

• Read the tool calling UI article for comprehensive examples in R
• Explore tool calling with ellmer (R) or chatlas (Python)

Acknowledgements

A huge thank you to everyone who contributed to this release with bug reports, feature requests, and code contributions:

@bianchenhao, @cboettig, @chendaniely, @cpsievert, @DavZim, @DeepanshKhurana, @DivadNojnarg, @gadenbuie, @iainwallacebms, @janlimbeck, @jcheng5, @jimrothstein, @karangattu, @ManuelSpinola, @MohoWu, @nissinbo, @noamanemobidata, @parmsam, @PaulC91, @rkennedy01, @schloerke, @selesnow, @simonpcouch, @skaltman, @stefanlinner, @t-kalinowski, @thendrix-trlm, @wch, @wlandau, and @Yousuf28.

Getting Started

promises provides fundamental abstractions for asynchronous programming in R using JavaScript-style promises. It enables a single R process to orchestrate multiple tasks in the background while remaining responsive to other operations. Key features include:

• Promise chaining with then(), catch(), and finally() for handling asynchronous results
• Combinators like promise_all() and promise_race() for coordinating multiple async operations
• Promise domains for managing execution context across asynchronous boundaries (e.g., graphics devices, reactive contexts)

The package uses semantics similar to JavaScript promises but with idiomatic R syntax, making it particularly useful for building responsive Shiny applications, coordinating parallel computations, and managing complex asynchronous workflows.

Install the latest version with:

install.packages("promises")

# Works with both regular values and promises
result <- hybrid_then(
  expr = possible_promise_or_value(),
  on_success = function(x) x * 2,
  on_failure = function(err) stop("Error occurred")
)

promise_that_works() |>
  then(function(value) {
    # Log for debugging without affecting the chain
    cat("Current value:", value, "\n")
  }, tee = TRUE) |>
  then(function(value) {
    # Original value is still available here
    process(value)
  })

# Setup a consistent OpenTelemetry tracer
my_tracer <- otel::get_tracer("my-tracer")

# When using OpenTelemetry (otel) spans that must be active across async
# boundaries, wrap the entire promise chain creation within
# `with_otel_promise_domain()`. Once is enough, but it may be nested.
with_otel_promise_domain({

  # Makes an otel span that persists until the promise chain is resolved.
  # This otel span will be reactivated for each step in the promise chain.
  # This otel span will end when the encapsulated promise chain completes.
  with_otel_span("my-promise-chain", tracer = my_tracer, {

    promise1() |>
      then(\(x) {
        # Make an OpenTelemetry span around `promise2()` promise chain
        # whose parent span is `my-promise-chain`
        with_otel_span("middle-span", tracer = my_tracer, {
          promise2(x) |>
            then(sideeffect2, tee = TRUE)
        })
      }) |>
      then(\(x) {
        # `with_otel_span()` is not needed for _purely_ synchronous work
        # (but may be used if desired!)
        otel::start_local_active_span("last-span", tracer = my_tracer)
        sync3(x)
      })

  }) # `my-promise-chain` span ends here

})

# Inner domain now correctly takes precedence
with_promise_domain(outer_domain, {
  with_promise_domain(inner_domain, {
    promise() |> then(callback)  # inner_domain wraps first
  })
})

Why Shiny?

We knew pretty early on that “DeckCheck” was going to be an app. Why? Because an app is just easier. People can click buttons, type things, and get results without ever touching code (which is great, because “copy-paste this into your terminal” tends to scare off half the audience).

But ok, why Shiny? You’re reading this on the Shiny blog, so yes, it seems pretty obvious we love it. Still, we have solid reasons:

• You can go from idea to something you can actually click in almost no time. Shiny is great for prototyping. You can quickly experiment, gather feedback, and gradually build an app out to a production-ready state.
• Shiny is reactive by design, which is a fancy way of saying: it keeps track of what depends on what, and only updates what actually needs to change. You don’t need to worry about the logic, which means you can spend more time building your app instead of dealing with state management.
• This reactive engine also makes Shiny efficient: outputs only re-render when the stuff they depend on changes.
• If your LLM workflow is in Python, there’s Shiny for Python. If it’s in R, there’s Shiny for R. No language wars or conversations about “X is better than Y”. Just pick whatever you’re comfortable with.
• You can even drop in your own HTML, CSS, and JavaScript to really make it your own.

Alright, enough with the sales pitch. Shiny it is!

Optimising conversations for Shiny

Going from a script-like workflow to an app requires a different way of thinking. We simply have other expectations from a web app compared to just a regular Python or R script. We want things to be interactive, and ideally we want to have the result instantly. If we click on something, we expect something to happen, fast. Ever encountered a web page that stayed blank for just 5 seconds? How long did that feel? Like 10 minutes? Or didn’t you even stick out the 5 seconds? Yes, you are impatient! You need to see something is happening, and get some visual feedback.

LLMs take your impatience into account, and that’s why most models stream tokens progressively. Instead of making you wait forever for a big wall of text, they start showing you the answer bit by bit, almost like they’re thinking out loud. This streaming feels faster, keeps you engaged, and makes the whole experience way less frustrating. chatlas and ellmer use this streaming capability too and they print the result on the console as soon as words come in. But… a Shiny app doesn’t have a console! So what to do?

Where the chat() method does not return any results until the entire response is received and only prints the streaming results to the console, the stream() method can process the response as it arrives. It’s perfect for something like a Shiny chat window. You simply replace the chat() method with the stream() method, which returns something called a “generator”. A generator is a function that can pause (yield) and resume later, remembering where it left off. That’s handy because it lets your code:

1. Process text as it arrives (aka, by chunk) instead of waiting for the whole thing.
2. Pause between chunks without blocking other things.
3. Keep its place so it can pick up right where it left off when the next chunk arrives.

from chatlas import ChatAnthropic

chat = ChatAnthropic(
    model="claude-sonnet-4-20250514",
    system_prompt="You are a presentation coach for data scientists. You give constructive, focused, and practical feedback on titles, structure, and storytelling.",
)

# Set model parameters (optional)
chat.set_model_params(
    temperature=0.8,  # default is 1
)

stream = chat.stream(
    """I'm working on a presentation with the title: 'The Shiny Side of LLMs'.
        Please evaluate the clarity, tone, and relevance of this title for the intended audience.
        For context, this is a 10-minute lightning talk at posit::conf(2025).
        The audience is Python and R users who are curious about AI and large language models,
        but not all of them have a deep technical background.
        
        The talk uses Shiny as a way to explore and demo LLMs in practice.
        
        Return your answer as a JSON array of objects, where each object has the following keys:
        
        - 'aspect': one of 'clarity', 'tone', or 'relevance'
        - 'feedback': your concise assessment
        - 'suggestion': an optional improvement if applicable"""
)

for chunk in stream:
    print(chunk)

library(ellmer)

chat <- chat_anthropic(
  model = "claude-sonnet-4-20250514",
  system_prompt = "You are a presentation coach for data scientists.
  You give constructive, focused, and practical feedback on titles, structure, and storytelling.",
  params = params(
    temperature = 0.8 # default is 1
  )
)

stream <- chat$stream(
  "I'm working on a presentation with the title: 'The Shiny Side of LLMs'.
Please evaluate the clarity, tone, and relevance of this title for the intended audience.
For context, this is a 10-minute lightning talk at posit::conf(2025).
The audience is Python and R users who are curious about AI and large language models,
but not all of them have a deep technical background.

The talk uses Shiny as a way to explore and demo LLMs in practice.

Return your answer as a JSON array of objects, where each object has the following keys:

- 'aspect': one of 'clarity', 'tone', or 'relevance'
- 'feedback': your concise assessment
- 'suggestion': an optional improvement if applicable"
)

coro::loop(
  for (chunk in stream) {
    cat(chunk)
  }
)

Streaming is great for things like chatbots, live transcription, or anything where seeing text appear in real time feels natural. It’s perfect for conversations, or when the answer is long and you don’t want to keep users staring at a blank screen.

In apps like “DeckCheck”, where we’re analysing a Quarto presentation behind the scenes and then showing a finished result, streaming doesn’t really add much. Users expect a clear, polished answer all at once. Not a JSON, but ready-to-go value boxes, graphs and tables. So in this case, a smooth loading indicator or progress bar will probably satisfy impatient users and we can stick to our chat() method. Don’t forget the stream() method though: we’ll use that a little bit later in a small demo chatbot.

Whether we’re streaming or not, users simply have to wait for an LLM response and you can keep them entertained while they’re doing that. But another important thing related to a long waiting time is when your app is used by multiple users at the same time. They might ask things from the model at the same time too, meaning that you’re dealing with concurrent chat sessions. If you would just use chat() or stream(), the Shiny app (or technically speaking: the Python or R session running the Shiny app) will be blocked for other users for the duration of each response. And that’s not cool. The more users are concurrently using your app, the longer the queue gets, and the longer users have to wait. This is synchronous behaviour. We rather deal asynchronously (aka async) with a model’s responses. It means that we can receive responses at the same time, in parallel. To use async chat, we need to call chat_async() / stream_async() instead of chat() / stream(). The _async variants take the same arguments but returns a coroutine object, (aka a placeholder for something that will come) instead of the actual response.

So ideally, asking a question to an LLM would look something like this in our Shiny application:

import asyncio
from chatlas import ChatAnthropic

chat = ChatAnthropic(
    model="claude-sonnet-4-20250514",
    system_prompt="You are a presentation coach for data scientists. You give constructive, focused, and practical feedback on titles, structure, and storytelling.",
)

async def main():
    response = await chat.chat_async(
        """I'm working on a presentation with the title: 'The Shiny Side of LLMs'.
        Please evaluate the clarity, tone, and relevance of this title for the intended audience.
        For context, this is a 10-minute lightning talk at posit::conf(2025).
        The audience is Python and R users who are curious about AI and large language models,
        but not all of them have a deep technical background.
        
        The talk uses Shiny as a way to explore and demo LLMs in practice.
        
        Return your answer as a JSON array of objects, where each object has the following keys:
        
        - 'aspect': one of 'clarity', 'tone', or 'relevance'
        - 'feedback': your concise assessment
        - 'suggestion': an optional improvement if applicable"""
    )
    print(response)

asyncio.run(main())

"""
 [                                                                                                          
   {                                                                                                        
     "aspect": "clarity",                                                                                   
     "feedback": "The title is somewhat ambiguous - 'shiny side' could refer to positive aspects of LLMs or 
 the Shiny framework itself. For an audience not deeply familiar with both topics, this creates confusion   
 about the main focus.",                                                                                    
     "suggestion": "Consider titles like 'Exploring LLMs with Shiny' or 'Building LLM Demos in Shiny' to    
 clearly establish that Shiny is your vehicle for demonstrating LLMs."                                      
   },                                                                                                       
   {                                                                                                        
     "aspect": "tone",                                                                                      
     "feedback": "The tone is appropriately casual and engaging for a lightning talk, with a clever play on 
 words that fits the conference atmosphere. However, it may be too playful for conveying the practical valu 
 of the content.",                                                                                          
     "suggestion": "Balance the wordplay with clearer value proposition, such as 'The Shiny Side of LLMs:   
 Interactive AI Exploration' to maintain engagement while signaling practical benefits."                    
   },                                                                                                       
   {                                                                                                        
     "aspect": "relevance",                                                                                 
     "feedback": "Highly relevant to the posit::conf audience who knows Shiny well, but the connection      
 between Shiny and LLMs isn't immediately clear from the title alone. Given the 10-minute format, you need  
 attendees to quickly understand the value.",                                                               
     "suggestion": "Make the connection more explicit with alternatives like 'Hands-On LLM Exploration with 
 Shiny Apps' or 'From Prompts to Production: LLMs in Shiny' to immediately communicate the practical        
 application."                                                                                              
   }                                                                                                        
 ]                                                                                                          
<chatlas._chat.ChatResponseAsync object at 0x111a5c560>
"""

library(ellmer)
library(promises)

chat <- chat_anthropic(
  model = "claude-sonnet-4-20250514",
  system_prompt = "You are a presentation coach for data scientists.
  You give constructive, focused, and practical feedback on titles, structure, and storytelling."
)

chat$chat_async(
  "I'm working on a presentation with the title: 'The Shiny Side of LLMs'.
Please evaluate the clarity, tone, and relevance of this title for the intended audience.
For context, this is a 10-minute lightning talk at posit::conf(2025).
The audience is Python and R users who are curious about AI and large language models,
but not all of them have a deep technical background.

The talk uses Shiny as a way to explore and demo LLMs in practice.

Return your answer as a JSON array of objects, where each object has the following keys:

- 'aspect': one of 'clarity', 'tone', or 'relevance'
- 'feedback': your concise assessment
- 'suggestion': an optional improvement if applicable"
) %...>% print()

#> [1] "```json\n[\n  {\n    \"aspect\": \"clarity\",\n    \"feedback\": \"The title is somewhat ambiguous - 'shiny side' could mean positive aspects of LLMs or reference the Shiny framework. The wordplay may confuse rather than clarify the content focus.\",\n    \"suggestion\": \"Consider 'Building LLM Demos with Shiny' or 'Interactive LLM Exploration Using Shiny' to clearly communicate both the tool and topic.\"\n  },\n  {\n    \"aspect\": \"tone\",\n    \"feedback\": \"The playful wordplay fits well with the lightning talk format and conference atmosphere. It's approachable and not intimidating for audiences with varying technical backgrounds.\",\n    \"suggestion\": null\n  },\n  {\n    \"aspect\": \"relevance\",\n    \"feedback\": \"Highly relevant for posit::conf audience who are familiar with Shiny. The title connects a trending AI topic with a beloved R/Python tool, making LLMs accessible to the community.\",\n    \"suggestion\": \"Consider adding a subtitle for context: 'The Shiny Side of LLMs: Interactive Demos for AI Exploration' to enhance relevance while keeping the clever wordplay.\"\n  }\n]\n```"

And before you’re thinking: “hey, we were using structured output in the last part, right?” Yes! Luckily there’s also a method called chat_structured_async() (see docs for Python and R). How convenient! We’ll use that a little bit later.

Chatting with an LLM via Shiny

Never developed a Shiny app before? That’s ok! Before building our DeckCheck app, we’ll start with a very basic example that allows you to chat with any LLM, just like you type in your question at ChatGPT. And while this series isn’t about building “just a chatbot”, you can perfectly do so with Shiny. Minimal code required to get started. If you have experience with Shiny this code won’t have much surprises, but if you’re new to Shiny there’s a mini crash-course-like explanation below the code.

from shiny import App, ui
from chatlas import ChatAnthropic

# Define UI
app_ui = ui.page_fluid(
    ui.h1("DeckCheck"),
    # Card with chat component
    ui.card(
        ui.card_header("Get started"),
        ui.p("Ask me anything about your presentation 💡"),
        # Chat component
        ui.chat_ui(id="my_chat"),
    ),
)

# Define server
def server(input, output, session):
    chat = ui.Chat(id="my_chat")

    chat_client = ChatAnthropic(
        model="claude-sonnet-4-20250514",
        system_prompt="You are a presentation coach for data scientists. You give constructive, focused, and practical feedback on titles, structure, and storytelling.",
    )

    @chat.on_user_submit
    async def handle_user_input(user_input: str):
        response = await chat_client.stream_async(user_input)
        await chat.append_message_stream(response)

# Create app
app = App(app_ui, server)

library(shiny)
library(bslib)
library(ellmer)
library(shinychat)

ui <- page_fluid(
  theme = bs_theme(bootswatch = "flatly"),

  # App title
  h1("DeckCheck"),

  # Create a card
  card(
    card_header("Get started"),
    p("Ask me anything about your presentation 💡"),

    # Chat component
    chat_mod_ui("my_chat")
  )
)

server <- function(input, output, session) {
  chat_client <- chat_anthropic(
    model = "claude-sonnet-4-20250514",
    system_prompt = "You are a presentation coach for data scientists. 
  You give constructive, focused, and practical feedback on titles, structure, and storytelling."
  )

  chat_mod_server("my_chat", chat_client)
}

shinyApp(ui, server)

Building DeckCheck

All the ingredients are there now: we know how to programmatically talk to an LLM, we can make an informed choice when it comes to streaming (or not streaming) and async usage, and we’ve seen how to combine it in a simple chat interface (with a bit of help from shinychat). Time to apply that knowledge to our DeckCheck app.

But, first things first… A design. Nothing too fancy, just a quick conceptual drawing of what our app will look like. No matter what kind of app you’re developing, this is always the (and honestly, often overlooked) first step. If you know what you’re building towards, it’s way easier to start coding. Here’s our design:

We have a section where users can upload information (most importantly, the Quarto presentation itself, but also the required information like audience), there are some value boxes, there’s a graph, and a table. Elements you will frequently encounter when developing data-savvy apps. For a reason, of course, as we want to provide you with all the necessary building blocks.

To bring this design to life, here’s what we’re working towards:

But first things first: let’s start with building the basic UI before we connect the server part to it.

from shiny import App, ui
import shinyswatch

# ======================
# Icons
# ======================
# SVG icon copied from https://icons.getbootstrap.com/icons/file-slides-fill/
file_slides = """<svg xmlns="http://www.w3.org/2000/svg" fill="currentColor" class="bi bi-file-slides-fill" viewBox="0 0 16 16">
  <path d="M7 7.78V5.22c0-.096.106-.156.19-.106l2.13 1.279a.125.125 0 0 1 0 .214l-2.13 1.28A.125.125 0 0 1 7 7.778z"/>
  <path d="M12 0H4a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h8a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2M5 4h6a.5.5 0 0 1 .496.438l.5 4A.5.5 0 0 1 11.5 9h-3v2.016c.863.055 1.5.251 1.5.484 0 .276-.895.5-2 .5s-2-.224-2-.5c0-.233.637-.429 1.5-.484V9h-3a.5.5 0 0 1-.496-.562l.5-4A.5.5 0 0 1 5 4"/>
</svg>"""

file_code = """<svg xmlns="http://www.w3.org/2000/svg" fill="currentColor" class="bi bi-file-code-fill" viewBox="0 0 16 16">
  <path d="M12 0H4a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h8a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2M6.646 5.646a.5.5 0 1 1 .708.708L5.707 8l1.647 1.646a.5.5 0 0 1-.708.708l-2-2a.5.5 0 0 1 0-.708zm2.708 0 2 2a.5.5 0 0 1 0 .708l-2 2a.5.5 0 0 1-.708-.708L10.293 8 8.646 6.354a.5.5 0 1 1 .708-.708"/>
</svg>"""

file_image = """<svg xmlns="http://www.w3.org/2000/svg" fill="currentColor" class="bi bi-file-image-fill" viewBox="0 0 16 16">
  <path d="M4 0h8a2 2 0 0 1 2 2v8.293l-2.73-2.73a1 1 0 0 0-1.52.127l-1.889 2.644-1.769-1.062a1 1 0 0 0-1.222.15L2 12.292V2a2 2 0 0 1 2-2m4.002 5.5a1.5 1.5 0 1 0-3 0 1.5 1.5 0 0 0 3 0"/>
  <path d="M10.564 8.27 14 11.708V14a2 2 0 0 1-2 2H4a2 2 0 0 1-2-2v-.293l3.578-3.577 2.56 1.536 2.426-3.395z"/>
</svg>"""

robot = """<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-robot" viewBox="0 0 16 16">
  <path d="M6 12.5a.5.5 0 0 1 .5-.5h3a.5.5 0 0 1 0 1h-3a.5.5 0 0 1-.5-.5M3 8.062C3 6.76 4.235 5.765 5.53 5.886a26.6 26.6 0 0 0 4.94 0C11.765 5.765 13 6.76 13 8.062v1.157a.93.93 0 0 1-.765.935c-.845.147-2.34.346-4.235.346s-3.39-.2-4.235-.346A.93.93 0 0 1 3 9.219zm4.542-.827a.25.25 0 0 0-.217.068l-.92.9a25 25 0 0 1-1.871-.183.25.25 0 0 0-.068.495c.55.076 1.232.149 2.02.193a.25.25 0 0 0 .189-.071l.754-.736.847 1.71a.25.25 0 0 0 .404.062l.932-.97a25 25 0 0 0 1.922-.188.25.25 0 0 0-.068-.495c-.538.074-1.207.145-1.98.189a.25.25 0 0 0-.166.076l-.754.785-.842-1.7a.25.25 0 0 0-.182-.135"/>
  <path d="M8.5 1.866a1 1 0 1 0-1 0V3h-2A4.5 4.5 0 0 0 1 7.5V8a1 1 0 0 0-1 1v2a1 1 0 0 0 1 1v1a2 2 0 0 0 2 2h10a2 2 0 0 0 2-2v-1a1 1 0 0 0 1-1V9a1 1 0 0 0-1-1v-.5A4.5 4.5 0 0 0 10.5 3h-2zM14 7.5V13a1 1 0 0 1-1 1H3a1 1 0 0 1-1-1V7.5A3.5 3.5 0 0 1 5.5 4h5A3.5 3.5 0 0 1 14 7.5"/>
</svg>"""

# ======================
# Shiny App
# ======================
app_ui = ui.page_fillable(
    ui.layout_sidebar(
        ui.sidebar(
            ui.div(
                ui.p(ui.strong("Hey, I am DeckCheck!")),
                ui.p(
                    """I can help you improve your Quarto presentations by analysing them and suggesting improvements. Before I can do that, I need some information about your presentation."""
                ),
            ),
            ui.input_file(
                "file",
                "Upload your Quarto presentation",
                accept=[".qmd", ".qmdx"],
                multiple=False,
            ),
            ui.input_text_area(
                "audience",
                "Describe your audience",
                height="150px",
                placeholder="e.g. Python and R users who are curious about AI and large language models, but not all of them have a deep technical background",
            ),
            ui.input_numeric(
                "length", "Time cap for the presentation (minutes)", value=10, min=1
            ),
            ui.input_text(
                "type",
                "Type of talk",
                placeholder="e.g. lightning talk, workshop, or keynote",
            ),
            ui.input_text("event", "Event name", placeholder="e.g. posit::conf(2025)"),
            ui.input_task_button(
                "submit",
                icon=ui.HTML(robot),
                label="Analyse presentation",
            ),
            width=400,
        ),
        ui.layout_column_wrap(
            ui.value_box(
                "Showtime",
                "9 minutes",
                showcase=ui.HTML(file_slides),
                theme="primary",
            ),
            ui.value_box(
                "Code Savviness",
                "15%",
                showcase=ui.HTML(file_code),
                theme="primary",
            ),
            ui.value_box(
                "Image Presence",
                "7%",
                showcase=ui.HTML(file_image),
                theme="primary",
            ),
            width=1 / 3,
            fill=False,
        ),
        ui.layout_column_wrap(
            ui.card(
                ui.card_header(ui.strong("Scores per category")),
                ui.p("My beautiful interactive plot..."),
            ),
            ui.card(
                ui.card_header(ui.strong("Suggested improvements per category")),
                ui.p("My beatiful table..."),
            ),
            width=1 / 2,
            fill=False,
        ),
    ),
    # Bootswatch theme
    theme=shinyswatch.theme.flatly,
)

def server(input, output, session):
    # Empty for demo purposes
    pass

app = App(app_ui, server)

library(shiny)
library(bslib)

ui <- page_fillable(
  ## General theme and styles
  theme = bs_theme(bootswatch = "flatly"),
  layout_sidebar(
    ## Sidebar content
    sidebar = sidebar(
      width = 400,
      # Open sidebar on mobile devices and show above content
      open = list(mobile = "always-above"),
      strong(p("Hey, I am DeckCheck!")),
      p(
        "I can help you improve your Quarto presentations by analysing them and suggesting improvements.
      Before I can do that, I need some information about your presentation."
      ),
      fileInput(
        inputId = "file",
        label = "Upload your Quarto presentation",
        accept = c(".qmd", ".qmdx")
      ),
      textAreaInput(
        inputId = "audience",
        height = "150px",
        label = "Describe your audience",
        placeholder = "e.g. Python and R users who are curious about AI and large language models, but not all of them have a deep technical background"
      ),
      numericInput(
        inputId = "length",
        label = "Time cap for the presentation (minutes)",
        value = 10
      ),
      textInput(
        inputId = "type",
        label = "Type of talk",
        placeholder = "e.g. lightning talk, workshop, or keynote"
      ),
      textInput(
        inputId = "event",
        label = "Event name",
        placeholder = "e.g. posit::conf(2025)"
      ),
      input_task_button(
        id = "submit",
        label = shiny::tagList(
          bsicons::bs_icon("robot"),
          "Analyse presentation"
        ),
        label_busy = "DeckCheck is checking...",
        type = "default"
      )
    ),
    ## Main content
    layout_column_wrap(
      fill = FALSE,
      ### Value boxes for metrics
      value_box(
        title = "Showtime",
        value = "9 minutes",
        showcase = bsicons::bs_icon("file-slides"),
        theme = "primary"
      ),
      value_box(
        title = "Code Savviness",
        value = "15%",
        showcase = bsicons::bs_icon("file-code"),
        theme = "primary"
      ),
      value_box(
        title = "Image Presence",
        value = "7%",
        showcase = bsicons::bs_icon("file-image"),
        theme = "primary"
      )
    ),
    layout_column_wrap(
      fill = FALSE,
      width = 1 / 2,
      ### Graph with scoring metrics
      card(
        card_header(strong("Scores per category")),
        p("My beatiful interactive plot...")
      ),
      ### Table with suggested improvements
      card(
        card_header(strong("Suggested improvements per category")),
        p("My beatiful table...")
      )
    )
  )
)

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

shinyApp(ui, server)

No matter what language you use to display this basic UI, the result is the same:

That’s already a start! Of course it doesn’t do anything yet and is filled with placeholders, so we need some logic in the server part. The main engine behind DeckCheck is our conversation with the LLM. This logic is almost a copy-paste from part two, Talking to LLMs: From Prompt to Response, combined with what we learned earlier in this article about async.

The star of this main engine is something called “extended task”. As mentioned previously, by default, Shiny runs code synchronously. That means if we ask it to render a Quarto presentation or send a request to an LLM, the app would block until that job is done. The whole interface would freeze. That’s no fun for the user. That’s why Shiny has an option to run extended tasks (extended_task in Python, ExtendedTask in R). It lets us run non-blocking jobs asynchronously in the background, so our app can stay responsive. It works together with a special action button, input_task_button, which is designed to trigger long running tasks. In order for this button to work you need to bind the button to the extended task with bind_task_button.

For DeckCheck, there are two main jobs to do:

1. Render the presentation (we call this taskquarto_task)
   • Takes the uploaded Quarto file.
   • Runs Quarto to produce Markdown and HTML versions.
   • Returns the file path to the Markdown document.
2. Analyse our Markdown slides with the LLM (we call this taskchat_task)
   • Waits for the Markdown to be ready, so it can read the content of the Markdown file using the file path.
   • Starts a chat session with the model.
   • Runs two subtasks:
     • A “regular” async chat where the LLM can use our tool to count slides and calculate percentages.
     • A structured async chat that returns clean, structured data according to our data model.

Because the LLM depends on the Markdown output, we have to chain these tasks: the button click first kicks off quarto_task, and only when that’s finished, we run chat_task.

This chaining is done through Shiny’s reactive system:

• A reactive effect (run_quarto in Python) / observer (R) responds to the button press and invokes our first extended task: quarto_task.
• Another reactive effect (run_chat in Python) / observer (R) listens for quarto_task to finish, then reads the rendered Markdown using the file path and invokes our second extended task: chat_task.
• analysis_result is a reactive that listens for chat_task to complete and prepares the final output for the UI.

You can think of it as a pipeline:

This setup keeps the app responsive, ensures tasks run in the right order, and makes the logic clear: the button starts things off, the tasks are executed async (but in order!), and our desired data ends up in a reactive that we can use as information source for all the UI components.

# ======================
# Data Structure
# ======================
ScoreType = Annotated[int, Field(ge=0, le=10)]
PercentType = Annotated[float, Field(ge=0.0, le=100.0)]
MinutesType = Annotated[int, Field(ge=0)]
SlideCount = Annotated[int, Field(ge=0)]

class ScoringCategory(BaseModel):
    score: ScoreType = Field(..., description="Score from 1–10.")
    justification: str = Field(..., description="Brief explanation of the score.")
    improvements: Optional[str] = Field(
        None,
        description="Concise, actionable improvements, mentioning slide numbers if applicable.",
    )
    score_after_improvements: ScoreType = Field(
        ..., description="Estimated score after suggested improvements."
    )

class DeckAnalysis(BaseModel):
    presentation_title: str = Field(..., description="The presentation title.")
    total_slides: SlideCount
    percent_with_code: PercentType
    percent_with_images: PercentType
    estimated_duration_minutes: MinutesType
    tone: str = Field(
        ..., description="Brief description of the tone of the presentation."
    )

    clarity: ScoringCategory = Field(
        ...,
        description="Evaluate how clearly the ideas are communicated. Are the explanations easy to understand? Are terms defined when needed? Is the key message clear?",
    )
    relevance: ScoringCategory = Field(
        ...,
        description="Assess how well the content matches the audience's background, needs, and expectations. Are examples, depth of detail, and terminology appropriate for the audience type?",
    )
    # Truncated for brevity
    # ...
    
# ======================
# Shiny App
# ======================
app_ui = ui.page_fillable(
    ## Our UI
    # ...
    ui.input_task_button(
        "submit",
        icon=ui.HTML(robot),
        label="Analyse presentation",
    )
    # ...
)

def server(input, output, session):
    @ui.bind_task_button(button_id="submit")
    @reactive.extended_task
    async def quarto_task(file_path, temp_dir):
        # We're using an Extended Task to avoid blocking. Note that
        # a temporary directory called within mirai will be
        # different from the one in the "main" Shiny session. Hence,
        # we pass a temp_dir parameter to the task and use that.
        qmd_file = Path(temp_dir) / "my-presentation.qmd"
        shutil.copy(file_path, qmd_file)

        # Run asyncio subprocess
        proc = await asyncio.create_subprocess_exec(
            "quarto", "render", str(qmd_file), "--to", "markdown,html"
        )
        await proc.communicate()

        # Return the path to the markdown file
        return Path(temp_dir) / "my-presentation.md"

    @ui.bind_task_button(button_id="submit")
    @reactive.extended_task
    async def chat_task(system_prompt, markdown_content, DeckAnalysis):
        # We're using an extended task to avoid blocking the session and
        # we start a fresh chat session each time.
        # For a feedback loop, we would use a persistent chat session.
        chat = ChatAnthropic(
            model="claude-sonnet-4-20250514",
            system_prompt=system_prompt,
        )

        # Set model parameters (optional)
        chat.set_model_params(
            temperature=0.8,  # default is 1
        )

        # Register the tool with the chat
        chat.register_tool(calculate_slide_metric)

        # Start conversation with the chat
        # Task 1: regular chat to extract meta-data
        chat_res1 = await chat.chat_async(
            interpolate(
                "Execute Task 1 (counts). Here are the slides in Markdown: {{ markdown_content }}"
            )
        )

        print(chat_res1)

        # Task 2: structured chat to further analyse the slides
        chat_res2 = await chat.chat_structured_async(
            "Execute Task 2 (suggestions)",
            data_model=DeckAnalysis,
        )

        return chat_res2

    @reactive.effect
    @reactive.event(input.submit)
    async def run_quarto():
        req(input.file() is not None)

        # Get file path of the uploaded file
        file_path = input.file()[0]["datapath"]

        quarto_task.invoke(file_path, tempfile.gettempdir())

    @reactive.effect
    def run_chat():
        # require quarto_task result to be available
        req(quarto_task.result() is not None)
        
        # Get the Markdown file path from the complete quarto_task
        markdown_file = quarto_task.result()
        # Read the generated Markdown file containing the slides
        markdown_content = markdown_file.read_text(encoding="utf-8")

        # Define prompt file
        system_prompt_file = (
            ROOT_DIR / "prompts" / "prompt-analyse-slides-structured-tool.md"
        )

        # Create system prompt
        system_prompt = interpolate_file(
            system_prompt_file,
            variables={
                "audience": input.audience(),
                "length": input.length(),
                "type": input.type(),
                "event": input.event(),
                "markdown_content": markdown_content,
            },
        )

        # Trigger the chat task with the provided inputs
        chat_task.invoke(system_prompt, markdown_content, DeckAnalysis)

        # This reactive will be used as information source for
        # all the UI elements. It uses the result from the chat_task,
        # and does some data wrangling
    @reactive.calc
    def analysis_result():
        res = chat_task.result()
        if res is not None:
                # Some data wrangling
                # ...
            return res
        else:
            return None

app = App(app_ui, server)

# ======================
# Data Structure
# ======================
# Reusable scoring category
type_scoring_category <- type_object(
  score = type_integer(
    description = "Score from 1 to 10."
  ),
  justification = type_string(
    description = "Brief explanation of the score."
  ),
  improvements = type_string(
    description = "Concise, actionable improvements, mentioning slide numbers if applicable.",
    required = FALSE
  ),
  score_after_improvements = type_integer(
    description = "Estimated score after suggested improvements."
  )
)

# Top-level deck analysis object
type_deck_analysis <- type_object(
  presentation_title = type_string(description = "The presentation title."),
  total_slides = type_integer(description = "Total number of slides."),
  percent_with_code = type_number(
    description = "Percentage of slides containing code blocks (0–100)."
  ),
  percent_with_images = type_number(
    description = "Percentage of slides containing images (0–100)."
  ),
  estimated_duration_minutes = type_integer(
    description = "Estimated presentation length in minutes, assuming ~1 minute per text slide and 2–3 minutes per code or image-heavy slide."
  ),
  tone = type_string(
    description = "Brief description of the presentation tone (e.g., informal, technical, playful)."
  ),
  clarity = type_array(
    description = "Evaluate how clearly the ideas are communicated. Are the explanations easy to understand? Are terms defined when needed? Is the key message clear?",
    type_scoring_category
  ),
  relevance = type_array(
    description = "Asses how well the content matches the audience's background, needs, and expectations. Are examples, depth of detail, and terminology appropriate for the audience type?",
    type_scoring_category
  ),
  # Truncated for brevity
  # ...
)

# ======================
# Shiny App
# ======================
ui <- page_fillable(
  ## Our UI
  # ...
  input_task_button(
    id = "submit",
    label = shiny::tagList(
      bsicons::bs_icon("robot"),
      "Analyse presentation"
    ),
    label_busy = "DeckCheck is checking...",
    type = "default"
  )
  # ...
)

server <- function(input, output, session) {
  quarto_task <- ExtendedTask$new(function(file_path, temp_dir) {
    # We're using an Extended Task to avoid blocking. Note that
    # a temporary directory called within mirai will be
    # different from the one in the "main" Shiny session. Hence,
    # we pass a temp_dir parameter to the task and use that.
    mirai(
      {
        qmd_file <- file.path(temp_dir, "my-presentation.qmd")
        file.copy(file_path, qmd_file, overwrite = TRUE)

        quarto::quarto_render(
          input = qmd_file,
          output_format = c("markdown", "html")
        )

        # Return the path to the markdown file
        file.path(temp_dir, "my-presentation.md")
      },
      # Use the same environment as the Shiny app
      environment()
    )
  }) |>
    bind_task_button("submit")

  chat_task <- ExtendedTask$new(function(
    system_prompt,
    markdown_content,
    type_deck_analysis
  ) {
    # We're using an Extended Task to avoid blocking the session and
    # we start a fresh chat session each time.
    # For a feedback loop, we would use a persistent chat session.
    chat <- chat_anthropic(
      model = "claude-sonnet-4-20250514",
      system_prompt = system_prompt,
      params = params(
        temperature = 0.8 # default is 1
      )
    )

    # Register the tool with the chat
    chat$register_tool(calculate_slide_metric)

    # Start conversation with the chat
    # Task 1: regular chat to extract meta-data
    chat_res <- chat$chat_async(
      interpolate(
        "Execute Task 1 (counts). Here are the slides in Markdown: {{ markdown_content }}"
      )
    )

    chat_res$then(function(res) {
      # Print the response from Task 1
      cat("Response from Task 1:\n")
      cat(res, "\n\n")

      # Execute next task
      # Task 2: structured chat to further analyse the slides
      chat$chat_structured_async(
        "Execute Task 2 (suggestions)",
        type = type_deck_analysis
      )
    })
  }) |>
    bind_task_button("submit")

  observe({
    req(input$file)
    req(input$audience)
    req(input$length)
    req(input$type)
    req(input$event)

    # Get file path of the uploaded file
    file_path <- input$file$datapath

    quarto_task$invoke(file_path, temp_dir = tempdir())
  }) |>
    bindEvent(input$submit)

  observe({
    req(quarto_task$result())
    
    # Get the Markdown file path from the completed quarto_task
    markdown_file <- quarto_task$result()
    # Read the generated Markdown file containing the slides
    markdown_content <- readChar(markdown_file, file.size(markdown_file))

    # Define prompt file
    system_prompt_file <- here::here(
      "prompts",
      "prompt-analyse-slides-structured-tool.md"
    )

    # Create system prompt
    system_prompt <- interpolate_file(
      path = system_prompt_file,
      audience = input$audience,
      length = input$length,
      type = input$type,
      event = input$event
    )

    # Trigger the chat task with the provided inputs
    chat_task$invoke(
      system_prompt = system_prompt,
      markdown_content = markdown_content,
      type_deck_analysis = type_deck_analysis
    )
  })

  # This reactive will be used as information source for
    # all the UI elements. It uses the result from the chat_task,
    # and does some data wrangling
  analysis_result <- reactive({
    named_list <- chat_task$result()

        # Some data wrangling
        # ...
        
    named_list
  })

shinyApp(ui, server)

In this case, we choose to start a fresh chat session each time. Another way to do this would be to bring up the code that initialises the chat client, set model parameters, and registers our tool so it only runs once at the start of the session. Then, we could use chat.set_turns([]) (Python) / chat$set_turns([]) (R) before each new “chat task”. This way, we won’t accumulate chat history.

Towards a better UI

There’s an engine, and there’s a basic UI. Time to put them together. But if we want a Shiny app to truly shine, we need to give the UI a little extra love. In this section, we’ll go over all the UI elements that we have in our design, plus some extra goodies. The suggestions here are just examples though, the possibilities go far beyond what we’ll cover here.

# ======================
# Shiny App
# ======================
app_ui = ui.page_fillable(
    # ...
    ui.layout_sidebar(
        ui.sidebar(
            # Sidebar content
            # ...
        ),
        # Main content is now dynamic
        ui.output_ui("results"),
    ),
    # ...
)

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

    @render.ui
    async def results():
        if quarto_task.status() == "running":
            return ui.div(
                ui.HTML(file_slides_loader),
                ui.br(),
                ui.p("Processing your Quarto presentation..."),
                class_="text-center d-flex flex-column justify-content-center align-items-center",
                style="height: 100%",
            )

        elif chat_task.status() == "running":
            return ui.div(
                ui.HTML(robot_loader),
                ui.br(),
                ui.p("The LLM is doing its magic..."),
                class_="text-center d-flex flex-column justify-content-center align-items-center",
                style="height: 100%",
            )

        elif chat_task.status() == "success":
            return ui.TagList(
                # Final results UI components
                # ...
            )

app = App(app_ui, server)

# ======================
# Shiny App
# ======================
ui <- page_fillable(
  # ...
  layout_sidebar(
    # Sidebar content
    # ...
    ),
    # Main content is now dynamic
    uiOutput("results", height = "100%")
    # ...
  )
)

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

  output$results <- renderUI({
    if (quarto_task$status() == "running") {
      div(
        class = "text-center d-flex flex-column justify-content-center align-items-center",
        style = "height: 100%;",
        bsicons::bs_icon(
          "file-slides",
          size = "6em",
          class = "text-primary bounce"
        ),
        br(),
        p("Processing your Quarto presentation...")
      )
    } else if (chat_task$status() == "running") {
      div(
        class = "text-center d-flex flex-column justify-content-center align-items-center",
        style = "height: 100%;",
        bsicons::bs_icon(
          "robot",
          size = "6em",
          class = "text-primary bounce"
        ),
        br(),
        p("The LLM is doing its magic...")
      )
    } else if (chat_task$status() == "success") {
      tagList(
        # Final results UI components
        # ...
      )
    }
  })

shinyApp(ui, server)

.bounce {
    animation: bounce 2s infinite;
}

@keyframes bounce {
    0%, 100% {
        transform: translateY(0);
    }
    50% {
        transform: translateY(-20px);
    }
}

# SVG icon copied from https://icons.getbootstrap.com/icons/file-slides-fill/
file_slides = """<svg xmlns="http://www.w3.org/2000/svg" fill="currentColor" class="bi bi-file-slides-fill" viewBox="0 0 16 16">
  <path d="M7 7.78V5.22c0-.096.106-.156.19-.106l2.13 1.279a.125.125 0 0 1 0 .214l-2.13 1.28A.125.125 0 0 1 7 7.778z"/>
  <path d="M12 0H4a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h8a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2M5 4h6a.5.5 0 0 1 .496.438l.5 4A.5.5 0 0 1 11.5 9h-3v2.016c.863.055 1.5.251 1.5.484 0 .276-.895.5-2 .5s-2-.224-2-.5c0-.233.637-.429 1.5-.484V9h-3a.5.5 0 0 1-.496-.562l.5-4A.5.5 0 0 1 5 4"/>
</svg>"""

ui.tooltip(
    ui.value_box(
        "Showtime",
        ui.output_text("showtime"),
        showcase=ui.HTML(file_slides),
        theme="primary",
    ),
    "Slides are being counted based on the provided Quarto presentation, then an educated guess is made about the time it will take to present them.",
)

@render.text
def showtime():
    res = analysis_result()

    req(res is not None)
    return f"{res['meta']['estimated_duration_minutes']} minutes"

value_box(
  title = tooltip(
    span(
      "Showtime ",
      bsicons::bs_icon("question-circle-fill")
    ),
    "Slides are being counted based on the provided Quarto presentation, then an educated guess is made about the time it will take to present them."
  ),
  value = textOutput("showtime"),
  showcase = bsicons::bs_icon("file-slides"),
  theme = "primary"
)

output$showtime <- renderText({
  req(analysis_result())
  paste0(
    analysis_result()$meta$estimated_duration_minutes,
    " minutes"
  )
})

ui.card(
    ui.card_header(ui.strong("Scores per category")),
    output_widget("scores"),
    height="600px",
)

@render_widget
def scores():
    res = analysis_result()

    req(res is not None)

    evals = res["evals"].copy()
    evals = evals.sort_values("score")
    evals["category"] = pd.Categorical(
        evals["category"], categories=evals["category"], ordered=True
    )

    # apply to the justification column
    evals["justification_wrapped"] = evals["justification"].apply(add_line_breaks)

    # Create a custom tooltip column
    evals["tooltip"] = (
        "Score: "
        + evals["score"].astype(str)
        + "<br>After improvements: "
        + evals["score_after_improvements"].astype(str)
        + "<br>Justification: "
        + evals["justification_wrapped"]
    )

    plot = px.bar(
        evals,
        x="score",
        y="category",
        orientation="h",
        labels={"category": "Category", "score": "Score"},
        hover_data={"tooltip": True},  # include the tooltip column
    )

    # Set hovertemplate to use our custom tooltip
    plot.update_traces(
        hovertemplate="%{customdata[0]}<extra></extra>",
        customdata=evals[["tooltip"]].values,
    )

    plot.update_traces(marker_color="#18bc9c")

    plot.update_layout(template="simple_white")

    return plot