mirai: Asynchronous Evaluation Framework for R

You can create independent pools of workers using the .compute argument. This allows you to separate workloads (e.g., CPU-bound vs GPU-bound tasks).

• daemons(n, .compute = "name"): Creates a new compute profile.
• local_daemons("name"): Switches the active compute profile for the duration of the current function.
• with_daemons("name", { ... }): Switches the active compute profile for a specific block of code.

# Create independent pools
daemons(4, .compute = "cpu")
daemons(2, .compute = "gpu")

# Run tasks on specific profiles
m1 <- mirai(cpu_work(), .compute = "cpu")
m2 <- mirai(gpu_work(), .compute = "gpu")

# Switch active profile for a block
with_daemons("workers", {
  m <- mirai(task())
  m[]
})

The mirai() function sends tasks to daemons, which are persistent R worker processes.

• Host/Client Model: The host listens at a URL, and daemons dial in to pull work.
• Dispatcher Thread: An in-process thread handles scheduling, cancellation, and bounded queues.
• Scalability: You can add or remove daemons at any time and direct tasks to different compute profiles (e.g., CPU pool, GPU pool, or remote clusters) from the same session.
• Performance: Round-trip latency is in the microsecond range.

Daemons start with no user packages loaded. To use package functions inside a mirai() call or a mirai_map() callback, you must use one of the following patterns:

1. Namespace qualification (Best Practice): Use package::function() directly in the expression.
2. Load inside the expression: Call library(package) within the curly braces of the expression.
3. Pre-load on all daemons: Use everywhere(library(package)) to load the package on all existing daemons before running tasks.

# CORRECT: namespace-qualify
m <- mirai(dplyr::filter(df, x > 5), .args = list(df = my_df))

# CORRECT: load inside the expression
m <- mirai({
  library(dplyr)
  filter(df, x > 5)
}, .args = list(df = my_df))

# CORRECT: pre-load on all daemons
everywhere(library(dplyr))
m <- mirai(filter(df, x > 5), .args = list(df = my_df))

You can configure daemons() to run on various infrastructures using specific configuration functions:

Example for an HPC cluster using Slurm:

daemons(
  n = 6,
  url = host_url(tls = TRUE),
  remote = cluster_config(options = "#SBATCH --mem=10G")
)

If you are using Claude Code, it is recommended to add the Posit marketplace first. This allows you to browse, install, and update skills easily.

1. Add the Posit marketplace:

claude plugin marketplace add posit-dev/skills

2. Install the r-lib category (which includes mirai and all R package development skills):

claude plugin install r-lib@posit-dev-skills

Alternatively, you can perform a direct install without adding the marketplace:

claude plugin install r-lib@posit-dev-skills

Updating the skill depends on how it was originally installed.

If installed via Claude Code Plugins

You must update the marketplace index before updating the specific plugin:

claude plugin marketplace update
claude plugin update r-lib@posit-dev-skills

If installed via npx skills add

Skills installed this way are copied into your agent's configuration at install time. To update, re-run the original installation command to fetch the latest version:

npx skills add posit-dev/skills --skill mirai

# For Claude Code plugins
claude plugin marketplace update
claude plugin update r-lib@posit-dev-skills

# For npx installations
npx skills add posit-dev/skills --skill mirai

To prevent a high-throughput producer from overwhelming the system, you can cap the queued task payload using the memory argument in daemons().

When the queue reaches the specified limit (in MB), mirai() will block the host thread. To avoid blocking the host thread, use try_mirai(), which returns NULL invisibly if the memory cap is hit.

Note: memory requires the dispatcher (which is the default).

# 100 MB queue cap
daemons(4, memory = 100)

# try_mirai() returns NULL instead of blocking when the cap is hit
m <- try_mirai(work(x), .args = list(x = x))
if (is.null(m)) {
  # backpressure: drop, retry later, or signal upstream
} else {
  # m is a regular mirai
}

# Inspect current and peak queue usage
status()$memory

When performing nested parallel tasks (e.g., calling mirai_map inside a daemon callback), do not use daemons(n) to spawn new workers. This can conflict with the existing outer daemon pool. Instead, use local_url() combined with launch_local() to create a localized, isolated pool for the inner tasks. Always ensure you shut down the local daemons using daemons(0) before the inner task completes to prevent resource leaks.

mirai_map(1:10, \(x) {
  daemons(url = local_url())
  launch_local(2)
  result <- mirai_map(1:5, function(y, x) x * y, .args = list(x = x))[]
  daemons(0)
  result
})[]

Install the mirai package from CRAN to use the minimalist async evaluation framework for R.

install.packages("mirai")

Shiny: ExtendedTask

For Shiny applications, use the ExtendedTask pattern from the bslib package. This allows you to trigger async tasks from UI elements (like buttons) and render results reactively without blocking the Shiny event loop.

Promises

mirai objects can be converted to promises for use with the promises package using the %...>% operator.

# Shiny ExtendedTask pattern
library(shiny)
library(bslib)
library(mirai)

daemons(4)

server <- function(input, output, session) {
  task <- ExtendedTask$new(
    function(n) mirai(rnorm(n), .args = list(n = n))
  ) |> bind_task_button("run")

  observeEvent(input$run, task$invoke(input$n))
  output$result <- renderPlot(hist(task$result()))
}

# Promise piping
library(promises)
mirai({Sys.sleep(1); "done"}) %...>% cat()