Rewrite changelog entries with improved style and structure

Each major feature gets its own H2 heading with narrative depth
and code examples instead of dense bullet lists under category
headers. Minor improvements and fixes go at the bottom as a flat
list. Style inspired by Qlty, Linear, Vercel, and Resend changelogs.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Bryan Helmkamp 2026-03-05 03:13:42 -05:00
parent 45a7762a17
commit e7d64136b3
11 changed files with 339 additions and 141 deletions

View file

@ -3,18 +3,35 @@ title: "First CLI, Docker sandboxing, and web dashboard"
date: "2026-02-23"
---
Arc's first usable release — run AI workflows from the command line, execute them in Docker sandboxes, and monitor progress through a web dashboard.
## Arc CLI
## Features
Run AI workflows from the command line with `arc run start`, validate DOT workflow definitions with `arc validate`, and step through dry-runs to test logic before committing real LLM calls.
- **Arc CLI**: Run workflows with `arc run start`, validate DOT definitions with `arc validate`, and step through dry-runs to test workflow logic before committing real LLM calls
- **Docker sandboxing**: Isolate agent tool execution inside Docker containers with `--docker`, so workflows can safely run shell commands, edit files, and install dependencies without affecting your host machine
- **Web dashboard**: Monitor workflow runs in real time with a pipeline kanban board showing status, progress, and human-in-the-loop prompts
- **Interactive tool approval**: Approve or reject each tool call during a run via arrow-key prompts in the terminal, giving you fine-grained control over what the agent does
- **Streaming output**: Watch LLM responses stream in real time instead of waiting for the full response, with `--output-format json` for NDJSON event streaming
```bash
arc run start spec-dod-multimodel.dot
arc validate my-workflow.dot
arc run start --dry-run my-workflow.dot
```
## Improvements
The CLI streams LLM responses in real time and supports interactive tool approval — each tool call pauses for you to approve or reject via arrow-key prompts, giving fine-grained control over what the agent does.
- **Claude Opus 4.6 default**: Ships with Claude Opus 4.6 (1M context window) as the default Anthropic model, and Gemini 3.1 Pro Preview as the default Gemini model
- **Extended thinking**: Anthropic models now use adaptive thinking by default for deeper reasoning on complex tasks
- **Prettier CLI output**: Color-coded terminal output with ANSI styling makes it easier to follow what the agent is doing
## Docker sandboxing
Agent tool execution can now run inside Docker containers, so workflows can safely run shell commands, edit files, and install dependencies without affecting your host machine.
```bash
arc run start --docker my-workflow.dot
```
The container is shared across all stages in a run, so tools have access to the same filesystem throughout the workflow.
## Web dashboard
A pipeline kanban board shows all active runs with their status, progress, and any pending human-in-the-loop prompts. Watch workflows execute in real time from the browser.
---
- Ships with Claude Opus 4.6 (1M context window) as the default Anthropic model and Gemini 3.1 Pro Preview as the default Gemini model
- Anthropic models use adaptive thinking by default for deeper reasoning on complex tasks
- Color-coded terminal output with ANSI styling makes it easier to follow agent activity
- Use `--output-format json` for NDJSON event streaming into CI/CD pipelines or custom dashboards

View file

@ -3,14 +3,22 @@ title: "Auto-compaction and run progress logs"
date: "2026-02-24"
---
Long-running agent sessions no longer fail when they hit the context window limit, and every run now produces a detailed progress log.
## Auto-compaction
## Features
Long-running agent sessions used to fail when they hit the context window limit. Now, sessions automatically summarize earlier conversation history when approaching the limit, so long workflows keep running without manual intervention.
- **Auto-compaction**: Agent sessions automatically summarize earlier conversation history when approaching the context window limit, so long workflows can keep running without manual intervention
- **Progress logs**: Every run now writes `progress.ndjson` and `live.json` to the logs directory, giving you a structured record of every LLM call, tool execution, and routing decision for post-run analysis
- **Model sync**: Run `arc models sync` to download the latest model metadata from OpenRouter, keeping your catalog current as new models launch
The compaction preserves the most relevant context — recent tool calls, file changes, and key decisions — while condensing older turns into a structured summary.
## Improvements
## Progress logs
- **Token and cost tracking**: Each run now tracks cumulative input/output tokens and estimated cost, displayed at completion
Every run now writes `progress.ndjson` and `live.json` to the logs directory, giving you a structured record of every LLM call, tool execution, and routing decision. Use these for post-run analysis, debugging, or building custom dashboards.
```bash
# Watch events stream in real time
tail -f ~/.arc/logs/<run-id>/progress.ndjson
```
---
- Each run now tracks cumulative input/output tokens and estimated cost, displayed at completion
- Run `arc models sync` to download the latest model metadata from OpenRouter

