Reimburse a month of business mileage with a yearly rate threshold, home-start commute deductions and passengers
Exact prompt
# Pay October's mileage claims Inputs: `employees.csv` (normal one-way commute in miles and business miles already claimed this tax year before October), `trips.csv` (October trip log) and `mileage-policy.json`. Work out each employee's mileage payment for October 2026. - Trips with purpose `commute` are not paid and don't count toward any total. - A business trip whose `start` is `home` has the employee's `commute_miles` deducted from its miles (never below 0). That deduction is not business mileage. - Business miles are paid at `rate_high` until the employee's tax-year business miles reach `threshold_miles`, then at `rate_low`. Take trips in date order (then trip_id); a trip that crosses the threshold is split at it. - Each passenger adds `passenger_rate` per business mile of that trip. - Work exactly; round only the reported figures, to 2 decimals half-up. Write `out/mileage.json`: `{"payment": {"<employee_id>": <October payment>, ...}, "business_miles": {"<employee_id>": <October business miles after deductions>, ...}, "total_payment": <sum of the rounded payments>}`. List every employee with a paid trip. ## 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.
Pay staff mileage claims for a month from a trip log. The higher per-mile rate applies only until each person's tax-year business miles pass a threshold, which can happen partway through a trip, trips that start from home lose the person's normal commute, commuting trips pay nothing, and carrying a colleague adds a passenger supplement. Ignoring year-to-date miles, the commute deduction or the passenger rule each changes someone's payment. 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: payments home_start_deduction threshold_split commute_and_passengers
Best model for this task so far: Claude Haiku 5.5 (effort default (no --effort flag) · thinking on) (success, $0.0053, 20s).
All runs (3)
100% pass rate across 3 eligible runs: 3 pass, 0 partial, 0 fail. Partial and failed runs are listed below with everything else.ⓘ
| Model | Cost | Time | Step-insⓘ | Autonomy | Outcome | Trustⓘ | Date | Compare |
|---|---|---|---|---|---|---|---|---|
| AClaude Opus 5.5default · thinking on | $0.11 | 16s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-21 | |
| AClaude Haiku 5.5default · thinking on | $0.0053 | 20s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-21 | |
| AClaude Sonnet 5.5default · thinking on | $0.06 | 15s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-21 |
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.