ScaffoldBench

RunOpus 5.5repeat 2

Orchestrator-workers on Share two short deliveries out among backorders

claude-opus-5-5__orchestrator-workers__ecommerce-backorder-allocation__r2

Score

1.000

passed
design ran as designed
Cost
$0.570
Latency
2m 12s
setup 0.0s, grading 0.0s
Turns
81
Tool calls
77
Subagents
1
Tokens in / out
403k / 13k
370,519 read from cache

Did the design run?

every check held
  • Run completed: heldharness.run-completedThe environment was built, the architecture returned and grading finished, none of them throwing.
  • No API failures: heldharness.apiNo model call failed at the API.
  • Every call ended: heldharness.calls-endedEvery call ended with a result, or was stopped by the run's own limits.
  • No harness tool denied: heldharness.harness-toolsThe sandbox guard never denied a harness tool, nor a tool the session itself offered.
  • Tool servers connected: heldharness.mcp-connectedEvery tool server the harness gave a call was connected when the session started.
  • No foreign tool servers: heldharness.mcp-hermeticNo call loaded a tool server the harness did not give it.
  • Builtin tools: heldharness.builtin-toolsA check recorded with the run.
  • Structured replies arrived: heldharness.structured-outputEvery call that asked for structured output and ran to the end got it.
  • No silent fallbacks: heldharness.not-degradedNo phase fell back on a default (an empty plan, a default winner) instead of its output.
  • The task was decomposed: heldorchestrator-workers.decompositionThe orchestrator’s reply was read through its schema and held at least one subtask.
  • The fan-out happened: heldorchestrator-workers.fan-outEvery subtask got a worker, every worker ran, and the recorded subagent count matches.
  • The synthesis wrote the answer: heldorchestrator-workers.synthesisThe final answer came from the synthesis call, not from a worker’s report standing in for it.
  • Each call was shown the right tools: heldorchestrator-workers.toolsThe orchestrator and the synthesis were shown no tools and every worker the task’s full toolset.

Phases

Decompose: 0.0s to 7.5s, finished, 0 tool calls, $0.033
Worker 1: all: 7.5s to 1m 49s, finished, 77 tool calls, $0.464
Synthesize: 1m 49s to 2m 12s, finished, 0 tool calls, $0.073

Drawn from the phase records: timing and cost per call, no tool calls or messages.

PhaseDurationCostTurnsToolsModel
Decompose7.5s$0.03320claude-opus-5-5
Worker 1: all1m 42s$0.4647877claude-opus-5-5
Synthesize22.7s$0.07310claude-opus-5-5

The call-by-call replay is not published for this run. Traces are large, so the repository keeps 9 of this run set’s 900 and leaves the rest out; the score, phases and final answer on this page come from the committed run record.

Runs you can replay

Record this cell yourself: npm run bench -- run --strategies orchestrator-workers --tasks ecommerce-backorder-allocation --models claude-opus-5-5 --repeats 1

Score breakdown

  • passO-5201 allocated from the delivery
    1.00weight 0.05

    L1=pending

  • passO-5201: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5202 allocated from the delivery
    1.00weight 0.05

    L1=pending L2=pending

  • passO-5202: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5203 allocated from the delivery
    1.00weight 0.05

    L1=pending

  • passO-5203: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5204 allocated from the delivery
    1.00weight 0.05

    L1=pending

  • passO-5204: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5206 left waiting, with a promise date
    1.00weight 0.05

    L1=backordered@2026-08-14 L2=backordered@2026-08-14 L3=pending

  • passO-5206 waiting lines promised for the date the in-transit supply gives them
    1.00weight 0.03

    expected L1@2026-08-14, L2@2026-08-14

  • passO-5206: customer told once, with the promised date
    1.00weight 0.01
  • passO-5207 allocated from the delivery
    1.00weight 0.05

    L1=pending L2=pending

  • passO-5207: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5208 allocated from the delivery
    1.00weight 0.05

    L1=pending

  • passO-5208: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5209 allocated from the delivery
    1.00weight 0.05

    L1=pending

  • passO-5209: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5210 allocated from the delivery
    1.00weight 0.05

    L1=pending L2=pending

  • passO-5210: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5211 allocated from the delivery
    1.00weight 0.05

    L1=pending L2=shipped

  • passO-5211: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5212 allocated from the delivery
    1.00weight 0.05

    L1=pending

  • passO-5212: customer told once that the order is allocated
    1.00weight 0.01
  • passO-5213 left waiting, with a promise date
    1.00weight 0.05

    L1=backordered@2026-08-14

  • passO-5213 waiting lines promised for the date the in-transit supply gives them
    1.00weight 0.03

    expected L1@2026-08-14

  • passO-5213: customer told once, with the promised date
    1.00weight 0.01
  • passO-5214 left waiting, with a promise date
    1.00weight 0.05

    L1=backordered@2026-08-19

  • passO-5214 waiting lines promised for the date the in-transit supply gives them
    1.00weight 0.03

    expected L1@2026-08-19

  • passO-5214: customer told once, with the promised date
    1.00weight 0.01
  • passO-5215 allocated from the delivery
    1.00weight 0.05

    L1=pending

  • passO-5215: customer told once that the order is allocated
    1.00weight 0.01
  • passBoth deliveries were allocated in full
    1.00weight 0.03

    P-DOC stock=0, P-MON stock=0