View file

@ -3,15 +3,26 @@ title: "Skills system and secret redaction"
date: "2026-02-25"
---
Reusable prompt templates and automatic secret detection keep workflows organized and logs safe to share.
## Skills
## Features
Skills are reusable prompt templates that any workflow can invoke on demand. Define them as `skills/<name>/SKILL.md` files and activate them during runs with the `use_skill` tool.
- **Skills**: Define reusable prompt templates as `skills/<name>/SKILL.md` files and activate them during runs with the `use_skill` tool — build a library of domain-specific capabilities that any workflow can invoke
- **Secret redaction**: API keys, tokens, and other secrets detected in NDJSON logs, `live.json`, and SSE events are automatically redacted before being written, so progress logs are safe to share and store
- **Claude Haiku 4.5**: Added to the model catalog for fast, cost-effective tasks within workflows
```
skills/
code-review/
SKILL.md
security-audit/
SKILL.md
```
## Improvements
This lets you build a library of domain-specific capabilities — a code review checklist, a security audit procedure, a migration playbook — and compose them into different workflows without duplicating prompts.
- **Per-node visit limits**: Nodes now track visit counts and stop after a configurable maximum, preventing infinite loops in dry-run mode
- **One-shot LLM nodes**: Set `codergen_mode = "one_shot"` to use a single LLM call instead of an agent loop, useful for classification and summarization nodes that don't need tools
## Secret redaction
API keys, tokens, and other secrets detected in NDJSON logs, `live.json`, and SSE events are now automatically redacted before being written. Previously, progress logs could contain sensitive values if the agent encountered them during tool execution. Now they're safe to share, store, and ship to external observability systems.
---
- Added Claude Haiku 4.5 to the model catalog for fast, cost-effective tasks within workflows
- Nodes now track visit counts and stop after a configurable maximum, preventing infinite loops in dry-run mode
- Set `codergen_mode = "one_shot"` to use a single LLM call instead of an agent loop, useful for classification and summarization nodes

View file

@ -3,10 +3,26 @@ title: "Daytona cloud sandboxes and TOML run config"
date: "2026-02-26"
---
Run workflows in Daytona cloud sandboxes and configure runs with TOML files instead of CLI flags.
## Daytona cloud sandboxes
## Features
Workflows can now execute in Daytona cloud environments — full dev containers with SSH access, persistent storage, and network isolation. Previously, Docker was the only sandbox option, which meant running everything locally. Daytona moves execution to the cloud, freeing up your machine and providing a more production-like environment.
- **Daytona cloud sandboxes**: Use `--execution-env daytona` to run agent tool execution in Daytona cloud environments — full dev containers with SSH access, persistent storage, and network isolation
- **TOML run configuration**: Define run settings in a TOML file with `[execution]` for sandbox config and `[vars]` for DOT source parameterization, replacing long CLI flag chains with version-controlled config files
- **Variable expansion**: Use `$variable` placeholders in DOT workflow sources and supply values through TOML config, making workflows reusable across different projects and environments
```bash
arc run start --execution-env daytona my-workflow.dot
```
## TOML run configuration
Long chains of CLI flags are hard to remember and impossible to version-control. Run settings now live in a TOML file with `[execution]` for sandbox config and `[vars]` for DOT source parameterization.
```toml
[execution]
environment = "daytona"
[vars]
repo = "https://github.com/example/project"
branch = "main"
language = "typescript"
```
Use `$variable` placeholders in DOT workflow sources and supply values through the TOML config, making workflows reusable across different projects and environments.

