Welcome to the first edition of our Positron newsletter! Here, we will share highlights from our latest release, tips on how to be more productive with Positron, and useful resources.

We just returned from an in-person onsite in beautiful Monterey, California. During the trip, we got a chance to meet (some of us for the first time), touch grass and sand, and brainstorm ways we can improve to build better products for you.

Let’s get into the updates.

Key Product Updates

The April 2026 release of Positron brings significant improvements across:

• Positron Server for Academic Use via JupyterHub
• AI enhancements : Next Steps in Jupyter Notebooks, Agent Skills, and Azure AI Foundry Support
• Telemetry updates
• R improvements : Addins, Debugging, and more
• Data Explorer Performance Improvement
• Windows ARM in GA
• What’s Coming Next : Inline Outputs, Packages Pane, and Posit Assistant

Here’s a look at the key features that shipped with the April 2026 release.

Positron Server for Academic Use via JupyterHub

What we built: Academic institutions can now offer Positron Server to their students at no cost through JupyterHub ( blog post ). If your institution already runs JupyterHub, you can add Positron as a launcher option alongside JupyterLab, with no additional infrastructure required. Students simply log in and select Positron from the launcher, getting the full Positron experience including rich Python and R support, the extension marketplace, and (optionally) Positron Assistant.

Why this matters: This removes the barrier for students and educators who want to use Positron in a classroom setting. No local installs, no configuration headaches — just a familiar JupyterHub login with Positron ready to go.

Get started: Review the eligibility criteria and send an email to academic-licenses@posit.co to request a free teaching license.

AI Next Steps in the Native Jupyter Notebook Editor

What we built: AI Next Steps uses the Positron Assistant to analyze your current cell output and suggest a logical next step in a “ghost cell” at the bottom of your notebook. If you just loaded a CSV, it might suggest data cleaning steps or a visualization, without you needing to open a chat pane or write a prompt. Suggestions stay aligned with the notebook’s live kernel state, updating as your code and outputs change.

Why this matters: The design came out of interviews with data scientists who kept telling us the same thing: switching to a chat pane mid-analysis breaks their concentration. AI Next Steps sits at the bottom of your notebook and updates as your outputs change. You just run a cell, and if there’s a logical next step, it surfaces, with no prompt required.

Get started: Enable the feature by setting positron.assistant.notebook.ghostCellSuggestions.enabled to true in your settings. When you run a cell, look for the ghost cell suggestion at the bottom of the notebook, accept, reject, or hide it.

Agent Skills in Positron Assistant

