Skip to content

Claude Sonnet 5.5 (effort default (no --effort flag) · thinking on) on Decode a recorded long-wave radio time-signal sample into the exact date and time, with parity checks and missed pulses

AClaude Sonnet 5.5default · thinking on · Claude Code 2.1.299 (headless -p) · cloud · 2026-10-25 · by @bobsiopener

Trust 80%Fully autonomoussuccess · first try
Estimated cost
$0.06
Wall time
21s
Human step-ins
0
Outcome
Pass

Compare with other models on this task →

Summary

Exact prompt

# Decode a recorded long-wave radio time-signal sample into the exact date and time, with parity checks and missed pulses Input: `recording.txt`, a synthetic capture of a long-wave time-signal receiver's carrier level, one sample every 10 ms (lines starting with `#` are comments; the other lines are one long run of samples, wrapped at 80 characters, `1` = full carrier, `0` = reduced carrier). Sample i is at time i × 10 ms from the start of the recording. The transmitter, the receiver and the recording are synthetic. These rules are the format's; where `receiver-notes.txt` disagrees, the rules win. Rules: - Noise: first, every run of identical samples shorter than 5 samples (under 50 ms) is noise; give it the level of the samples on both sides of it. Then each run of `0` is a reduction; its start is the time of its first sample and its length the run's length × 10 ms. - Pulses: a reduction shorter than 150 ms is a 0 bit and one of 150 ms or more is a 1 bit. - Minutes: each second normally starts with a reduction; second 59, the last second of every minute, has none. A gap of 1.9 s to 2.1 s between two consecutive reduction starts means one second had no reduction: it is a minute marker when another such gap starts 60 s (±0.1 s) before or after it, and otherwise a pulse was missed. Second 0 of a minute is the reduction that ends a minute-marker gap. Bit n of that minute (n = 0 … 58) is the reduction that starts n s (±0.1 s) after second 0's start; if none does, bit n is missing. A minute is complete when its second 0 and the next minute marker are both in the recording; decode complete minutes only, in recording order. - Layout: bit 0 is always 0 and bit 20 always 1; bits 1–16 and 19 carry other information and are ignored; bit 17 = 1 means summer time (UTC+02:00) and bit 18 = 1 means winter time (UTC+01:00). Binary-coded decimal, least significant bit first: minutes in bits 21–27 (weights 1, 2, 4, 8, 10, 20, 40), hours in 29–34 (1, 2, 4, 8, 10, 20), day of month in 36–41 (1, 2, 4, 8, 10, 20), day of week in 42–44 (1, 2, 4; 1 = Monday), month in 45–49 (1, 2, 4, 8, 10) and year within the century in 50–57 (1, 2, 4, 8, 10, 20, 40, 80; the century is 2000). The time sent during a minute is the local time of the minute that starts at the next second 0. - Parity: even parity over bits 21–28, over 29–35 and over 36–58 (each group, its parity bit included, holds an even number of 1 bits). - Status: a minute is "missed_pulse" if any bit is missing, otherwise "parity_error" if any parity group fails, otherwise "ok"; only an "ok" minute gets a time. - Write `out/decoded.json`: `{"second0_ms": [<start of each complete minute's second-0 reduction, in ms from the start of the recording>], "bits": [<one 59-character string of 0, 1 and ? (missing) per complete minute>], "status": [<"ok", "parity_error" or "missed_pulse" per complete minute>], "times": [<"YYYY-MM-DDTHH:MM+01:00" or "+02:00" for an ok minute, null otherwise>], "status_counts": {"ok": <n>, "parity_error": <n>, "missed_pulse": <n>}}`, the four lists in recording order. - Roll-ups: Statuses with no complete minutes are included at 0. ## 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.

Decode a synthetic capture of a long-wave time-signal receiver: carrier levels every 10 ms with seeded glitches. Clean the noise by a stated run-length rule, read 100 ms and 200 ms pulses as bits, find the minute markers (and tell them apart from missed pulses), check the three even-parity groups and decode each complete minute's binary-coded local date and time, which refers to the following minute. Every case seeds one corrupted minute and usually a minute with missed pulses. Receiver notes get the noise, marker and parity 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: pulse_bits minute_framing parity_checks decoded_times status_counts

Setup notes: Batch 40 case tn03-radio-time-signal-decoding (offline, synthetic inputs, seed 432012140). Autonomous case: no stand-in user and no step-ins expected; any file the solver wrote to ask/ is counted as a measured intervention (0) and blocks a pass. Prompt = TASK.md verbatim. Hidden key kept outside the solver's work dir. Scored with the case's scorer (python3 score.py WORKDIR KEYDIR, absolute paths); pass = every check true and no ask/ files. Tools: Read/Write/Edit/Glob/Grep/Bash, web disabled. Single run, no retries. 1-min load average at scoring 0.30 (8 cores). Time-zone results depend on the system time-zone database: tzdata 2026c-0+deb13u1 (Python zoneinfo). Claude Code's own reported cost for claude-sonnet-5.5: $0.060821. Score: 5/5. Cost is an ESTIMATE: measured tokens x pricing.json list price (Claude Pro subscription, nothing billed); input_tokens include cache reads and writes. Single run.