View file

@ -3,18 +3,30 @@ title: "MCP tool servers, web tools, and multi-CLI backends"
date: "2026-02-27"
---
Agents can now connect to external MCP tool servers, search the web, fetch URLs, and delegate work to Claude Code, Codex, or Gemini CLIs.
## MCP support
## Features
Agents can now connect to external tool servers using the Model Context Protocol. Any MCP-compatible server can provide tools to your workflows without custom integration — databases, APIs, internal services, anything with an MCP server.
- **MCP support**: Connect agents to external tool servers using the Model Context Protocol — any MCP-compatible server can provide tools to your workflows without custom integration
- **Web search**: Agents can search the web using the Brave Search API via the built-in `web_search` tool, bringing real-time information into workflow decisions
- **Web fetch**: Agents can fetch and read web pages with `web_fetch`, which converts HTML to Markdown and summarizes long content to fit within context limits
- **CLI backends**: Delegate agent work to Claude Code, Codex, or Gemini CLIs with the `cli_backend` option — each node in a workflow can use a different AI coding assistant
- **Subagent tools**: Agents can spawn sub-agents to handle focused tasks in parallel, each with their own tool set and conversation context
- **Structured compaction**: Context compaction now tracks which files were modified and preserves file-level state, so agents maintain accurate project understanding across compaction boundaries
## Web search and web fetch
## Improvements
Two new built-in tools bring real-time information into workflow decisions. `web_search` queries the Brave Search API, and `web_fetch` retrieves web pages, converting HTML to Markdown and summarizing long content to fit within context limits.
- **NDJSON streaming**: Use `--output-format json` for machine-readable event streaming, useful for integrating Arc into CI/CD pipelines or custom dashboards
- **Artifact sync**: Files created in remote sandboxes are automatically synced back to the host, so workflow outputs are always available locally
## CLI backends
Individual workflow nodes can now delegate work to external AI coding assistants. Set the backend to `claude-code`, `codex`, or `gemini-cli` and the node will use that CLI tool instead of the built-in agent loop.
```dot
implement [handler=codergen, cli_backend=codex]
review [handler=codergen, cli_backend=claude-code]
```
This means each stage in a workflow can use a different AI tool — use Codex for implementation and Claude Code for review, for example.
## Subagent tools
Agents can spawn sub-agents to handle focused tasks in parallel, each with their own tool set and conversation context. The parent agent delegates work and receives results without its own context window growing.
---
- Context compaction now tracks which files were modified and preserves file-level state across compaction boundaries
- Files created in remote sandboxes are automatically synced back to the host

View file

