Work out a family's health-plan cost sharing across embedded deductibles, copays, adjustments and out-of-pocket caps
Exact prompt
# Work out a family's health-plan cost sharing across embedded deductibles, copays, adjustments and out-of-pocket caps Inputs: `plan.json`, `members.json` and `claims.csv` (claim_id, member, service_date, received_date, service_type, billed_amount, allowed_amount, status, adjusts). Everything is synthetic and in dollars. `plan.json` and these rules are the record; where `benefits-desk-note.txt` disagrees, the rules win. Rules: - Process claims in service_date order, ties by the number in claim_id; file order and received_date don't matter. Only allowed_amount is shared; billed_amount is ignored. - A claim with status denied costs the member nothing and counts toward nothing. A claim with status adjustment replaces the claim named in adjusts: the original is processed at its own place in the order but with the adjustment's allowed_amount, and the adjustment row is not processed on its own. - Accumulators reset at plan_year_start: claims before it belong to the prior plan year, which has its own deductibles and caps. - preventive costs the member 0. A service_type listed in copays costs the member the copay (or the allowed amount if lower); copays never count toward a deductible but do count toward the out-of-pocket caps. - For any other claim the member first pays toward the deductible, up to the smaller of what is left of their individual deductible and of the family deductible (embedded: a member's deductible is done once either is used up). Then the member pays coinsurance_pct of the rest of the allowed amount, rounded half-up to the cent per claim. - A member's share on any claim is capped so that neither their individual out-of-pocket total nor the family's goes above its oop_max; deductible and coinsurance both count toward the caps. When a cap cuts a share, the part that counts toward the deductible is the smaller of the deductible part and the capped share. The plan pays allowed_amount minus the member's share. - Write `out/costshare.json`: `{"claims": {"<claim_id>": {"member": <dollars>, "plan": <dollars>}, ...} (every processed claim, not adjustment rows; denied claims as 0 and 0), "members": {"<member>": {"deductible_paid": <dollars>, "oop_paid": <dollars>}, ...} (current plan year only), "family_deductible_met_on": "<service_date of the claim that used up the family deductible in the current plan year>" or null}`. ## 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.
Split a family's synthetic medical claims between the plan and the members. Claims must be taken in service-date order rather than file order, adjustment rows replace earlier claims in place, a plan-year boundary resets the accumulators, copays sit outside the deductible but inside the caps, the deductible is embedded (individual or family, whichever runs out first), coinsurance is rounded per claim, and both the individual and the family out-of-pocket caps bite. A benefits-desk note gets the order, copay, family and adjustment rules wrong. 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: order_and_adjustments embedded_deductible copays oop_caps family_met_and_year
Best model for this task so far: Claude Haiku 5.5 (effort default (no --effort flag) · thinking on) (success, $0.0081, 41s).
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.13 | 1m | 0 | Fully autonomous | pass | Trust 80% | 2026-10-24 | |
| AClaude Haiku 5.5default · thinking on | $0.0081 | 41s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-24 | |
| AClaude Sonnet 5.5default · thinking on | $0.06 | 14s | 0 | Fully autonomous | pass | Trust 80% | 2026-10-24 |
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.