What we built: Agent skills — reusable, structured capabilities that extend what agents can do in agent.md files — are now integrated into Positron ( #11753 ). Skills let agents execute multi-step workflows like “profile this dataset and suggest cleaning steps” or “run this test suite and summarize failures,” so you define a task once and reuse it across sessions and projects.

Why this matters: Skills make agents composable building blocks rather than one-off chat interactions. Instead of re-explaining a complex workflow every time, you codify it as a skill that any team member can use.

Get started: Open the chat gear icon and select Skills, or run Chat: Configure Skills from the Command Palette.

Positron Assistant Now Supports Microsoft Foundry as a Provider

What we built: Positron Assistant now supports Microsoft Foundry as a model provider ( #8583 ) with API key-based access via a custom base URL.

Why this matters: If your team runs on Azure and uses LLMs through Foundry, you can now use Positron Assistant with them.

Get Started: In Positron Assistant’s provider settings, set positron.assistant.provider.msFoundry.enable to true to select Microsoft Foundry as a provider. You can authenticate with an API key and your Foundry endpoint URL.

Telemetry Update: Anonymous Session Identifiers

What we changed: Positron now generates an anonymous, random session identifier to help us understand usage patterns like session frequency and retention across releases. This identifier contains no personal information, account data, or workspace content; it’s a cryptographically random UUID that cannot be linked to any other identifiers, including the identifier that VS Code uses for telemetry.

Why we’re doing this: As a free, source available project, we don’t have traditional product analytics. Understanding whether people come back, how often they use Positron, and whether releases improve or regress the experience helps us prioritize the right work to build a better experience for you.

You can opt out by updating your settings outlined here , or you can reset the anonymous identifier with the command Preferences: Reset Anonymous Telemetry ID. If you’ve opted out of product updates, no session identifier is generated or sent.

RStudio Addins Support

What we built: Positron now supports running RStudio addins from R packages. If a package registers an addin (like styler, reprex, clipr, or shinyuieditor), you can run it directly from Positron ( #1313 ).

Why this matters: This was one of our most upvoted issues this release (25 👍). Many R users rely on addins as part of their daily workflow for code formatting, generating reproducible examples, or launching Shiny tools.

Get started: Open the Command Palette (Ctrl-Shift-P (windows), Ctrl-Shift-P (linux), Command-Shift-P (mac)) and search for Run RStudio Addin. You’ll see a quick pick with all available addins from your installed packages.

R Debugger & Workflow Improvements

What we built: The R debugger received a suite of improvements this release. In addition to conditional breakpoints, hit count breakpoints, and log breakpoints ( #12360 ), the debugger now supports error and warning breakpoints ( #11797 ), the ability to pause R at any time ( #11799 ), Watch Pane support ( #1765 ), and synchronization between the Console and Variables pane with the selected call stack frame ( #3078 and #12131 ).

Why this matters: Advanced debugging in R has traditionally meant scattering if (...) browser() calls through your code or setting options(error = recover) by hand. These new features put Positron’s R debugger on par with what you’d expect from any modern language:

• Conditional, hit count, and log breakpoints let you control exactly when breakpoints fire and print diagnostic info, all without touching your source code.
• Error and warning breakpoints drop you into the debugger the moment an error or warning is emitted, so you can inspect the state that caused it.
• Pause R at any time. If R is stuck in a long computation or an infinite loop, you can drop into the debugger mid-execution, look around, and resume by clicking Continue.
• Watch Pane lets you track expressions across debug steps. Prefix an expression with /print to see R’s printed output (hover to get full output) instead of a structured variable.
• Synchronization with the call stack. Click any frame in the Call Stack view and the Console, completions, and Variables pane all switch to that frame’s environment. The Console synchronization is like recover(), but built into the IDE.

Get started: Set a breakpoint in any R file, then right-click it and choose Edit Breakpoint. Select “Expression” to add a condition (e.g., i > 100), “Hit Count” to break after N hits, or “Log Message” to print a message without pausing. For error and warning breakpoints, open the Breakpoints pane and enable them there. To pause R while code is running, use the command Debug: Pause or check the Interrupt breakpoint option in the Breakpoints pane. While debugging, add expressions in the Watch section of the debug sidebar and click on frames in the Call Stack to navigate environments.

Data Explorer: Faster with Multiple DataFrames

What we built: We fixed two long-standing performance issues in the Data Explorer. Background Data Explorer tabs no longer trigger backend recomputation, and the summary panel no longer recalculates summary statistics for large DataFrames on every cell execution ( #4279 and #2795 ).

Why this matters: If you work with multiple DataFrames open, you may have noticed lag as Positron recomputed statistics for tabs you weren’t even looking at. That’s gone now.

Get started: Nothing to configure. When you open multiple DataFrames in the Data Explorer and switch between them, you should notice snappier performance, especially with large datasets.

Windows ARM Is Generally Available

What we built: We started creating experimental builds for Windows ARM several months ago, and our early users have had good experiences with them. This release, we promoted the Windows ARM builds from experimental to stable and they are now available through all standard installation channels ( #12207 ).

Why this matters: ARM-based devices are increasingly common for Windows users, whether you’re a student or a professional. GA support means these users get the same Positron experience, including Quarto with R and Python support, without needing workarounds or experimental builds. Do be aware that the Windows ARM build bundles the non-ARM version of Quarto, which runs under emulation.

Get started: Install Positron on your ARM-based Windows device through standard installation channels .

View all issues in the 2026.04.0 Release milestone .

What’s Coming Next

We are currently building the following features and we’d love your feedback. Please share on GitHub . These early alpha features with some rough edges are available for testing by enabling their respective settings.

Inline Outputs for Quarto and R Markdown Files

This was the second most upvoted issue we have ever, ever had! We just completed an initial run to allow displaying inline outputs within Quarto and R Markdown files ( #5640 ), and it is available for early testing. Note that this experimental version, while it does get the basics into Positron, does not have support for many popular RStudio features. You can opt in to the experimental feature using the positron.quarto.inlineOutput.enabled setting.

Packages Pane for Managing Environments

We are currently building out a new Packages pane that will allow you to install, update, and uninstall packages without leaving your workspace or needing to use the terminal ( #11214 ). We’d love to hear your feedback on this discussion thread .

Events and Resources

Explore Positron’s Video Walkthroughs on YouTube

We hosted a walkthrough of exploring GitHub data in a Jupyter Notebook and converting this into an interactive Shiny app with AI. Catch up on the recording or explore more Positron videos .

Registration for posit::conf(2026) Is Now Open!

Registration is officially open for posit::conf(2026)! Join the global data community in Houston or tune in online from September 14–16. Register today!

How We Chose a Python Type Checker

Ever wondered about the decision making process behind how we chose which Python type checker to bundle in Positron? Check out Austin Dickey’s blog post walking through his research and decision making process.

Community Affirmations

Thank you all for your support, ideas and engagement. We’re building Positron in the open because the best ideas come from the people using it. If there’s a feature you’d love to see, open an issue or upvote an existing one, it genuinely shapes what we work on next.

Have a great April!

Positron Team

Students can launch Positron the same way they would open JupyterLab or a notebook. Just select it from the JupyterHub launcher and start working.

Once launched, Positron provides the full IDE experience, including:

• Rich Python and R support
• Access to the OpenVSX extension marketplace
• Built in data viewer and variables explorer
• Integrated help pane, debugger, version control and other features to help students level up when they’re ready

How it works

Positron Server is designed to integrate directly with existing JupyterHub deployments. It’s compatible with JupyterHub environments running JupyterLab 4 and Python 3.9+.

It’s installed via the jupyter-positron-server Python package , built on Jupyter Server Proxy. If you’ve configured similar services before, setup will feel familiar. This is not a standalone desktop install. Rather, it lets you bring Positron into an existing JupyterHub setup.

Who can use it?

This offering is available to academic institutions using Positron for teaching. Under a free license, institutions can provide access to enrolled students, course participants, or staff involved in the delivery or receipt of educational programming.

Full eligibility details are available in the Positron Education License Rider .

Getting started

Hosting Positron for teaching purposes requires a free license key. To get set up:

1. Review the eligibility criteria in the Positron Education License Rider .
2. Email academic-licenses@posit.co to request a teaching license.
3. Once your license is confirmed, follow the jupyter-positron-server documentation to complete setup in your JupyterHub environment.

Quarto 2 is a full rewrite of the Quarto CLI, written from the ground up in Rust to better support your existing use cases, and enable a number of new, exciting use cases. Most importantly, Quarto 2 will include a built-in collaborative editor, and we plan on adding support for collaborative writing in Posit’s commercial products such as Posit Cloud, Connect, and Workbench. With that said, the design of those integrations is still taking shape.

It is also very early in the project. If you interact with the Quarto project solely as a user of the tool, nothing in your workflow will change, and you should proceed as if you didn’t know about our plans for Quarto 2. We don’t expect to have a public release of Quarto 2 for at least 6 months. In addition, we will continue to develop and maintain parallel versions until Quarto 2 is a suitable replacement for users of Quarto 1.

Just like Quarto 1, Quarto 2 is open source and MIT licensed. The GitHub repository for Quarto 2 is currently quarto-dev/q2 .

Why Quarto 2?

There are some fundamental pain points in Quarto 1 that can’t be solved incrementally. The goal of Quarto 2 is not to change how you currently work with Quarto; instead, we’ve arrived at a point where incremental improvements do not provide the value you deserve given our team size and constraints. These are some of the things we want to do in Quarto 2:

• A new Markdown parser enables tighter integration with editors for the entire rendering pipeline. We know that good error messages, autocompletion, and YAML validation are some of your favorite features in Quarto 1. Quarto has about 1,000 different YAML configuration options, and we know how important it is to be able to provide good error messages. We want to extend this same idea to everything in your Quarto project: Markdown syntax errors, Lua filter errors, broken links, etc. Whenever possible, these should be flagged in your editor of choice.

• A fundamental solution for long-standing performance problems. Quarto 1 is built by integrating a number of tools that work very well in isolation, but aren’t designed to be performant when used together. A full rewrite of the Quarto core functionality in a single programming language will enable us to provide much better performance than before.

• A collaborative editor. Quarto 2 will ship with a collaborative editor designed to work directly on the web as well as on the command-line. Keeping in the tradition and ethos of the Quarto project, this will include a robust open-source foundation based on automerge , as well as a commercial solution for hosted project management. This follows the relationship between Quarto 1 and its integration with other Posit commercial offerings.

• A visual editor that works well alongside a source editor. The visual editor we ship in RStudio, VS Code, and Positron works well if everyone working on the document is using the visual editor. On the other hand, if you choose the visual editor, but your colleague chooses the source editor, then you’ll find that the experience is full of sharp edges. Quarto 2 is built from the ground up to support bidirectional editing workflows. A small change in your document using the visual editor shouldn’t cause a large change in the .qmd file that is disruptive for your colleagues using a source editor.

• Support for Quarto 1 projects. We aim for Quarto 2 to be backwards compatible with Quarto 1. Concretely, we’re aiming to incorporate our Quarto 1 test suite directly into Quarto 2’s project, including support for Pandoc and its output formats that our community depends on. Your existing extensions and projects should just work in Quarto 2. Early on, there will be gaps, and Quarto 2 will initially be a better fit for new projects.

What happens to Quarto 1 development?

It’s not going anywhere, and will be in active development for at least the next year. We’ll still provide bugfixes, and accept pull requests.

Current status

The development is happening in a separate GitHub repository . Feel free to look around! However, this code base isn’t ready for public consumption, and is very much in flux: that means we’re not going to spend a lot of time answering architectural questions about it until things have settled, and all discussion of Quarto should remain in our current discussion forum and issue tracker.

There are big, interesting changes in the Quarto 2 architecture, and they deserve a longer exposition. We are working on those documents right now, and will share them with you in the next few weeks. Stay tuned!

We’re pleased to announce that Shiny for Python v1.6 is now available on PyPI !

Install it now with pip install -U shiny.

This release has two big additions: toolbar components for building compact, modern UIs, and OpenTelemetry support for understanding how your apps behave in production. A full list of changes is available in the CHANGELOG .

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.

Toolbars in card headers and footers

The most common use case is placing a toolbar in a card header to attach controls directly to a card’s content:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

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()}"

Toolbars in input labels

You can also pass a toolbar as an input’s label to add an info button for additional information or provide quick actions, like resetting an input value.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

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,
    )

Toolbars in text areas

The input_submit_textarea() component accepts a toolbar parameter directly, making it easy to add contextual controls for AI chat interfaces and message composers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

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)

Toolbars are available in py-shiny and forthcoming in bslib for R. For a complete walkthrough with full app examples, see the Toolbar component page .

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?

Getting started

The fastest way to get started is with Pydantic Logfire , which provides zero-configuration OTel setup:

1
2

pip install logfire
logfire auth

Then set an environment variable to tell Shiny what level of tracing to collect:

1

export SHINY_OTEL_COLLECT=reactivity

That’s it — no changes to your app code required. Run your app and visit logfire.pydantic.dev to see traces.

OTel is great for GenAI apps

Shiny’s OTel integration pairs especially well with Generative AI applications. When a user reports that your chatbot feels slow, traces make it easy to pinpoint whether the delay is in the AI model request, streaming, tool execution, or a downstream reactive calculation.

The image below shows a trace from a weather forecast app powered by a Generative AI model. A single user session is captured in full detail:

What gets traced automatically

Shiny automatically creates spans for all of the following — no manual instrumentation needed:

• Session lifecycle: When sessions start and end, including HTTP request details
• Reactive updates: The entire cascade of reactive calculations triggered by an input change or a new output to be rendered
• Reactive expressions: Individual calculations such as @reactive.calc, @reactive.effect, @render.*, and other reactive constructs

Works with any OTel backend

Logfire is our recommended starting point, but Shiny’s OTel integration is fully vendor-neutral. You can send traces to Jaeger , Zipkin , Grafana Cloud , Langfuse , or any other OTLP-compatible backend.

For local debugging without a backend, install the OpenTelemetry SDK and use the console exporter:

1

pip install "shiny[otel]"

Full documentation — including custom spans, database instrumentation, and production considerations — is available in the OpenTelemetry guide .

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!

The open-source Python type checker and language server ecosystem has exploded. Over the past year or two, four language server extensions have appeared, each with a different take on what Python type checking should look like. We evaluated each of them to decide which one to bundle with Positron to enhance the Python data science experience.

Background

The Language Server Protocol (LSP) is a cross-language, cross-IDE specification that allows different IDE extensions to contribute smart features like tab completions, hover info, and more. The four¹ Python extensions in this post are powered by type checkers, which are Python-specific tools that catch bugs in your code before runtime by guessing and checking the types of your variables. They do this by statically analyzing your code before you run it.

With AI tools writing more of your code, a good language server helps you read and navigate code you didn’t write. LLM-generated code also introduces bugs that type checkers catch before you run anything. For data scientists, who rely on code to be the reproducibility layer, and who can’t automate away human judgment, what matters is a tool that helps you understand and trust your code.

We did this evaluation in November 2025 but have refreshed the data in this post at the time of publish.

The contenders

Pyrefly is Meta’s successor to Pyre. It takes a fast, aggressive approach to type inference, being able to catch issues even in code with no type annotations. It reached beta status in November 2025.

ty is from Astral, the team behind uv and ruff. OpenAI announced its acquisition of Astral recently; Astral has stated that ty, ruff, and uv will remain open source and MIT-licensed. It’s the newest project, with a focus on speed and tight integration with the Astral toolchain. It reached beta status in December 2025 and follows a “gradual guarantee” philosophy (more on that below).

Basedpyright is a community fork of Microsoft’s Pyright type checker, with additional type-checking rules and LSP features baked in. It’s the most mature of the four and has the largest contributor base.

Zuban is from David Halter, the author of Jedi (the longtime Python autocompletion library). It aims for mypy compatibility and ships as a pip-installable tool.

What we tested

We tested each language server across several dimensions, roughly following the rubric we outlined publicly :

• Feature completeness: Completions, hover, go-to-definition, rename, code actions, diagnostics, inlay hints, call hierarchy
• Correctness: How well does the type checker handle real-world Python code?
• Performance: Startup time and time to first completion
• Ecosystem: License, community health, development velocity, production readiness

We tested inside Positron with a mix of data science and general Python code.

Feature completeness

Here are some screenshots of hovers, tab-completions, and diagnostics from each extension:

• Pyrefly
• ty
• Basedpyright
• Zuban

All four provide the core features you’d expect: completions, hover documentation, go-to-definition, semantic highlighting, and diagnostics. The differences show up in the details.

Pyrefly

Strong feature set. The hover documentation is the best of the four; Pyrefly renders it cleanly and sometimes includes hyperlinks to class definitions.

ty

Fast and clean, now in beta. The completion details can sometimes feel a little overwhelming, but can help when expanded.

Basedpyright

Handles type checking comprehensively well. The main friction point: it surfaces a lot of warnings out of the box. If you’re doing exploratory data science, a wall of type errors on your first pandas import can feel hostile. You can tune this down, but the defaults are oriented toward stricter use cases like package development.

Zuban

The least mature of the four so far. Installation requires a two-step process (pip install zuban, then configure the interpreter), and the analysis is tied to that specific Python installation on saved files only. Third-party library completions only work when stubs are available, not from installed packages. Symbol renaming once broke standard library code in our testing.

Type checking philosophy

The bigger difference between these tools isn’t features but how they think about type checking.

Gradual guarantee vs. aggressive inference

ty follows what’s called the gradual guarantee: removing a type annotation from correct code should never introduce a type error. The idea is that type checking should be additive. You opt in by adding types, and the checker only flags things it’s sure about.

The other extensions take the opposite approach. They always infer types from your code, even when you haven’t written any annotations. This means they can catch bugs in completely untyped code, but it also means they may flag code that runs perfectly fine.

For example:

1
2
3
4
5
6
7

my_list = [1, 2, 3]
my_list.append("foo")

# Pyrefly: bad-argument-type
# ty: <no error>
# Basedpyright: reportArgumentType
# Zuban: arg-type

Pyrefly infers my_list as list[int] and flags the append("foo") call as a type error. ty sees no annotations and stays silent. The code is dynamically typed and that’s fine.

If you’re doing exploratory data analysis and don’t want to annotate everything, ty’s restraint might be more comfortable. But if you’re writing a library and want to catch bugs early, Pyrefly’s aggressiveness is helpful. For example:

1
2
3
4
5
6
7
8
9

def process(data):
    return str(data)

process(42) + 1  # Raises a runtime AttributeError

# Pyrefly: unsupported-operation
# ty: <no error>
# Basedpyright: reportOperatorIssue
# Zuban: operator

Basedpyright and Zuban land somewhere in between, with Basedpyright leaning toward stricter checking and Zuban aiming for mypy compatibility. Each of these extensions has the ability to suppress certain diagnostics you actually see when typing if you wish.

For a deeper dive on this topic, Edward Li’s comparison of Pyrefly and ty and Rob Hand’s overview of future Python type checkers are both worth reading, though some bugs have been fixed since they were published.

Performance

We measured startup time (how long until the language server responds to an initialize request) and time to first completion (how long a textDocument/completion request takes after initialization) in a relatively small repository. We ran each measurement five times and averaged. As always, these results only represent our computer’s experimental setup.

ty was the fastest across the board. But the practical differences are small: a 3-second difference in startup happens once per session, and a 100ms difference in completions is imperceptible. All four are fast enough that differences are negligible for daily use.

Ecosystem health

We also looked at each project’s development velocity and community health metrics. A language server you rely on daily needs to keep up with Python’s evolution.

ty and Pyrefly are shipping fast. Both are on a weekly release cadence or higher with high issue throughput. ty’s issue volume is notable: 789 issues opened in 90 days reflects both heavy adoption and active bug reporting. Pyrefly is closing more issues than it’s opening, a good sign for a beta project.

Response times are quick. In a spot-check of recent issues, ty and Pyrefly both had first responses from core maintainers within minutes to hours. Basedpyright’s maintainer responds quickly too, though at a lower volume. Zuban’s maintainer often replies within an hour.

What we chose

We bundled Pyrefly as Positron’s default Python language server.

The deciding factors:

• Pyrefly’s clean design decisions felt like the best fit for Positron. The hover docs are rendered and hyperlinked, with sources for type inference. The type inference catches real bugs without requiring you to annotate everything. While it has the strictest type checking, this is configured to a moderate level by default.
• It has active development with strong backing. Meta has committed to making Pyrefly genuinely open-source and community-driven, with biweekly office hours and a public Discord. Development velocity is high.
• It is MIT licensed, which allows us to bundle it into Positron.

It wasn’t a runaway winner. Basedpyright is more mature and feature-complete. ty has a lot of long-term potential, especially for ruff users and fans of the gradual guarantee, and is closing feature gaps fast. But for the specific use case of “Python data science in an IDE,” Pyrefly had the best balance of features, UX, and readiness.

How to switch

This space is competitive and moving fast, and you shouldn’t feel locked in. Positron makes it straightforward to switch language servers:

1. Open the Extensions view (Ctrl-Shift-X (linux), Ctrl-Shift-X (windows), Command-Shift-X (mac)).
2. Search for and install the language server you want to try (e.g., basedpyright, ty, or zuban).
3. Disable Pyrefly: search for pyrefly in Extensions, click Disable.
4. Reload the window with the command Developer: Reload Window.

Or, if you want to keep Pyrefly installed but prevent it from auto-activating, you can use the extensions.allowed setting:

1
2
3
4
5
6

{
    "extensions.allowed": {
        "meta.pyrefly": false,
        "*": true
    }
}

What’s next

We started bundling Pyrefly in November and have been quite pleased with the results. It solved some longstanding user-requested issues (like better semantic highlighting) and feels snappier to users than our previous internal solution.

ty is adding features at an aggressive pace and will likely close its remaining gaps. OpenAI’s acquisition of Astral adds resources but also uncertainty; it’s unclear how it will affect ty’s priorities. Pyrefly continues to improve its type checking and performance (a recent release noted 20% faster PyTorch benchmarks ). Basedpyright tracks upstream Pyright closely and keeps shipping.

Both ty and Pyrefly have been receptive to PRs that improve the experience for Positron users, which suggests they care about working well across editors, not just VS Code. For example, both contribute hover, completions, and semantic highlighting in the Positron Console.

We’ll keep evaluating as these tools mature! Want to try Positron? Download it here .

The Typst ecosystem is thriving, and Quarto 1.9 brings Typst much closer to feature parity with LaTeX:

• Typst books
• Article layout in Typst
• Bundling of Typst packages for offline rendering

Typst books

In Quarto 1.9, a project with type book and format typst is now rendered as a single document with multiple chapters and other book content.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

project:
  type: book

book:
  title: "My Book"
  author: "Jane Doe"
  chapters:
    - index.qmd
    - intro.qmd
    - summary.qmd

format: typst

All book features previously available in the LaTeX format are now available in Typst:

• Parts and Chapters
• Appendices
• Cross-references and chapter-based numbering
• Table of Contents

List-of-Figures and List-of-Tables support is coming soon .

The default Typst book uses the bundled Quarto quarto-orange-book extension, which uses typst-gather to bundle the Typst orange-book package. Orange-book provides a textbook-style layout with colored chapter headers and sidebars.

The orange-book extension supports brand.yml customization — it uses the primary color for chapter headers and sidebars, and the medium logo on the title page. The screenshots above were generated with this _brand.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

color:
  primary: "#F36619"
  secondary: "#2E86AB"

logo:
  images:
    test-logo:
      path: logo.svg
      alt: "Test Logo"
  medium: test-logo

Since Typst books are implemented as Quarto Format Extensions , you can customize the appearance by creating your own extension. Typst partials define the overall book structure, while Lua filters handle the necessary AST transformations.

Article layout in Typst

Also in Quarto 1.9, all Article Layout features now work in Typst, via the Typst Marginalia package.

Specifically:

• Figures, tables, code listings, and equations can be placed in the margin using the .column-margin class or the column: margin code cell option.
• You can also target specific output types with fig-column: margin or tbl-column: margin.
• Figure, table, and code listing captions can be placed in the margin with cap-location: margin (or fig-cap-location: margin and tbl-cap-location: margin for specific types).
• Footnotes and citations can be displayed in the margin with reference-location: margin and citation-location: margin. When margin citations are enabled, the bibliography is suppressed.
• Asides (.aside class) place content in the margin without a footnote number.

typst-gather

Quarto 1.9 automatically stages Typst packages — from your extensions, from Quarto’s bundled extensions, and from Quarto itself — into the .quarto/ cache directory before calling typst compile. This means Typst documents render offline without needing network access.

To make this work, extension authors use the new typst-gather tool, which scans their .typ files for @preview imports and downloads the packages into the extension directory. Authors run quarto call typst-gather and commit the results. Users of the extension will have the packages staged without any downloads.

This means Custom Typst Formats can depend on Typst packages without copying and pasting Typst code, making them simpler and easier to maintain.

Both Typst books and article layout are built on typst-gather — orange-book depends on the Typst orange-book package, and article layout depends on Marginalia . As the Typst package ecosystem grows, we’re excited to see what the community builds with Typst packages.

RAG is a simple concept that comes up anytime you want to retrieve content for an LLM to improve or augment the generated output.

LLMs are great at reasoning and generating text, but their knowledge is frozen at training time. They can’t access private documents, recent information, or anything that wasn’t in the training data. When asked about these topics, they either refuse to answer or — worse — hallucinate a confident-sounding response. RAG solves this by giving the model access to relevant information at query time, without needing to retrain it.

In practice, most tools built on top of LLMs already do this. ChatGPT uses web search to include recent news in its answers. Claude Code reads the codebase using tools like grep, list_files, and symbol_search before generating code. RAG is what makes LLMs useful for tasks that require specific, up-to-date, or private knowledge.

Modern LLMs support context windows of 100K tokens or more, which might seem like it makes RAG unnecessary — just paste everything into the prompt. But this doesn’t work well in practice. LLMs suffer from “lost in the middle” (sometimes called “context rot”): they pay less attention to information buried in the middle of a very long prompt, so relevant content gets missed. On top of that, sending your entire knowledge base with every query is expensive, slow, and most real-world document collections are too large to fit in a single context window anyway. Long context and RAG are complementary — a larger window lets you include more retrieved chunks, but retrieval is what gives you precision: the model sees 5 relevant paragraphs instead of 500 irrelevant pages.

raghilda

Building a good retrieval system is the hard part of RAG. raghilda is a Python framework designed to handle it. You give it URLs or file paths, and it takes care of the rest. The defaults are opinionated but transparent — every step is exposed and replaceable. You can swap the chunker, change the embedding provider, or write a custom ingestion function without fighting the framework.

• Document processing. Converting HTML pages, PDFs, and DOCX files into clean text is surprisingly messy. raghilda handles this automatically, converting documents to Markdown. For websites, find_links() crawls and discovers pages so you don’t have to list them by hand.

• Smart chunking. Naive fixed-size chunking can split a code block or paragraph in half. raghilda’s Markdown chunker splits text at semantic boundaries — headings, paragraphs, sentences — and preserves the heading hierarchy so each chunk retains context about where it came from.

• Multiple storage backends. raghilda supports DuckDB (local, zero-config), ChromaDB, and OpenAI Vector Stores. The API is the same across backends, so you can start with a local DuckDB file and move to a hosted solution later without rewriting your code.

• Hybrid retrieval. Pure vector search finds semantically similar content but misses exact keyword matches. raghilda combines semantic search, BM25 keyword matching, and attribute filters — so you can search by meaning, by keywords, and by metadata (e.g. source URL, document type, or any custom attribute) all at once.

How it works

A retrieval system has two phases: ingestion — turning your documents into a searchable store — and retrieval — finding the right chunks given a query. raghilda exposes both phases clearly, with each step exposed as an individual call you can customize or replace.

Let’s walk through a minimal example using a Wikipedia article about Princess Ragnhild of Norway.

First, you create a store with an embedding provider. The store is where your chunks and their vector embeddings will live:

1
2
3
4
5
6
7
8

from raghilda.store import DuckDBStore
from raghilda.embedding import EmbeddingOpenAI

store = DuckDBStore.create(
    location="ragnhild.db",
    embed=EmbeddingOpenAI(),
    overwrite=True,
)

Then you read the document and chunk it. read_as_markdown() converts the URL to Markdown, and MarkdownChunker splits it into overlapping chunks at semantic boundaries:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

from raghilda.read import read_as_markdown
from raghilda.chunker import MarkdownChunker

doc = read_as_markdown(
    "https://en.wikipedia.org/wiki/Princess_Ragnhild,_Mrs._Lorentzen"
)

# We intentionally use a small chunk size for display purposes.
# In practice, chunk sizes of ~1600 characters are a good
# compromise on size versus retrieval quality.
chunker = MarkdownChunker(chunk_size=200, target_overlap=0.25)
chunked = chunker.chunk(doc)
print(f"{len(chunked.chunks)} chunks")

185 chunks

Finally, you upsert the chunked document into the store and build the search indexes. Embedding is handled by the store itself — since the embedding provider is configured at creation time, all chunks in a store are guaranteed to use consistent embeddings:

1
2

store.upsert(chunked)
store.build_index()

During retrieval, you query the store and get back the most relevant chunks. raghilda runs semantic search and BM25 keyword search, then merges the results:

1
2
3
4

chunks = store.retrieve("Did she move to Brazil?", top_k=2)
for chunk in chunks:
    print(chunk.text)
    print("---")

Lorentzen"), a member of the Lorentzen family of shipping magnates.
In the same year, they moved to Brazil, where her husband was an
industrialist and a main owner of Aracruz Celulose. She lived in
Brazil until her death 59 years later.
---
to Rio de Janeiro, where her husband had substantial business
holdings. Their residence in Brazil was originally temporary, but
they
---

Tip: In practice, you’ll usually work with many documents at once — just loop over your URLs or file paths and call upsert() for each one. See the Getting Started guide for a full walkthrough.

Using with an LLM

A retrieval system on its own just returns text chunks. To get actual answers, you connect it to an LLM. The simplest way to do this is to register a search function as a tool that the LLM can call when it needs information.

Here’s an example using chatlas :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from chatlas import ChatOpenAI
import json

def search_ragnhild(query: str) -> str:
    """Search for information about Princess Ragnhild."""
    chunks = store.retrieve(query, top_k=10)
    return json.dumps(
        [{"text": c.text, "context": c.context} for c in chunks]
    )

chat = ChatOpenAI(
    model="gpt-4.1-mini",
    system_prompt="Answer questions about Princess Ragnhild "
    "using the search tool. Always search before answering.",
)
chat.register_tool(search_ragnhild)
_ = chat.chat("Which year did she move to Brazil?", echo="text")

Princess Ragnhild moved to Brazil in the same year she got married,
1953. Her marriage and the move to Brazil were connected, as her
husband was an industrialist and owner of business holdings in Brazil.
They settled in Rio de Janeiro and lived there until her death in 2012.

Compare this with the same question without the search tool:

1
2
3
4
5
6
7
8

chat_no_rag = ChatOpenAI(
    model="gpt-4.1-mini",
    system_prompt="Answer questions about Princess Ragnhild.",
)
_ = chat_no_rag.chat(
    "Which year did she move to Brazil?",
    echo="text",
)

Princess Ragnhild moved to Brazil in 1960.

With the search tool, the LLM retrieves the relevant chunks and grounds its answer in the actual document. Without it, the model has to rely on its training data — and may hallucinate or give a vague response.

Learn more

• Getting Started — full walkthrough building a store from a documentation site
• Examples — complete scripts showing RAG workflows with chatlas, ChromaDB, and more
• GitHub repository — source code, issues, and contributions

Sharing your work just got easier with integrated Posit Connect Cloud publishing. Typst users will appreciate book project support and article layouts, while experimental PDF accessibility standards bring PDF/A and PDF/UA compliance to both LaTeX and Typst. This release also introduces LLM-friendly output for websites, the quarto use brand command for keeping your brand assets in sync, and list tables for authoring complex tables with familiar bullet syntax.

You can read about these improvements and some other highlights below. You can find all the changes in this version in the Release Notes .

Publish to Posit Connect Cloud

You can now publish documents and websites to Posit Connect Cloud directly from the command line. For example, publish your Quarto website project with:

1

quarto publish posit-connect-cloud

Posit Connect Cloud is a hosted platform for sharing data applications and documents without managing your own infrastructure. It includes a free tier for unlimited static document publishing. Read more in Publishing > Posit Connect Cloud .

Improvements to Typst Support

Quarto 1.9 brings substantial improvements to Typst output:

• Book projects can now render to Typst via the bundled orange-book extension, with chapter numbering, cross-references, and professional textbook styling.
• Article layout support lets you place content in the margins, create full-width figures, or add side notes.
• New options: mathfont, codefont, linestretch, linkcolor, citecolor, filecolor, thanks, and abstract-title.
• Theorem styling with four appearance options: simple, fancy, clouds, or rainbow.

See this blog post for details on all the Typst improvements.

PDF Accessibility (Experimental)

We’re rolling out experimental support for PDF accessibility standards in 1.9. The new pdf-standard option enables PDF/A archival formats and PDF/UA accessibility compliance for both LaTeX and Typst outputs. Alt text from fig-alt attributes now passes through to PDF for screen reader support, and Typst gains support for alt text on cross-referenced equations.

Read more in our PDF Accessibility and Standards blog post or the documentation for LaTeX and Typst .

Output for LLMs

Quarto can now generate llms.txt format output for your website, making your content more accessible to large language models and AI-powered tools.

Enable it in your website configuration:

1
2
3

website:
  title: "My Documentation"
  llms-txt: true

When you render your site, Quarto creates:

• An llms.txt index file at the root of your site listing all pages
• A .llms.md markdown file alongside each HTML page (e.g., guide.html gets guide.llms.md)

The markdown files contain clean versions of your content—navigation, sidebars, and scripts are stripped out; tables, code blocks, and callouts are converted to standard markdown.

Read more, including how to customize what appears in LLM output, in Websites > Output for LLMs .

quarto use brand Command

Keep your project’s brand assets in sync with an external source using the new quarto use brand command:

1

quarto use brand myorg/shared-brand

The command copies brand files from a GitHub repository, local directory, or zip archive into your project’s _brand/ directory. Quarto walks you through each step—confirming trust for remote sources, creating the directory if needed, and asking whether to overwrite or remove files.

See Guide > Brand for --dry-run, --force, and other options.

List Tables

List tables provide a new syntax for creating tables with complex content—multiple paragraphs, code blocks, or nested lists—using familiar bullet syntax instead of grid table formatting:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

::: {.list-table}
- - Function
  - Description

- - `sum()`
  - Add values:

    ```python
    sum([1, 2, 3])
    ```

- - `len()`
  - Count items:

    - Works on lists
    - Works on strings
:::

sum([1, 2, 3])

Each top-level bullet represents a row; nested bullets represent cells. This syntax is much easier to maintain than grid tables, especially when cells contain code or other block elements.

List tables support all the usual table features: captions, cross-references, column widths, and alignment. Thanks to Martin Fischer for the original development, with contributions from Albert Krewinkel and William Lupton.

Find all the details in Guide > Tables .

Other Highlights

• Search Result Highlighting : Improved highlighting of search terms on destination pages, with persistent marks, automatic tab activation for matches inside tabsets, and cross-element highlighting for multi-word searches.

• Privacy-focused features for websites:

  • A privacy-first default for cookie consent : The default for cookie consent has changed to type: express, providing opt-in consent that blocks cookies until users explicitly agree. This privacy-conscious default is designed with modern privacy regulations in mind.

  • Algolia Search Insights avoids cookies : Use Algolia Insights now uses persistent cookies only if cookie-consent is active, and the user has opted-in.

  • Use Plausible Analytics : Add privacy-friendly Plausible Analytics to websites via the plausible-analytics configuration option.

• aria-label for videos : Improve accessibility of embedded videos by providing custom descriptive labels for screen readers instead of the default “Video Player” label.

• New syntax-highlighting Option : Replaces the deprecated highlight-style (Pandoc 3.8). Supports style names, custom .theme files, none, or idiomatic for format-native highlighting.

• Metadata and brand extensions now work without a _quarto.yml project. A temporary default project is created in memory.

• Engine extensions allow replacement of the execution engine:

  • Julia is now a bundled extension instead of being built-in.
  • quarto-marimo will soon change from a filter extension to an engine extension.
  • New quarto create extension engine command.
  • New quarto call build-ts-extension command.
  • New Quarto API for engine extensions to use. (This is in flux and will not be documented for the next few releases, but there is a dev blog post about it .)

Dependency updates:

• pandoc updated to 3.8.3
• typst updated to 0.14.2
• esbuild updated to 0.25.10
• deno updated to 2.4.5
• mermaid updated to 11.12.0

Acknowledgements

One of the early proposals for PDF accessibility and alt text in the LaTeX ecosystem was provided to us by Sam Schiano and Sophie Breitbart . We want to thank them for bringing into our attention the approach they used in their {asar} R package , which influenced some of our design.

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

CoryMcCartan , DanChaltiel , Data-Wise , FrankwaP , Joao-O-Santos , LukasDSauer , MBe-iUS , MarcoPortmann , MariaBarrioSchez , MateusMolina , Selbosh , ThePurox , TucoFernandes , aecoleman , amirhome61 , andrewheiss , azankl , bensoltoff , bruvellu , byzheng , cbrnr , chendaniely , chi-raag , christopherkenny , coatless , cynthiahqy , darwindarak , davidskalinder , dmenne , fconil , fkgruber , fkohrt , fredguth , gadenbuie , github-actions[bot] , gsathler-vi , hamgamb , herosi , icarusz , idavydov , jeremy886 , jkrumbiegel , jmcphers , jonas37 , jorherre , jreades , jromanowska , jtbayly , juleswg23 , juliasilge , kathsherratt , kusnezoff-alexander , lrrichter , lwjohnst86 , maelle , matthiasbaitsch , mipmip , mstrms2000 , multimeric , mvuorre , mykolaskrynnyk , nichtich , nithinmkp , nrichers , orbsmiv , paytonej , petrelharp , phongphuhanam , pm-gusmano , posit-snyk-bot , prosoitos , rabyj , sasja-san , sbwiecko , serialc , spaette , spraetor , stragu , szimmer , the-solipsist , thomasp85 , yyzeng , zhe00a .

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

We are once again chuffed to offer summer internships.

Our internship program has been a great success over the years. If you want to know what it is like, many of our alumni have written about it:

• 2016: Thomas Lin Pederson
• 2017: Lucy D’Agostino McGowan and Kara Woo
• 2018: Alex Hayes , Fanny Chow , Irene Steves , and Dana Paige Seidel
• 2019: Marly Gotti and Dewey Dunnington
• 2020: Simon Couch
• 2022: Mike Mahoney
• 2025: Frances Lin .

Three past interns are current Posit employees: Thomas Lin Pederson, Kara Woo, and Simon Couch.

2026 Positions

This year, we have four positions in different groups. The positions are US-based and range from 10-12 weeks, starting on May 26, 2026. See the link at the bottom for the details.

Skills and Evals Intern (PyData Team)

The PyData team is looking for an intern to help make AI agents better at using our Python open-source projects by writing skills and evaluations for common user tasks.

The core of the role is to identify the tasks users perform with our tools — such as Plotnine and Great Tables — translate them into clear skill definitions that agents can use, and build evaluations that measure whether agents can reliably complete those tasks. This includes writing prompts, creating example workflows, and developing automated tests that measure how well agents perform. A major focus will be on applying the emerging skills format, while the broader goal is to improve documentation, examples, and API design across the PyData ecosystem in ways that make our tools work better with AI-assisted workflows.

R Modeling Intern (Tidymodels Team)

The tidymodels R internship is focused on different tasks, including: expand content on tidymodels.org , expanding tabular deep learning models (in brulee ), additional performance metrics for survival analysis models , modernizing the caret package , and/or Rust bindings for predictive models. The intern is welcome to suggest R-based projects focused on modeling and/or data analysis.

Shiny Accessibility and Testing Intern (Shiny Team)

The Shiny team is looking for an intern to help advance accessibility and testing across the Shiny framework. You’ll audit Shiny components against Web Content Accessibility Guidelines (WCAG), implement fixes, improve test coverage, and contribute to documentation that helps the broader community build accessible Shiny apps.

Some of the harder problems in this role aren’t strictly code problems. Shiny’s components are built for flexible, abstract usage, so you can’t always anticipate how they’ll end up on a page. Making them accessible means understanding HTML semantics and WCAG well enough to exercise good judgment and make sensible compromises when there isn’t one clear right answer. Candidates should be comfortable with Git and GitHub, have solid working knowledge of HTML/CSS, and have experience in at least one of R, Python, or JavaScript. Familiarity with WCAG, assistive technology, automated testing frameworks, or open-source workflows is a plus.

Software Engineering Intern (Posit Connect Team)

The Posit Connect team is looking for an intern to contribute to the development and quality of Connect, Posit’s professional platform for publishing and sharing data science and AI applications at scale. The primary focus of the internship will be to contribute reports and applications to the Connect Gallery , an open-source collection of useful extensions and example content. These Python, R, and Quarto projects help data science teams realize the full potential of the product and allow us to experiment with new features. In the process of building these apps, you will have the opportunity to contribute to the Connect product as well.

Applying

To apply, make sure that you have a GitHub handle and follow this link:

https://posit.co/job-detail/?gh_jid=7674250003

We can’t wait to get started and look forward to reading your applications.

Why we built our own notebook editor

We built the Positron Notebook Editor to treat your .ipynb files as first-class citizens in an IDE tailored specifically for data science workflows.

Up to this point, Positron used the legacy Code OSS notebook editor that powers VS Code. While functional, this editor was designed for general-purpose development and not specifically for data science workflows. The tradeoffs show up in small ways that compound over time: limited context for AI assistance, no deep integration with your variables or data, and a user experience that treats .ipynb files as just another file type.

We wanted notebooks to feel like a first-class part of a data science IDE, so we built our own native notebook editor.

If you missed the original February announcement , that post covers our initial reasoning in more detail.

What’s included out of the box

The Positron Notebook Editor brings the core capabilities of Positron directly into your notebook workflow:

Variables Pane : Variables update in real time as you run cells. No need to print or inspect manually.

Data Explorer : When a cell returns a Pandas or Polars DataFrame, you get an inline data viewer. Open the full Data Explorer to sort, filter, and profile your data. Any filtering or cleaning you do can be converted into code, so your analysis stays reproducible without writing repetitive df.head() or df.describe() calls.

AI Assistant : The Assistant has access to your notebook’s full context, including cell states, execution history, and outputs like images and tables. It can suggest edits, reorder cells, and run code with your permission. You can inspect exactly what context it’s using and follow along as it works.

Help Pane : Python and R documentation is available inline, with hyperlinks, without switching to a browser.

Publisher : Deploy your .ipynb notebooks directly to Connect or Connect Cloud, where you can manage access, schedule runs, and view telemetry.

A sample notebook workflow

Now that you have all these capabilities in one place, your workflow might look something like this:

1. Import your data using Pandas or Polars.
2. Run your notebook cells and watch variables update in the pane as cells run.
3. Explore your DataFrame in the inline Data Explorer. Sort and filter without writing any code.
4. Use Assistant to generate a visualization based on your filtered data or AI quick actions to recommend next steps.
5. When the analysis is ready to share, use an AI action to add markdown headers and notes.
6. Publish the notebook to Connect or Connect Cloud to share with your colleagues.

What’s coming next

The roadmap includes SQL support, improved version control, R improvements, and more. You can view and vote on items in the GitHub roadmap .

Get started with the alpha

1. Download Positron and install a release from February 2026 or later.
2. Enable the alpha by setting positron.notebook.enabled to true in your settings.
3. Try the tutorial repository for examples that use the new features.
4. Share feedback in GitHub Discussions or book time to talk with us directly .

We’re excited to hear how you use the Positron Notebook Editor as we continuously improve the experience.

Recently, Rich and I were poking around transit data, and we were struck by the amount of structuring that goes into transit timetables.

For example, consider this weekend rail schedule table from SEPTA, Philadelphia’s transit agency.

Notice these big pieces:

• The vertical text on the left indicating trains are traveling “TO CENTER CITY”.
• The blue header, and spanner columns (“Services” and “Train Number”) grouping related columns.
• The striped background for easier reading. Also the black background indicating stations in Center City (the urban core).

Tables like this often have to be created in tools like Illustrator, and updated by hand. At the same time, when agencies automate table creation, they often sacrifice a lot of the assistive features and helpful affordances of the table.

We set out to recreate this table in Great Tables (and by we I mean 99% Rich). In this post, I’ll walk quickly through how we recreated it, and share some other examples of transit timetables in the wild. For the theory behind why tables like this are useful, see The Design Philosophy of Great Tables .

The final result

Here’s a look at our quick version in Great Tables. In this post we’ll walk through quickly how we created it, but wanted to treat you to the final result up front! Note that the table is fully in HTML for accessibility.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

from great_tables import GT, html, style, loc, google_font
import polars as pl
import polars.selectors as cs

stops = pl.read_csv("chw-stops.csv")
times = pl.read_csv("times.csv")

stop_times = times.join(other=stops, on="stop_name", maintain_order="left").select(
    pl.lit("To Center City").alias("direction"), pl.col("*")
)


def h_m_p(s):
    h, m, _ = [int(part) for part in s.split(":")]
    ap = "a"

    if h > 12:
        h -= 12
        ap = "p"
    return f"{h}:{m:02d}{ap}"


def tick(b):
    return "✓" if b else ""


transit_table = (
    GT(stop_times)
    .tab_stub(groupname_col="direction")
    .tab_header("Saturdays, Sundays, and Major Holidays")
    .cols_hide(columns=["stop_url", "zone_id", "stop_desc", "stop_lat", "stop_lon", "stop_id"])
    .fmt(h_m_p, columns=cs.matches(r"^[0-9]{4}$"))
    .fmt(tick, columns=cs.starts_with("service_"))
    .cols_label(
        stop_name="Stations",
        service_access="A",
        service_cash="C",
        service_park="P",
        fare_zone=html("Fare<br>Zone"),
    )
    .tab_spanner(label="Services", columns=cs.starts_with("service_"))
    .tab_spanner(label="Train Number", columns=cs.matches(r"^[0-9]{4}$"))
    .cols_move_to_start("fare_zone")
    .cols_move_to_start(cs.starts_with("service_"))
    .cols_width(cases={c: "20px" for c in stop_times.columns if c.startswith("service_")})
    .cols_width(cases={c: "60px" for c in stop_times.columns if c.startswith("8")})
    .opt_row_striping(row_striping=True)
    .cols_align(align="center", columns="fare_zone")
    .cols_align(align="right", columns=cs.matches(r"^[0-9]{4}$"))
    # style header
    .tab_style(
        locations=loc.header(),
        style=style.css(
            "background-color: rgb(66, 99, 128) !important; color: white !important; font-size: 24px !important; font-weight: bold !important; border-width: 0px !important;",
        ),
    )
    # style vertical text on left
    .tab_style(
        locations=loc.row_groups(),
        # TODO: rotate text vertically
        style=style.css(
            "writing-mode: sideways-lr; padding-bottom: 25% !important; font-size: 24px !important; font-weight: bold !important; text-transform: uppercase !important;"
        ),
    )
    .tab_style(
        style=style.css(
            "background-color: black !important; color: white !important; border-top: none !important; border-bottom: none !important;"
        ),
        locations=loc.body(columns=None, rows=list(range(-4, -1))),
    )
    .tab_style(
        style=style.css(
            """
                border-top: none !important;
                border-bottom: none !important;
                border-right: solid white 2px !important;
                color: white !important;
            """
        ),
        locations=loc.body(columns=~cs.matches(r"^[0-9]{4}$"), rows=list(range(-4, -1))),
    )
    .tab_style(
        style=style.css("border-right: solid black 2px !important;"),
        locations=loc.body(columns=~cs.matches(r"^[0-9]{4}$"), rows=list(range(0, 10)) + [13]),
    )
    .tab_options(
        row_striping_background_color="#A9A9A9",
        row_group_as_column=True,
    )
    .opt_table_outline()
    .opt_table_font(font=google_font("IBM Plex Sans"))
)

transit_table

Reading in stops and times

For this example, I simplified SEPTA’s transit data down to two pieces:

• chw-stops.csv - detailed information about each stop location.
• times.csv - when a train arrives at a stop on the Chesnut Hill West line. Each row is a stop location, and each column is a trip (e.g. the 6:51am train).

To make the final table we joined these two together, to get the trips and stop information together.

1
2
3
4

import polars as pl

stops = pl.read_csv("chw-stops.csv")
times = pl.read_csv("times.csv")

Here’s a quick preview of stops.

1

stops.select("stop_name", "service_access", "service_cash").head()

Notice that the table above has the name of each stop, and a 1 or 0 in the service_access column to indicate whether the stop is wheelchair accessible. Note that a big challenge for this specific route is that sometimes boarding the train requires using steps, and sometimes the station requires using steps. For example, Chelton Ave (not shown) does not require steps to board the train, but the station itself is not wheelchair accessible because of steps to get to the platform.

Here’s a quick preview of the times.

1

times.head(3)

Notice that each trip is a column (i.e. a train leaving from Chesnut Hill West at a specific time), and each row is a stop. For example, the 8210 train is the 6:51am train. (Note that schedules and train numbers can change, so this data may be out of date).

Joining these together gives us stop_times, with trips and stop information on the columns.

1
2
3
4
5

stop_times = times.join(other=stops, on="stop_name", maintain_order="left").select(
    pl.lit("To Center City").alias("direction"), pl.col("*")
)

stop_times.head(3)

Notice that in the table above, the first row tells us when each train leaves Chesnut Hill West, and information about the Chesnut Hill West stop.

Creating the table

Below is the code for the table, with 5 key activities marked with comments. For example, the first is creating high level structure, like the header and the left-hand “To Center City” stub. Others include formatting in checkmarks, customizing columns (e.g. their width), and styling (e.g. setting background colors and fonts).

It’s a lot to take in, but worth it!:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104

from great_tables import GT, html, style, loc, google_font
import polars as pl
import polars.selectors as cs


def h_m_p(s):
    h, m, _ = [int(part) for part in s.split(":")]
    ap = "a"

    if h > 12:
        h -= 12
        ap = "p"
    return f"{h}:{m:02d}{ap}"


def tick(b):
    return "✓" if b else ""


transit_table = (
    GT(stop_times)

    # Create left-hand stub, top header, and hide extra cols --------
    .tab_stub(groupname_col="direction")
    .tab_header("Saturdays, Sundays, and Major Holidays")
    .cols_hide(
        columns=["stop_url", "zone_id", "stop_desc", "stop_lat", "stop_lon", "stop_id"]
    )

    # custom functions for checkmarks and time formatting -----------
    .fmt(h_m_p, columns=cs.matches(r"^[0-9]{4}$"))
    .fmt(tick, columns=cs.starts_with("service_"))

    # relabel columns and add spanners (labels over columns) --------
    .cols_label(
        stop_name="Stations",
        service_access="A",
        service_cash="C",
        service_park="P",
        fare_zone=html("Fare<br>Zone"),
    )
    .tab_spanner(label="Services", columns=cs.starts_with("service_"))
    .tab_spanner(label="Train Number", columns=cs.matches(r"^[0-9]{4}$"))

    # move columns around and setting their width and alignment -----
    .cols_move_to_start("fare_zone")
    .cols_move_to_start(cs.starts_with("service_"))
    .cols_width(
        cases={c: "18px" for c in stop_times.columns if c.startswith("service_")}
    )
    .cols_width(cases={c: "60px" for c in stop_times.columns if c.startswith("8")})
    .cols_align(align="center", columns="fare_zone")
    .cols_align(align="right", columns=cs.matches(r"^[0-9]{4}$"))

    # styles: striping, vertical text, background colors, fonts -----
    # style header
    .tab_style(
        locations=loc.header(),
        style=style.css(
            "background-color: rgb(66, 99, 128) !important; color: white !important; font-size: 24px !important; font-weight: bold !important; border-width: 0px !important;",
        ),
    )
    # style vertical text on left
    .tab_style(
        locations=loc.row_groups(),
        style=style.css(
            "writing-mode: sideways-lr; padding-bottom: 25% !important; font-size: 24px !important; font-weight: bold !important; text-transform: uppercase !important;"
        ),
    )
    .tab_style(
        style=style.css(
            "background-color: black !important; color: white !important; border-top: none !important; border-bottom: none !important;"
        ),
        locations=loc.body(columns=None, rows=list(range(-4, -1))),
    )
    .tab_style(
        style=style.css(
            """
                border-top: none !important;
                border-bottom: none !important;
                border-right: solid white 2px !important;
                color: white !important;
            """
        ),
        locations=loc.body(
            columns=~cs.matches(r"^[0-9]{4}$"), rows=list(range(-4, -1))
        ),
    )
    .tab_style(
        style=style.css("border-right: solid black 2px !important;"),
        locations=loc.body(
            columns=~cs.matches(r"^[0-9]{4}$"), rows=list(range(0, 10)) + [13]
        ),
    )
    .tab_options(
        row_striping_background_color="#A9A9A9",
        row_group_as_column=True,
    )
    .opt_row_striping(row_striping=True)
    .opt_table_outline()
    .opt_table_font(font=google_font("IBM Plex Sans"))
)

transit_table

Other schedules in the wild

MetroTransit in Minneapolis uses a transposed format, with stops as columns and trips as rows. Here’s an example from their Route 2 bus timetable :

This is useful when there a lot of trips, because with trips on the rows readers can scroll down (versus needing to scroll sideways).

The MTA in New York City is similar. Here’s an example of their bx1 bus route timetable :

What I like about all these tables is they highlight the structure behind bus and train routes. Sometimes they skip certain stops. But realistically, what makes them a route is that trips tend to make the same stops over and over.

A common alternative to using these tables is to do routing from a set start to end point. For example, below is a form for selecting a start and end point on SEPTA’s website, with a resulting table of departure and arrival times.

Notice that the table has removed a lot of information about intermediate stops people might not care about.

In conclusion

Transit tables are richly structured displays of information. They take advantage often of the fact that a train route like Chesnut Hill West is a fixed set of stops–so that stops can be on the rows, and arrival times for trips throughout the day can be on the columns.

This is intuitive to people reading transit timetables, but can get tricky to display on the web. Timetables are a core part of navigating transit networks, so it was a fun experiment to try replicating one of Septa’s timetables in Great Tables!

Last week, I had the pleasure of giving a talk to R-Ladies Abuja about how Positron can grow with you as you work on data that is too large for your laptop. The talk was recorded, and you can find it on YouTube here:

I opened this talk discussing how I first learned about these “beyond your laptop” technologies, typically in a organization where these technologies were already in use and seemed specific to infrastructure there. I later came to understand that these technologies are actually related to each other and understanding one can really help when you need to pick up another one. I pointed out some of the Positron features that are designed to make it easier to work with these technologies:

• Data Explorer
• Connections Pane
• Remote SSH sessions

Check out my slides

If you’d like to check out my slides, they are available as well :

2025 was a big year for PDF accessibility. LaTeX and Typst both released support for PDF tagging and accessibility standards, just in time for new regulations in the EU (June 2025) and US (April 2026).

Quarto 1.9 brings this support to you as a Quarto user.

What PDF Standards Do

Currently LaTeX supports the newer UA-2 standard, and Typst supports the older UA-1 standard. Typst is likely to have UA-2 support later in 2026.

Both standards instruct the PDF renderer to provide screen readers:

• The semantic structure of the text (title, heading, paragraph, figure, etc)
• The natural reading order
• Spatial coordinates for highlighting and assistive navigation
• Required metadata such as title and language

How to enable a PDF Standard in Quarto

In Quarto 1.9, specify a PDF standard for your document or project with pdf-standard

1
2
3

format:
  pdf:
    pdf-standard: ua-2

1
2
3

format:
  typst:
    pdf-standard: ua-1

pdf-standard takes a single standard name or list of standard names. PDF version is used if provided in the list, but otherwise inferred from the standard.

If you specify a PDF standard, Quarto first instructs LaTeX or Typst to use the standard when producing the PDF, and then validates the output PDF against the standard using veraPDF, an open-source PDF validation tool. If veraPDF is not installed, you’ll get a warning but still receive a PDF – it just won’t be validated.

1

quarto install verapdf

When a document passes validation, you’ll see output like:

[verapdf]: Validating my-document.pdf against PDF/UA-2... PASSED

Creating accessible PDFs

Quarto’s Markdown-based workflow handles many accessibility requirements automatically:

• Document metadata (title, author, date, language) flows into the PDF’s built-in metadata fields.
• The semantic structure of Markdown satisfies PDF tagging requirements. For Typst this is always enabled; for LaTeX it is enabled when you specify a standard that requires it.
• Alt text for images is carried through to the PDF for screen readers.

But you do need to make sure your document has:

• A title in the YAML front matter.
• Alt text for every image, specified with fig-alt. See Figures for details.

See the LaTeX and Typst documentation for more details.

If your document fails validation

LaTeX does not perform validation during PDF generation, so if veraPDF validation fails, that’s a warning, and you still get a partially-accessible PDF as long as you use pdf-standard: ua-2.

Typst fails and does not produce a PDF if its built-in validation fails during PDF generation. However, in Typst all accessibility features are on by default, so you can generate a partially-accessible PDF by rendering without pdf-standard.

Current limitations

We ran our test suite – 188 LaTeX examples and 317 Typst examples – to find where Quarto PDFs do not yet pass UA-1 or UA-2, and where users will need to change their documents.

LaTeX

Margin content is the biggest structural blocker. If you use .column-margin divs, cap-location: margin, reference-location: margin, or citation-location: margin, the resulting PDF will not pass UA-2. The underlying sidenotes and marginnote LaTeX packages do not cooperate with PDF tagging .

(Margin content does work with Typst and passes UA-1 – see Typst Article Layout .)

There are smaller upstream issues in Pandoc, LaTeX, and LaTeX packages, documented here .

Typst

In our tests, Typst catches every UA-1 violation, and fails to generate the PDF. veraPDF did not detect any violation that Typst did not.

Typst also seems to do a very good job of generating UA-1 compliant output by default – almost all errors were due to missing titles or missing alt text.

However, we did discover that Typst books are not yet compliant. There is a structural problem with the Typst orange-book package and we’ll work with the maintainers to correct it.

Conclusion

Although Typst currently targets an the earlier UA-1 standard, today it seems to offer better PDF accessibility than LaTeX.

We expect PDF accessibility support to improve through the LaTeX ecosystem throughout 2026 as awareness of UA-2 and the new regulations spreads.

If you run into accessibility issues with PDF output, please search the Quarto discussions and open a new one with the accessibility label for any issues you discover.

Let’s say you developed a dashboard to display women’s international soccer matches. You are proud of what you have built and you eagerly show it to a colleague:

Colleague: “Amazing! Can you show me the soccer matches for the FIFA World Cup only?”

You: “Of course, let me filter it down for you and select the FIFA World Cup tournaments”

Colleague: “Interesting, can you show me all the matches in which The Netherlands have played?”

You: “Eh… Well, I could, but I just have to include a country filter in my dashboard then!”

Right. How are we supposed to filter down to a specific country if there is no input for it? And what about getting summary statistics for countries or players? By now it becomes painfully clear that our soccer dashboard has its limits.

This is exactly the moment when  querychat  becomes interesting. It is a multilingual package that allows you to chat with your data using natural language queries. No more clicking, no more limited filters, just you and your questions. And in this article, you’re going to learn everything about it!

To bring querychat to life, we will keep returning to two examples:

• The classic diamonds dataset. After all, diamonds are a girl’s best friend, and a data scientist’s too! The familiar dataset offers a mix of variables such as cut, colour, clarity and price, which makes it ideal for all sorts of natural language questions. You might wonder about average prices for particular cuts, or you want to compare colours, look at how clarity affects value, or explore simple patterns in the data. In other words, it is a perfect playground for testing how well natural language queries behave on structured data.
• SheScores, the soccer dashboard that you were so proud of earlier. This app originates from the shiny::conf(2024) workshop  “Shiny 101: The Modular App Blueprint” , although it has been tweaked to make it a bit more interesting and updated with matches through to November 2025.

• Python
• R

Both datasets set the stage nicely, so let’s roll the ball and see how querychat plays. We’re talking about soccer after all!

Full code available on GitHub

Instead of copy-pasting the content of this blog into your favourite IDE, you can also pull the project from GitHub and follow along. All the code is available in both Python and R.

Short on time?

Jump straight to the SheScores app with querychat or visit the querychat website

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.

Recommended models

In this blog we’ll use Claude Sonnet 4.5 from Anthropic. Other good choices would be GPT-4.1 (the current default for querychat) and Google Gemini 3.0 (as of November 2025).

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.

1

ANTHROPIC_API_KEY=yourkey

1
2

from dotenv import load_dotenv
load_dotenv()

1

ANTHROPIC_API_KEY=yourkey

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

1

pip install querychat

1

uv add querychat

1

import querychat

1

install.packages("querychat")

1

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

1

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:

1
2
3
4
5
6

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

1

shiny run --reload diamonds-app.py 

1
2
3
4

library(ellmer)
library(ggplot2)

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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.

• Python
• R

Custom branding

Do you notice the nice green touches and custom font in this demo app? That’s because the project we’ll be using in this article uses brand.yml : a simple, portable YAML file that codifies brand guidelines into a format that can be used by Quarto, Python and R. And in this case, it works beautifully for Shiny. Curious to see what such a _brand.yml file looks like? You can check it out here .

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.

1

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.

1
2
3
4
5
6

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

-- 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

1
2
3
4
5
6

        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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

-- 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

1
2
3
4
5
6

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?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

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.

LLMs can make mistakes

Note that it’s still an LLM that generates these queries. LLMs can make mistakes. The nice thing about querychat though, is that you can inspect the SQL query yourself.

Most issues fall into two categories:

• Query errors: the SQL may fail to run or may not fully reflect what you intended. When it fails, the model will often try again. In this case, giving more context about the data can help.
• Result errors: even when the query is correct, the model may misunderstand or oversimplify the results, especially if that result is large or complex. The result might be that key insights are missed or misinterpreted.

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!

• Python
• R

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.

QueryChat object

You call QueryChat to initialise a QueryChat object (often called qc), like so:

1

qc = QueryChat(...)

1

qc <- QueryChat$new(...)

You can pass QueryChat several arguments:

• data_source and table_name

  These are the two most important arguments: they specify your data source and the name of your table that can be used for the SQL queries. The data source can be your data frame, a tibble, a table or any other Python or R data object, and the table name is usually the variable name of your data frame. In our example our data_source was diamonds, which we also stored in a variable called diamonds.

  • Python
  • R

  1	qc = QueryChat(diamonds, "diamonds")

  Generally, in R, the table name isn’t required as it can be inferred from the variable name. However, it is required when you use a database connection, which we’ll use later.

  1 2 3 4

  qc <- QueryChat$new( diamonds, "diamonds" )

  You’re not limited to data objects: you can also pass a database connection to data_source. We’ll come back to that later.

• client

  We used the client argument before: we use it to tell querychat that we want to use Claude Sonnet 4.5 (or any other model). This gets us back at the starting point of our Diamonds “quick launch” app.

  • Python
  • R

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

  Alternatively, you can set the client in options the QUERYCHAT_CLIENT environment variable.

  1 2 3 4 5

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

  Alternatively, you can set the client in options with options(querychat.client = "claude/claude-sonnet-4-5").

• id

  This is an optional argument, and if it’s not given it’s derived from the table_name. When to use it? If you want to work with multiple QueryChat instances , for example.

• greeting

  A nice greeting message to display to your users. It’s the first thing your users see, so you better make it good! If not provided, one is generated at the start. While this one looks fine on first sight, it’s rather slow and wasteful (it costs extra tokens because it’s generated every single time). Also, because it’s generated on the fly, it’s far from consistent. Earlier, when we ran the “quick launch” app, you already might have noticed that it generated a warning message:

  • Python
  • R

  1	Warning: No greeting provided; the LLM will be invoked at conversation start to generate one. For faster startup, lower cost, and determinism, please save a greeting and pass it to init(). You can also use `querychat.greeting()` to help generate a greeting.

  1 2 3 4

  Warning message: No greeting provided; the LLM will be invoked at conversation start to generate one. • For faster startup, lower cost, and determinism, please save a greeting and pass it to QueryChat$new(). ℹ You can generate a greeting with $generate_greeting().

  So yes, we need a greeting! You can add your own greeting by providing a string in Markdown format.

  Some inspiration on what you can put in there: basic instructions, suggestions for filtering, sorting or analysing the data, addressing data privacy concerns, or letting people know where they can get support if something goes wrong.

  And if you don’t feel like writing your own greeting, or if you feel uninspired, you can let querychat handle it! Simply use generate_greeting():

  • Python
  • R

  1 2 3 4 5 6 7 8 9 10 11

  qc = QueryChat(diamonds, "diamonds", client="anthropic/claude-sonnet-4-5") # Generate a greeting with help from the LLM greeting_text = qc.generate_greeting() # Save it with open("diamonds_greeting.md", "w") as f: f.write(greeting_text) # Then use the saved greeting in your app qc = QueryChat(diamonds, "diamonds", client="anthropic/claude-sonnet-4-5", greeting=Path("diamonds_greeting.md"))

  Which give us this nice greeting:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  # Welcome! 👋 I'm here to help you explore and understand your diamonds dataset. I can filter and sort the data, answer questions with SQL queries, and help you discover insights. Here are some ideas to get started: ## Explore the data * <span class="suggestion">Show me the most expensive diamonds</span> * <span class="suggestion">What's the average price of diamonds by cut quality?</span> * <span class="suggestion">How many diamonds are in each clarity category?</span> ## Filter and analyze * <span class="suggestion">Show only ideal cut diamonds over 2 carats</span> * <span class="suggestion">Filter to diamonds with the best color grades (D, E, F)</span> * <span class="suggestion">Which cut has the highest average price per carat?</span> What would you like to explore first?

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  qc <- QueryChat$new( diamonds, "diamonds", client = "claude/claude-sonnet-4-5" ) # Generate a greeting with help from the LLM greeting_text <- qc$generate_greeting() # Save it writeLines(greeting_text, "diamonds_greeting.md") # Then use the saved greeting in your app qc <- QueryChat$new( diamonds, "diamonds", client = "claude/claude-sonnet-4-5", greeting = "diamonds_greeting.md" )

  Which give us this nice greeting:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  # Welcome to the Diamond Dashboard! 💎 I'm here to help you explore and analyze this dataset of diamond characteristics and prices. I can filter and sort the data, answer questions, and help you discover interesting patterns. Here are some ideas to get started: **Explore the Data** * <span class="suggestion">What's the average price of diamonds in this dataset?</span> * <span class="suggestion">How many diamonds are there in each clarity category?</span> * <span class="suggestion">Which diamond has the highest price?</span> **Filter and Sort** * <span class="suggestion">Show me only Ideal cut diamonds</span> * <span class="suggestion">Filter to diamonds over 2 carats and sort by price</span> * <span class="suggestion">Show me the most expensive diamonds with VS1 clarity</span> What would you like to explore?

  You can see that the generated greeting contains a span HTML tag: <span class="suggestion">…</span>. If you make your own greeting, you can use this tag to automatically populate the chatbox when it’s being clicked.

• data_description

  querychat automatically helps the LLM by providing things like the column names and datatypes of your data (the schema information), but results can be even more accurate when you provide additional context in the data description. There’s no specific format needed, and you can add whatever information you like. To give some inspiration, this is what we could say about the diamonds dataset:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  # Diamonds Dataset Description A structured dataset describing physical and quality attributes of individual diamonds, commonly used to model or predict price. ## Fields - carat (float) — Diamond weight - cut (category) — Cut quality: Fair, Good, Very Good, Premium, Ideal - color (category) — Color grade from D (best) to J (worst) - clarity (category) — Clarity grades: I1, SI2, SI1, VS2, VS1, VVS2, VVS1, IF - depth (float) — Total depth percentage - table (float) — Table width percentage - price (int) — Price in USD - x (float) — Length in mm - y (float) — Width in mm - z (float) — Depth in mm

  We can save this in a Markdown file and pass it on to querychat:

  • Python
  • R

  1 2 3 4 5 6 7

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

  1 2 3 4 5 6 7

  qc <- QueryChat$new( diamonds, "diamonds", client = "claude/claude-sonnet-4-5", greeting = "diamonds_greeting.md", data_description = "diamonds_data_description.md" )

• extra_instructions

  For further tweaking the LLMs behaviour you can use extra_instructions. You can go nuts here: make it talk like a pirate, use an emoji in every sentence, or use an annoying amount of diamond-related phrases. You can also use this section for more practical guidance like notes on preferred spelling, tone, or handling of sensitive terms. For example:

  1 2 3 4 5

  - Assume the user doesn't know much about diamonds: keep explanations simple and accessible. - When describing diamond attributes, default to plain English. If a term is highly technical, include a short clarification. - Maintain consistent spelling in British English.

  • Python
  • R

  1 2 3 4 5 6 7 8

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

  1 2 3 4 5 6 7 8

  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" )

• categorical_threshold

  This threshold applies to text columns, and sets the maximum number of unique values to consider it as a categorical variable. The default is 20.

• prompt_template

  The prompt_template is a more advanced parameter to provide a custom prompt template. If you don’t provide it, querychat will use the built-in prompt, which we’ll inspect a little bit closer later.