@ -1,21 +1,27 @@
---
title: "Arc web app, new providers, and git checkpointing"
title: "Arc web app, new LLM providers, and git checkpointing"
date: "2026-02-28"
---
A full-featured web app for managing workflows, three new LLM providers, and automatic git checkpoints at every workflow node.
## Arc web app
## Features
A full React-based dashboard for managing workflows. Browse workflow definitions with syntax-highlighted DOT and TOML, view run details with side-by-side diffs showing what each run changed, and inspect agent sessions turn-by-turn.
- **Arc web app**: A complete React-based dashboard for browsing workflows, viewing run details with syntax-highlighted diffs, inspecting agent sessions turn-by-turn, and monitoring run status in real time
- **Workflow visualization**: Interactive SVG diagrams of your workflow graph with zoom, pan, direction toggle, and fit-to-window controls — see exactly where a run is at a glance
- **Diff viewer**: Side-by-side and unified diff views with syntax highlighting show exactly what each workflow run changed, with split/unified and background toggles
- **Git checkpointing**: Arc automatically creates git commits at each workflow node, so you can see the exact state of the codebase at any point in a run and compare changes between stages
- **Kimi, Z.AI, and Minimax providers**: Three new LLM providers expand your options for model selection in workflow stylesheets
- **JWT authentication**: Secure service-to-service auth between arc-web and the API server using asymmetric JWT tokens with GitHub identity
The workflow detail page renders an interactive SVG diagram of the workflow graph with zoom, pan, direction toggle, and fit-to-window controls — see exactly where a run is in the graph at a glance.
## Improvements
## Git checkpointing
- **DOT parser**: Supports unquoted bare string values (e.g., `model = gpt-5.2`) for cleaner workflow definitions
- **ULID run IDs**: Runs now use time-sortable ULIDs instead of UUIDs, making it easier to find recent runs in logs and the API
- **Run labels**: Tag runs with custom labels and filter them with `arc run list`
Arc now automatically creates git commits at each workflow node, so you can see the exact state of the codebase at any point in a run. The run detail page includes a checkpoint picker that lets you compare file changes between any two stages.
Previously, you could only see the final output of a run. Now you can trace exactly what changed at each step and when.
## Kimi, Z.AI, and Minimax providers
Three new LLM providers expand model selection in workflow stylesheets. Configure API keys in your `.env` file and reference their models in DOT `model` attributes.
---
- DOT parser now supports unquoted bare string values (e.g., `model = gpt-5.2`) for cleaner workflow definitions
- Runs use time-sortable ULIDs instead of UUIDs, making it easier to find recent runs in logs and the API
- Tag runs with custom labels and filter them with `arc run list`
- Asymmetric JWT authentication between arc-web and the API server, with GitHub identity in the token

View file

@ -3,27 +3,48 @@ title: "Verifications, retrospectives, insights, and parallel branching"
date: "2026-03-01"
---
Automatically verify run outputs, generate LLM-powered retrospectives, query run data with SQL, and run workflow branches in parallel git worktrees.
## Verifications
## Features
Define verification checks that automatically validate run outputs. Browse the verification catalog to see all available checks, and review per-run results to catch regressions before merging.
- **Verifications**: Define verification checks that automatically validate run outputs — browse the verification catalog and see per-run results to catch regressions before merging
- **Retrospectives**: After each run, an LLM-powered retro agent analyzes what happened and generates a structured summary with timing, cost, and improvement suggestions
- **Insights SQL workbench**: Write and save SQL queries against your run data to answer questions like "which workflows fail most?" or "what's the average cost per stage?" — with a query editor, template library, and execution history
- **Parallel git branching**: Workflow branches now execute in isolated git worktrees, so parallel stages can edit files simultaneously without conflicts and merge cleanly at fan-in nodes
- **SQLite persistence**: Run data, sessions, and verifications are stored in a local SQLite database for fast querying and reliable persistence
- **Interactive SVG graphs**: Run graphs render as interactive SVGs with animated nodes showing which stage is currently executing
- **Light mode**: Full light mode support with a theme toggle in the web app
Verifications run after each workflow completes and report pass/fail status, so you get a quality gate between "the agent finished" and "the code is ready."
## Improvements
## Retrospectives
- **Failure signatures and circuit breakers**: Deterministic failure cycles (like the same syntax error on every retry) are detected and short-circuited, saving tokens and time on runs that would never succeed
- **Stall watchdog**: Hung pipeline handlers are detected and reported instead of silently blocking the run
- **Structured tracing**: File-based tracing across all crates controlled by `ARC_LOG`, providing detailed diagnostics without cluttering normal output
- **Retro output in CLI**: Retrospective summaries now print inline after the run completes, rendered as Markdown in the terminal
After each run, an LLM-powered retro agent analyzes what happened and generates a structured summary — what worked, what didn't, timing breakdown, cost, and improvement suggestions. The retro prints inline in your terminal after the run completes, rendered as Markdown.
## Fixes
```bash
arc run start my-workflow.dot
# ... run executes ...
# === Retro ===
# The run completed in 4m 32s across 6 stages...
```
- Fixes an issue where non-transient infrastructure failures (like invalid API keys) would trigger retries instead of failing immediately
- Fixes cross-browser SVG animation for the running graph node indicator
Previously, understanding what happened in a run meant reading through raw logs. Now you get a concise post-mortem automatically.
## Insights SQL workbench
Query your run data directly with SQL to answer questions like "which workflows fail most?" or "what's the average cost per stage?" The web app includes a query editor, template library, and execution history.
## Parallel git branching
Workflow branches now execute in isolated git worktrees, so parallel stages can edit files simultaneously without conflicts. At fan-in nodes, changes merge cleanly back together.
Previously, parallel stages sharing a single worktree would overwrite each other's changes. Worktree isolation makes parallel execution reliable.
## SQLite persistence
Run data, sessions, and verifications are stored in a local SQLite database. This replaces the previous file-only approach, enabling fast querying and the new Insights feature.
## Light mode
Full light mode support with a theme toggle in the web app.
---
- Interactive SVG graph rendering with animated nodes showing which stage is currently executing
- Failure signatures and circuit breakers detect deterministic failure cycles (like the same syntax error on every retry) and short-circuit them, saving tokens and time
- Stall watchdog detects hung pipeline handlers and reports them instead of silently blocking
- File-based structured tracing across all crates controlled by `ARC_LOG`
- Fixes non-transient infrastructure failures (like invalid API keys) triggering retries instead of failing immediately
- Fixes UTF-8 string slicing panics when truncating multi-byte characters in progress output