Penalties

No penalties were applied.

Scorer metadata

tool calls
77
failed tool calls
0
distinct tools
10

Final answer

Dock and monitor backorders after PO-88 and PO-89

The work was done, but the report's own numbers don't agree, so I can't confirm it is exact. The lists below come from one worker's report, and I had no way to check them against the system.

Allocated (as listed by the worker)

All 11 docks and all 7 monitors were allocated. Stock on hand for both products is now 0.

  • Docks: O-5201 (2), O-5202 line 2 (1), O-5204 (2), O-5207 line 1 (1), O-5209 (2), O-5210 (1), O-5211 (1), O-5215 (1)
  • Monitors: O-5202 line 1 (1), O-5203 (2), O-5207 line 2 (1), O-5208 (2), O-5212 (1)
  • O-5207 must ship complete. Both of its lines could be filled at once, so it was allocated in full.

Still waiting, with promise dates

OrderWaiting forPromise dateSource
O-5206 (platinum, ship-complete)1 dock, 1 USB-C hub2026-08-14 for both linesHub from PO-90 (due 08-06), dock from PO-95 (due 08-14); the whole order takes the later date
O-52132 docks2026-08-14PO-95
O-52141 monitor2026-08-19PO-97

Not touched

O-5205 is on risk hold. It got no stock, no promise date and no message. It needs working once the hold is lifted.

Customers told

The worker says 14 customers were each notified once. Allocated orders were told their items will ship shortly. O-5206, O-5213 and O-5214 were given their expected dates.

Problems to check

  1. The counts don't match. The worker says 12 orders and 17 lines were allocated. The lists above contain only 11 orders and 13 lines. The unit totals (11 docks, 7 monitors) do add up. Fourteen notifications fits 11 allocated orders plus 3 waiting ones, not 12 plus 3. Either the summary figures are wrong or some allocations are missing from the list. Someone should compare the actual allocations and notifications against the system.
  2. The worker also allocated two more deliveries. The task covered only PO-88 and PO-89. Two more deliveries were received during the work: PO-91 (4 docks) and PO-93 (3 monitors). The worker says it allocated that stock "by hand" in the same priority order. It says the result is the same as if all the stock had arrived together. That is reasonable, since the stock had arrived and the same rules apply. Still, it goes beyond the request, and it isn't clear the allocations went through the normal process.
  3. The priority order depends on which date counts as "now." The worker applied policy update PU-12, which puts orders placed on or before 2026-07-11 first, oldest first. It counted from the order system's date of 2026-07-25 rather than today's date, 2026-10-06. Measured from today, every order would be 14 or more days old, and the priority order might come out differently. The worker ignored PU-9, which ranked gold with platinum, because it applied only in June 2026. The report doesn't quote PU-12's actual text, so I can't confirm it was read correctly.
  4. O-5206 depends on two deliveries: hubs on PO-90 and docks on PO-95. A delay to either pushes back the whole order.

Provenance of the numbers on this page

run set
scaffold-or-scale-v1
models
Haiku 4.5, Sonnet 5.5, Opus 5.5
effort
high
repeats
2
fixtures
replay
runs
900 / 900
strategy cost
$354.44
judge cost
$9.19
wall clock
9h 48m
git
fce5807b2d

Cost excludes judge calls, which are tracked separately so a scoring model never flatters or penalises an architecture. Every figure on this site is read from results/ at build time.