Check airline crew rosters against duty, rest, rolling-window and consecutive-day limits
Exact prompt
# Check crew rosters against duty-time limits Inputs: `crew.csv` (crew id and home-base time zone), `duties.csv` (duty periods in UTC, merged from the roster system and a second import). Rules: - The second import repeats some duties under a differently formatted id ("D-00123" vs "D00123"). Duties with the same crew, report time and release time are one duty. Report duty ids as "D" followed by the digits only, e.g. "D00123". - long_duty: duties longer than 13 hours (exactly 13:00 is allowed). - short_rest: duties whose rest since the same crew member's previous release is less than 10 hours (exactly 10:00 is allowed). List the later duty. - over_60h_168h: crew members who have more than 60 hours of duty inside any rolling 168-hour window (any start time, not calendar weeks). Duty time is counted only where it overlaps the window. - seven_day_runs: crew members who report for duty on 7 or more consecutive calendar dates, using the local date of each report time in the crew member's home-base time zone. - Every list is sorted. Write `out/limits.json`: `{"long_duty": [...], "short_rest": [...], "over_60h_168h": [...], "seven_day_runs": [...]}`. ## 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.
Check about 1,400 duty periods for 40-55 crew members against four limits: maximum duty length, minimum rest, 60 hours in any rolling 168 hours, and seven consecutive local duty dates. A second import repeats some duties under reformatted ids. Rest and duty lengths sit exactly on the limits on purpose, and 'consecutive days' is judged on home-base local dates rather than UTC. 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: long_duty short_rest rolling_168h seven_day_runs
Best model for this task so far: Claude Haiku 5.5 (effort default (no --effort flag) · thinking on) (success, $0.0058, 24s).
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 |
|---|---|---|---|---|---|---|---|---|
| GGemma 4 31B Instruct (Venice)thinking on | $0.05 | 5m | 0 | Fully autonomous | fail | Trust 80% | 2026-10-28 | |
| AClaude Opus 5.5default · thinking on | $0.15 | 26s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-20 | |
| AClaude Haiku 5.5default · thinking on | $0.0058 | 24s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-20 | |
| AClaude Sonnet 5.5default · thinking on | $0.06 | 15s | 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.