View file

@ -3,30 +3,45 @@ title: "Workflows and runs, devcontainer support, and sessions"
date: "2026-03-02"
---
Clearer terminology, devcontainer-based sandboxes, persistent chat sessions, and GitHub OAuth login.
<Warning>
## Breaking changes
**"Pipeline" renamed to "Workflow" and "Run" across the entire system.** API endpoints, CLI commands, config files, and the web UI now use `workflow` and `run` instead of `pipeline`. The OpenAPI spec, generated TypeScript client, and all CLI help text have been updated.
**"Pipeline" renamed to "Workflow" and "Run" across the entire system.** API endpoints, CLI commands, config files, and the web UI now use `workflow` and `run` instead of `pipeline`.
To migrate:
1. Replace `pipeline` with `workflow` in DOT files and TOML configs
2. Update any API integrations to use the new endpoint paths (e.g., `/runs` instead of `/pipelines`)
2. Update API integrations to use new endpoint paths (e.g., `/runs` instead of `/pipelines`)
3. Regenerate API clients with `bun run generate`
</Warning>
## Features
## Devcontainer support
- **Devcontainer support**: Use standard `devcontainer.json` files to define sandbox environments — Arc parses and resolves devcontainer configs including features, lifecycle hooks, build args, and container environment variables
- **Sessions**: Persistent chat sessions with SQLite storage — start a conversation, come back to it later, and pick up where you left off
- **GitHub OAuth login**: Authenticate to the Arc web app using your GitHub account, with automatic session management and user identity
- **Preview endpoint**: Generate a live preview URL for any running sandbox with `POST /runs/{id}/preview`, accessible from a button in the run detail page
- **LLM chat**: Interactive multi-turn conversations with any configured model via `arc llm chat`, useful for quick experiments and prompt testing
- **Mintlify docs site**: Full documentation site with getting started guides, core concepts, workflow reference, and API docs
Sandbox environments can now be defined using standard `devcontainer.json` files. Arc parses and resolves the full devcontainer spec — features, lifecycle hooks (`onCreateCommand`, `postStartCommand`), build args, `containerEnv`, feature dependencies, and Compose-based configurations.
## Improvements
If your project already has a `.devcontainer/devcontainer.json`, Arc can use it directly instead of requiring a separate sandbox configuration.
- **Asset snapshots**: Generic asset collection for workflow node outputs — any files produced by a node are captured and available for review
- **Error pages**: Styled 404 and 500 error pages matching the Arc design system instead of raw error text
- **Debug flag**: Use `--debug` to switch log level from INFO to DEBUG for troubleshooting
## Sessions
Persistent chat sessions with SQLite storage. Start a conversation with an agent, close the terminal, and pick up where you left off. Sessions track messages, model, and conversation state.
## GitHub OAuth login
Authenticate to the Arc web app using your GitHub account. Session management is automatic, and user identity flows through to API authorization via JWT claims.
## LLM chat
Interactive multi-turn conversations with any configured model via the CLI. Useful for quick experiments and prompt testing outside of a workflow.
```bash
arc llm chat
arc llm chat --model gemini-3.1-pro
```
## Mintlify docs site
Full documentation site with getting started guides, core concepts, workflow reference, API docs, and this changelog.
---
- `POST /runs/{id}/preview` generates a live preview URL for any running sandbox, accessible from a button in the run detail page
- Asset snapshots capture files produced by workflow nodes for review
- Styled 404 and 500 error pages matching the Arc design system
- `--debug` flag switches log level from INFO to DEBUG for troubleshooting

