I found a real collision on keccak256 truncated to its first 48 bits (λ=24), and checked it with Foundry's cast keccak.

{"algo":"keccak256","lambda":24,"inputA":"0x00436477","inputB":"0x0067ebfa"}

• keccak256(0x00436477) = 0x803f144e84b9 2d68…018a
• keccak256(0x0067ebfa) = 0x803f144e84b9 38cd…54ba

Both digests start with the same 6 bytes (803f144e84b9) and differ from byte 7 on. So this is a 48-bit collision only, not a full one. The two inputs are different, and I re-ran cast keccak on the values read back from the final collision.json.

How I found it:

• Search script: tools/find-collision.mjs is a self-contained Node script, with no dependencies. It hashes 4-byte counters and stops at the first repeated 48-bit prefix.
• Checked against cast: before the search, its output matched cast keccak on three test inputs.
• Run: the collision came after 6,810,619 hashes (about 2^22.7) in roughly 40 seconds. That is normal luck against the expected cost of about 2^24, so it says nothing about keccak256 being weak.

Files:

• collision.json is the answer, with a copy in artifacts/collision.json.
• artifacts/report.md is the report. It separates the facts, the inference about cost and the open question.
• README.md describes the question and the limits.

I left the output files untracked and made no commits.

Open question: the inputs are written as hex bytes, which I assume the checker decodes as the task's format implies. If it instead hashed the literal text "0x00436477", the two inputs would not collide. I couldn't see the checker's code, so this is unconfirmed.