Estimated cost List-price estimate; not actually billed.

Metrics

Estimated cost
$0.06
Wall time
21s
Human step-ins
0
Turns
3
Model usage
ModelInput tokOutput tokCost
AClaude Sonnet 5.5anthropic/claude-sonnet-5.5effort default (no --effort flag) · thinking on60,0062,100$0.06

Reproduce this run

  1. Use the use case prompt on the use case page.
  2. Same setup: Claude Sonnet 5.5 (anthropic/claude-sonnet-5.5, effort default (no --effort flag) · thinking on) via Claude Code 2.1.299 (headless -p), cloud.
  3. It counts as a success only if it meets every success criterion: pulse_bits minute_framing parity_checks decoded_times status_counts
  4. Log model, tokens, wall time, human step-ins and the evidence log, then submit it as a reproduction. A different model? Submit a head-to-head rerun.

How runs are scored: Methodology.

Was this useful?

⇄ Rerun on another model

Automated checks

Trust 80% comes from these checks (how Trust % works).

Evidence log
[
 {
  "duration_api_ms": 19434,
  "stop_reason": "end_turn",
  "session_id": "[REDACTED]",
  "total_cost_usd": 0.0608211,
  "usage": {
   "input_tokens": 6,
   "cache_creation_input_tokens": 8669,
   "cache_read_input_tokens": 51331,
   "output_tokens": 2100,
   "output_tokens_details": {
    "thinking_tokens": 433
   },
   "server_tool_use": {
    "web_search_requests": 0,
    "web_fetch_requests": 0
   },
   "service_tier": "standard",
   "cache_creation": {
    "ephemeral_1h_input_tokens": 8669,
    "ephemeral_5m_input_tokens": 0
   },
   "inference_geo": "global",
   "iterations": [
    {
     "input_tokens": 2,
     "output_tokens": 404,
     "cache_read_input_tokens": 19543,
     "cache_creation_input_tokens": 1665,
     "cache_creation": {
      "ephemeral_5m_input_tokens": 0,
      "ephemeral_1h_input_tokens": 1665
     },
     "type": "message"
    }
   ],
   "speed": "standard",
   "fallback_credit": null
  },
  "modelUsage": {
   "claude-sonnet-5-5": {
    "inputTokens": 6,
    "outputTokens": 2100,
    "cacheReadInputTokens": 51331,
    "cacheCreationInputTokens": 8669,
    "webSearchRequests": 0,
    "costUSD": 0.0608211,
    "contextWindow": 1000000,
    "maxOutputTokens": 128000,
    "thinkingTokens": 433,
    "canonicalModel": "claude-sonnet-5-5",
    "provider": "firstParty",
    "costBasis": "list"
   }
  },
  "permission_denials": [],
  "terminal_reason": "completed",
  "fast_mode_state": "off",
  "fast_mode_disabled_reason": "sdk_opt_in_required",
  "subagent_stats": {
   "spawned": 0,
   "requested": {
    "background": 0,
    "foreground": 0,
    "unset": 0
   },
   "started_in_background": 0,
   "max_depth": 0,
   "spawned_by_subagents": 0,
   "completed": 0,
   "failed": 0,
   "killed": {
    "parent": 0,
    "user": 0,
    "system": 0
   },
   "refused": {
    "depth_limit": 0,
    "concurrency_limit": 0,
    "budget": 0
   },
   "by_type": {}
  },
  "safety_stops": 0,
  "is_error": false,
  "num_turns": 3,
  "subtype": "success",
  "api_error_status": null,
  "result": "I decoded the recording and wrote `out/decoded.json`. It holds 4 complete minutes: 2 `ok`, 1 `parity_error` and 1 `missed_pulse`. I haven't checked the times against anything independent, because I only ran the decoder once.\n\nThe first minute decodes to `2026-02-28T21:54+01:00` and the third to `2026-02-28T21:56+01:00`. The second is the `parity_error` minute, so it has no time, and the fourth is the `missed_pulse` minute.\n\nFive minute markers were found, which gives the four complete minutes.\n\nI followed the task's rules rather than `receiver-notes.txt`. I cleaned the noise, checked that two-second gaps recur 60 s apart before treating them as minute markers, and checked all three parity groups.\n\nThe rules don't say what to do when a noise run has different levels on its two sides. I gave it the left side's level. I didn't check whether any run in this recording actually hit that case.\n\nThe decoder script is `/tmp/d.py`, outside `out/`.",
  "ttft_ms": 2329,
  "type": "result",
  "duration_ms": 19733,
  "uuid": "[REDACTED]",
  "ttft_stream_ms": 1674,
  "time_to_request_ms": 174,
  "first_content_frame_ms": 1675,
  "queued_turn_count": 0,
  "result_index": 0
 }
]

Get new runs and ranking changes weekly