View file

@ -3,25 +3,55 @@ title: "mTLS auth, setup wizard, and arc doctor"
date: "2026-03-03"
---
Stronger authentication, guided setup, and a diagnostic command that checks your entire Arc installation.
## mTLS authentication
## Features
The API server now supports mutual TLS — both client and server present certificates, providing strong identity verification for production deployments. This is the recommended auth method for environments where network-level trust isn't sufficient.
- **mTLS authentication**: Secure the API server with mutual TLS — both client and server present certificates, providing strong identity verification for production deployments
- **Setup wizard**: Run `arc setup` for an interactive walkthrough that configures your API keys, server settings, and authentication — no more manually editing config files
- **Arc doctor**: Run `arc doctor` to check your entire installation: system dependencies, cryptographic key validation, LLM provider connectivity, and web server configuration — with `--live` for real-time API probes
- **Tailscale authentication**: Authenticate API requests using Tailscale identity for zero-config auth on Tailscale networks
- **TOML configuration**: All configuration moves to `~/.arc/arc.toml` — API keys, auth settings, GitHub App config, and server options in one version-controllable file
- **Run defaults**: Define default run settings in `server.toml` that all workflow runs inherit, so you don't have to specify the same sandbox, model, or concurrency settings every time
## Setup wizard
## Improvements
Previously, getting Arc running meant manually editing config files and setting environment variables. Now run `arc setup` for an interactive walkthrough that configures API keys, server settings, and authentication.
- **Progress UI**: A new indicatif-based progress display for `arc run start` shows real-time stage progress, tool calls, model names, and timing without the noise of raw event logs
- **Model catalog**: Mercury provider updated to `mercury-2`, Claude Haiku alias updated, and estimated output speed (tok/s) added to `arc models list`
- **Colored CLI output**: Consistent semantic color scheme across all CLI commands using the `console` crate, with `dialoguer` for interactive prompts
- **Base64 PEM keys**: `ARC_JWT_PUBLIC_KEY` and `ARC_JWT_PRIVATE_KEY` accept base64-encoded PEM strings for easier deployment in containerized environments
```bash
arc setup
```
## Fixes
The wizard detects your current configuration, prompts for missing values, and writes everything to `~/.arc/arc.toml`.
- Fixes an issue where the JWT `sub` claim used the GitHub API URL instead of the profile URL, causing identity mismatches
- Fixes stale configuration persisting after running `arc setup` until a manual restart
## Arc doctor
A single command to check your entire installation: system dependencies, cryptographic key validation, LLM provider connectivity, and web server configuration.
```bash
arc doctor # quick local checks
arc doctor --live # includes real-time API probes to each configured provider
```
If something is misconfigured, `arc doctor` tells you exactly what's wrong and how to fix it.
## Tailscale authentication
For teams on a Tailscale network, API requests can authenticate using Tailscale identity — no tokens, no certificates, just the identity your machine already has.
## TOML configuration
All configuration moves to `~/.arc/arc.toml` — API keys, auth settings, GitHub App config, and server options in one file. Environment variables still work but the TOML file is the recommended approach.
```toml
[auth]
provider = "github"
[providers.anthropic]
api_key = "sk-ant-..."
[web]
url = "http://localhost:5173"
```
---
- New indicatif-based progress display for `arc run start` shows real-time stage progress, tool calls, model names, and timing
- Mercury provider updated to `mercury-2`; estimated output speed (tok/s) added to `arc models list`
- Run defaults in `server.toml` are inherited by all workflow runs, so you don't have to repeat sandbox, model, or concurrency settings
- `ARC_JWT_PUBLIC_KEY` and `ARC_JWT_PRIVATE_KEY` accept base64-encoded PEM strings for containerized deployments
- Fixes JWT `sub` claim using the GitHub API URL instead of the profile URL, causing identity mismatches
- Fixes stale configuration persisting after `arc setup` until a manual restart

