Sandbox commands are Bash everywhere
Every sandbox now evaluates command strings as non-login Bash —bash -c, with no sh fallback and no ambient provider shell. Previously the three backends disagreed: Daytona ran commands through sh, and Docker’s streaming, stdio, and setup paths used a login shell. Bash-only syntax such as [[ ... ]] and arrays now behaves identically across local, Docker, and Daytona, through both buffered and streaming execution.
The shell tool’s name, argument names and types, and required fields are unchanged; its descriptions now make explicit that command is Bash source. Fabro still adds no shell options of its own — there is no implicit errexit or pipefail, so false | true still succeeds. A workflow that wants different semantics writes them into the command (sh -c ..., a #!/bin/sh shebang, an explicit set -o pipefail).
Both fresh initialization and resume now verify Bash before reporting the sandbox usable, so a missing or non-Bash interpreter fails at the lifecycle boundary with provider-specific remediation instead of on the first command. Fabro also clears BASH_ENV at each provider boundary so ambient worker or image configuration cannot execute a startup file before sandbox commands. Docker and Daytona require /bin/bash; local sandboxes resolve bash through the worker’s PATH, which keeps NixOS working.
Prepare-step script values and sandbox MCP script values run under the same contract. Hooks, host-side stdio MCP scripts, and interactive terminals are separate executors and keep their existing behavior.
Shared-checkout parallel execution
Parallel branches now run concurrently in the run’s existing sandbox and working directory instead of creating branch-specific Git worktrees. Each branch still receives isolated context updates, returned in outgoing-edge order underparallel.results, while a prompted fan-in can synthesize the complete typed result array. Promptless fan-in nodes act as barriers and never select, restore, or merge workspace state.
Fireworks AI
Fireworks AI is now an opt-in built-in provider with a curated serverless catalog for Kimi, DeepSeek, GLM, MiniMax, Qwen, and GPT-OSS models. The integration uses the existing OpenAI-compatible path, supports cached-input accounting, and works with the normal provider login, secret storage, diagnostics, and model-testing flows.settings.toml
Resumed stages keep their history
When a run resumes after a node was cancelled or lost mid-flight, the replay now starts a new stage execution such aswork@2 instead of clearing and reusing work@1. The earlier execution keeps its events, session, output, timing, billing, and terminal state, and the stage UI links the new execution back to the one it resumed from.
More
API
API
GET /api/v1/runs/{id}/eventsnow supports descending cursor pagination withorder=descandbefore_seq;fabro run events --tailuses it to fetch only the newest events- Completion usage now reports disjoint input, output, reasoning, cache-read, and cache-write token buckets
- Model responses now advertise exact
controls.reasoning_effortvalues, and completion requests—including structured completions—validate and forward reasoning effort with a400response for unsupported values
Fixes
Fixes
- Event history scans now use seek-based pagination with bounded cursors, avoiding full-history work and incorrect results for oversized sequence values
- Preflight now prefers providers that are actually ready while preserving explicit provider pins and useful diagnostics for unavailable offerings
- OpenAI-compatible agent providers now receive compatible file-edit and tool schemas
- Large values inside parallel branch results now stay available to fan-in prompts through normal artifact storage
Improvements
Improvements
- Added
claude-opus-5to the first-party Anthropic and optional OpenRouter model catalogs; theopusandclaude-opusaliases now resolve to Opus 5 - Added
gpt-sol,gpt-terra, andgpt-lunaaliases for GPT-5.6 offerings - Added portable
glm,glm52,glm5.2,deepseek, anddeepseek-flashaliases across direct and OpenRouter offerings