Scale a recipe to a new serving count and convert it to metric
Exact prompt
# Scale a recipe and convert it to metric Inputs: `recipe.json` (original servings and ingredients), `request.json` (target servings), `conversions.json` (unit factors). Rules: - Scale every quantity by target servings / original servings. - Quantities may be written as fractions or mixed numbers such as "1 1/2". - Convert volume units to ml and weight units to g using conversions.json; amounts already in g or ml keep their unit. - Round metric amounts of 10 or more to a whole number, and amounts below 10 to 1 decimal place, half-up. Decide using the exact scaled, converted amount. - Count items (unit "each") are rounded UP to a whole number and keep the unit "each". - total_g is the sum of the rounded g amounts and total_ml the sum of the rounded ml amounts. Write `out/scaled.json`: `{"servings": <target>, "ingredients": {"<name>": {"amount": <number>, "unit": "g" | "ml" | "each"}, ...}, "total_g": <number>, "total_ml": <number>}` with every ingredient from recipe.json, keyed by its name. ## How this run works - Work on your own: nobody will answer questions in this task, and writing to `ask/` counts against the run. - Write only under `out/`. Create `out/` if it is missing. Inputs are synthetic; don't fetch anything from the network. - Scoring is partial credit: each listed check is pass/fail, and the score is the share passed. Numbers are compared to within 0.005 unless the task says otherwise.
Scale a 9-12 ingredient recipe written in cups, spoons, ounces, sticks and fractions to a new number of servings and convert it to grams and millilitres. Amounts follow a two-tier half-up rounding rule and count items round up. Inputs are drawn fresh per seed, with draws near rounding ties or the 10-unit threshold rejected. Original benchmark task written for usecaserank.com (not based on a specific public post). Headless, offline run on a reproducible fixture. Each run's notes say how its cost was measured (estimates are marked).
Success criteria: all_ingredients_and_units volume_amounts_ml weight_amounts_g small_amounts_one_decimal count_items_rounded_up fraction_quantities_parsed totals
Best model for this task so far: Claude Haiku 5.5 (effort default (no --effort flag) · thinking on) (success, $0.0038, 12s).
All runs (4)
75% pass rate across 4 eligible runs: 3 pass, 0 partial, 1 fail. Partial and failed runs are listed below with everything else.ⓘ
| Model | Cost | Time | Step-insⓘ | Autonomy | Outcome | Trustⓘ | Date | Compare |
|---|---|---|---|---|---|---|---|---|
| QQwen3 Coder 480B Turbo (Venice)thinking on | $0.0018 | 19s | 0 | Fully autonomous | fail | Trust 80% | 2026-10-28 | |
| AClaude Opus 5.5default · thinking on | $0.10 | 14s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-20 | |
| AClaude Haiku 5.5default · thinking on | $0.0038 | 12s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-20 | |
| AClaude Sonnet 5.5default · thinking on | $0.04 | 10s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-20 |
Embed this result
A live badge for this use case. It links back here and updates as new runs are published.
Get new runs and ranking changes weekly
Which models got better or cheaper on real tasks like this one.