View file

@ -3,27 +3,47 @@ title: "Pagination, concurrency limits, usage tracking, and SSH access"
date: "2026-03-04"
---
All list endpoints now support pagination, runs queue when capacity is full, and you can SSH into running sandboxes for live debugging.
## Pagination
## Features
All list API endpoints now support offset-based pagination with `offset` and `limit` parameters. Previously, endpoints returned all results at once, which became slow as run history grew.
- **Pagination**: All list API endpoints now support offset-based pagination with `offset` and `limit` parameters, so large result sets load efficiently
- **Concurrency limiter**: Set `max_concurrent_runs` in server config to control how many runs execute simultaneously — additional runs queue automatically with `queued` and `starting` states visible in the UI
- **Usage API**: `GET /usage` returns aggregate token counts and estimated costs across all runs, broken down by model — useful for budgeting and monitoring spend
- **Timer nodes**: Add `wait.timer` nodes to workflows that pause for a configured duration, useful for rate limiting or waiting for external processes
- **SSH access**: Use `--ssh` with `arc run start` to get SSH access into running Daytona sandboxes for live debugging while the workflow executes
- **Hot config reload**: Changes to `server.toml` are automatically detected and applied without restarting the server, including model defaults from the catalog
- **Gemini 3.1 Flash Lite**: Added to the model catalog for ultra-fast, low-cost tasks
- **Preserve sandbox**: Use `--preserve-sandbox` to keep sandboxes alive after a run completes, so you can inspect the final state
```bash
curl "http://localhost:3000/runs?offset=0&limit=20"
```
## Improvements
## Concurrency limiter
- **Ensemble demo**: New multi-provider ensemble workflow demonstrating how to fan out the same task across different models and merge results
- **CLI polish**: Parallel branches show in progress UI, sandbox details with hyperlinks display during runs, and retro summaries render as Markdown in the terminal
- **Uniform error format**: All API error responses now use a consistent JSON structure with error codes and messages
Set `max_concurrent_runs` in server config to control how many runs execute simultaneously. Additional runs queue automatically with `queued` and `starting` states visible in the UI and API.
## Fixes
Previously, starting too many runs at once could overwhelm the machine. Now excess runs wait in a queue and start as capacity frees up.
- Fixes an issue where HTTP 529 (Overloaded) responses from LLM providers were misclassified as non-retryable, causing runs to fail instead of retrying
- Fixes an issue where the `--config` flag was ignored when starting the server
- Fixes a panic when displaying progress for tool calls containing long whitespace sequences
## Usage API
`GET /usage` returns aggregate token counts and estimated costs across all runs, broken down by model. Use it for budgeting, monitoring spend, or building cost dashboards.
## SSH access to running sandboxes
Use `--ssh` to get SSH access into running Daytona sandboxes for live debugging while the workflow executes. When something goes wrong mid-run, you can drop into the sandbox, inspect the filesystem, and understand the problem without waiting for the run to finish.
```bash
arc run start --ssh my-workflow.dot
```
Use `--preserve-sandbox` to keep sandboxes alive after a run completes for post-mortem inspection.
## Hot config reload
Changes to `server.toml` are automatically detected and applied without restarting the server. Model defaults from the catalog are also refreshed. No more restart-to-reconfigure cycles during development.
## Timer nodes
Add `wait.timer` nodes to workflows that pause for a configured duration. Useful for rate limiting between API calls or waiting for external processes to complete.
---
- Gemini 3.1 Flash Lite added to the model catalog for ultra-fast, low-cost tasks
- Multi-provider ensemble demo workflow showing fan-out across models and result merging
- Parallel branches show in progress UI; sandbox details with hyperlinks display during runs
- All API error responses now use a consistent JSON structure with error codes and messages
- Fixes HTTP 529 (Overloaded) responses from LLM providers being misclassified as non-retryable
- Fixes progress display panic when tool calls contain long whitespace sequences

