ScaffoldBench

RunSonnet 5.5repeat 1

Orchestrator-workers on Share two short deliveries out among backorders

claude-sonnet-5-5__orchestrator-workers__ecommerce-backorder-allocation__r1

Score

0.872

wrong answer
design ran as designed
Cost
$0.282
Latency
1m 30s
setup 0.0s, grading 0.0s
Turns
75
Tool calls
71
Subagents
1
Tokens in / out
244k / 13k
213,675 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 8.4s, finished, 0 tool calls, $0.019
Worker 1: all: 8.4s to 1m 14s, finished, 71 tool calls, $0.228
Synthesize: 1m 14s to 1m 30s, finished, 0 tool calls, $0.035

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

PhaseDurationCostTurnsToolsModel
Decompose8.4s$0.01920claude-sonnet-5-5
Worker 1: all1m 6s$0.2287271claude-sonnet-5-5
Synthesize15.4s$0.03510claude-sonnet-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-sonnet-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
  • failO-5208 allocated from the delivery
    0.00weight 0.05

    L1=backordered@2026-08-05

  • 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
  • failO-5212 allocated from the delivery
    0.00weight 0.05

    L1=backordered@2026-08-05

  • 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
  • failBoth deliveries were allocated in full
    0.00weight 0.03

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

Penalties

No penalties were applied.

Scorer metadata

tool calls
71
failed tool calls
1
distinct tools
11

Final answer

The backorders for P-DOC and P-MON have been worked, but the report has problems I can't verify, so I'd treat the result as needing review.

What the worker reports

  • P-DOC, 8 lines allocated (11 docks):

    • From PO-88: O-5201 L1 (2), O-5202 L2 (1), O-5204 L1 (2), O-5207 L1 (1), O-5210 L1 (1).
    • From PO-91: O-5209 L1 (2), O-5211 L1 (1), O-5215 L1 (1).
  • P-MON, 3 lines allocated (4 monitors): O-5202 L1 (1), O-5203 L1 (2), O-5207 L2 (1).

  • 6 lines still waiting, each with a promise date:

    • O-5206 L1 and L2: 2026-08-14. The order is ship-complete, with its dock from PO-95 (08-14) and a hub from PO-90 (08-06), so both lines take the later date.
    • O-5213 L1: 2026-08-14 (PO-95).
    • O-5208 L1: 2026-08-05 (PO-93).
    • O-5212 L1: 2026-08-05 (PO-93).
    • O-5214 L1: 2026-08-19 (PO-97).
  • Customer notices: 14 notices (N-1 to N-14) went out, one per customer, after the allocations and promise dates were set.
  • O-5205: left alone because it is on risk hold. There was no allocation, promise date or customer contact.

Things to check

  1. PO-91 was used outside the task. You named PO-88 and PO-89. PO-91 (4 docks) arrived mid-run and the worker allocated it too, then moved promise dates to PO-95. The lines affected are O-5209, O-5211 and O-5215. Decide whether that was wanted. Notices have already gone out on that basis.
  2. The line count in the report is wrong. It says 12 lines were allocated, but the lines it lists total 11 (8 dock lines and 3 monitor lines). The unit totals match the stock received. I can't tell whether a line is missing from the list or the "12" is a miscount.
  3. The priority rule may rest on the wrong date. The worker used policy update PU-12 to put orders aged 14 or more days ahead of the tiers, and treated PU-9 as expired. It measured age against 2026-07-25, but today's date here is 2026-10-05. I can't confirm which date the system reported, or whether PU-12 applies by order date or allocation date as its text defines. If the worker got this wrong, the allocation order for O-5201 to O-5204 and the orders below them could change.
  4. O-5205 still needs follow-up. Once the risk hold is resolved, its P-DOC line needs allocating or promising.

I didn't verify any of this independently, and no inbox messages or returns were touched.

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.