Skip to main content

Python API

The Rollout/Scene API is the primary way to run agent benchmarks programmatically.

Install

Quick Start

Core Types

RolloutConfig

Declarative configuration for a rollout — a sequence of Scenes in a shared sandbox.
Set sandbox_setup_timeout when sandbox user setup needs more than the default 120 seconds. The same field is also available on JobConfig and RuntimeConfig.

Scene

Authoring sugar for role, prompt, and skill attribution. Scenes compile to explicit rollout Steps before execution; there is no runtime Scene object or message scheduler.

Rollout

The execution engine — decomposed into independently-callable phases.

RuntimeConfig

Runtime-level configuration for the Agent + Environment execution path.

bf.run()

Convenience function — multiple calling conventions:

Rollout Lifecycle

Key: scene boundaries are gone by execution time; role changes are represented as Step metadata and handled by the rollout executor.

Multi-Turn vs Multi-Round

Multi-turn = same agent gets multiple prompts. Use when a second pass catches errors (self-review, iterative refinement). The agent keeps its context across turns. Multi-role = different agents receive explicit turns. Use when tasks need multiple perspectives (code review, client-advisor). Any handoff text must be part of the declared prompt or agent-native communication, not a BenchFlow Scene scheduler. Both use the same API — RolloutConfig with different Scene configurations.

Multi-Agent Patterns

Coder + Reviewer (followup-bench)

Skill Generation + Solve (BYOS)

User-Driven Loops

Use BaseUser or FunctionUser when one agent should run multiple rounds and Python should decide the next prompt from verifier feedback. This is the progressive-disclosure path: the user callback can stop early, read RoundResult after each soft_verify(), and optionally receive the oracle solution during setup() when oracle_access=True.
Use multi-role Scenes when another LLM should act as the reviewer or simulated user. Use BaseUser when the loop is deterministic or verifier-driven. See progressive-disclosure.md and docs/examples/scene-patterns.ipynb.

YAML Rollout Configs

Registered Agents

The Auth column shows each agent’s native/default credentials. Provider-prefixed models can use provider-specific credentials instead; for example, Azure Foundry models use AZURE_API_KEY plus AZURE_API_ENDPOINT with prefixes such as azure-foundry-openai/gpt-5.5 or azure-foundry-anthropic/claude-opus-4-5. BenchFlow routes these providers through LiteLLM on both Docker and Daytona. Any agent can be prefixed with acpx/ to run via ACPX (e.g. acpx/gemini, acpx/claude). ACPX is a headless ACP client with persistent sessions and crash recovery. The underlying agent’s install, env, credentials, and skill paths are preserved.

Retry and Error Handling

Rollout.run() catches common errors:
  • TimeoutError — agent exceeded timeout
  • ConnectionError — SSH/ACP pipe closed (retried 3x with exponential backoff)
  • ACPError — agent protocol error
Evaluation-level retry with RetryConfig:

Sandbox and Reward Types

Sandbox Protocol

The Sandbox protocol defines the interface any sandbox backend must implement. Docker and Daytona are built-in; you can bring your own (Modal, Firecracker, E2B, etc.).

Rubric + RewardFunc (Composable Rewards)

Declarative scoring via composable reward functions.

Adapters (Inspect AI + ORS)

Convert between BenchFlow types and external frameworks.

Evaluation

Batch orchestration with concurrency and retries.