View file

@ -3,25 +3,67 @@ title: "Lifecycle hooks, model failover, and Docker Compose demo"
date: "2026-03-05"
---
Control workflow execution with lifecycle hooks that can call HTTP endpoints or ask an LLM, automatically fail over to backup models, and get started faster with Docker Compose.
## Features
- **Lifecycle hooks**: Attach hooks to workflow events that execute before or after stages — use them to notify external systems, enforce policies, or gate execution on custom conditions
- **HTTP hooks**: Call external HTTP endpoints from hooks with environment variable interpolation in request bodies and configurable TLS modes for different environments
- **Prompt and agent hooks**: Define hook conditions in natural language — the hook evaluates whether to proceed by asking an LLM, so workflows can adapt to nuanced situations like "skip this stage if the code change is cosmetic"
- **Model failover**: Configure fallback models at the provider level, so if your primary model is unavailable or rate-limited, runs automatically switch to a backup without failing
- **Docker Compose demo**: Run `docker compose up` to start a complete Arc demo environment locally — API server, web app, and sample workflows ready to explore
- **CLI config file**: Persistent CLI defaults in `~/.arc/cli.toml` — set your preferred output format, default workflow, or any other CLI option once instead of passing flags every time
## Improvements
- **Variable validation**: Unknown `$variable` placeholders in DOT prompts now produce clear error messages instead of being silently passed through, catching typos before the run starts
<Warning>
## Breaking changes
**`GET /runs/{id}/files` renamed to `GET /runs/{id}/compare`.** The endpoint returns the same data but the path now reflects its purpose of comparing file changes between checkpoints.
To migrate: Update any API integrations using the old `/files` path to use `/compare`.
To migrate: Update API integrations using `/files` to use `/compare`.
</Warning>
## Lifecycle hooks
Workflows can now trigger actions at key moments — before a stage starts, after it completes, or when a run fails. Use hooks to notify external systems, enforce policies, or gate execution on custom conditions.
## HTTP hooks
Hook executors can call external HTTP endpoints with full environment variable interpolation in request bodies. TLS mode is configurable per-hook, supporting strict validation for production and permissive mode for development.
```toml
[[hooks]]
event = "stage.before"
executor = "http"
url = "https://api.example.com/webhook"
tls_mode = "strict"
```
## Prompt and agent hooks
Define hook conditions in natural language instead of rigid pattern matching. The hook evaluates whether to proceed by asking an LLM, so workflows can adapt to nuanced situations like "skip this stage if the code change is cosmetic."
```toml
[[hooks]]
event = "stage.before"
executor = "prompt"
prompt = "Should this stage run given the changes so far?"
```
## Model failover
If your primary model is unavailable or rate-limited, runs now automatically switch to a backup. Configure fallback models at the provider level in your server config:
```toml
[providers.anthropic]
failover = ["openai", "gemini"]
```
Previously, a provider outage would fail the entire run. Now it retries with the next provider in the list.
## Docker Compose demo
Get a complete Arc demo environment running locally with a single command — API server, web app, and docs site, all pre-configured.
```bash
docker compose -f docker-compose.demo.yaml up
```
## CLI config file
Persistent CLI defaults in `~/.arc/cli.toml`. Set your preferred output format, default workflow, or any other CLI option once instead of passing flags every time.
```toml
output_format = "json"
verbose = true
```
---
- Unknown `$variable` placeholders in DOT prompts now produce clear error messages instead of being silently passed through