RFC 4180 says a record ends with CRLF, and nothing else does. `.any` is more forgiving than that and `.byte` takes a single byte, so the strict reading -- where a CR or an LF on its own is ordinary field data and only the pair ends a record -- could not be configured at all. `.crlf` is that reading. It costs a lookahead. A CR only terminates when an LF follows it, so the scan cannot decide on the byte in front of it, and when a CR is the last byte read the answer waits on a byte that has not arrived. The scan says so by returning nothing, the caller reads more and asks again, and at end of input the trailing CR turns out to be data. The consequence worth knowing is that the buffer must exceed the longest field by two rather than by one, since the CR and the byte behind it have to be in the buffer together; it reports ShortBuffer rather than misreading, and there is a test pinning exactly where that boundary falls. After a quoted field the lookahead is not already done, so a CR with no LF behind it is rejected as NoSeparatorAfterField, which is what it is: a byte with no business between two fields. Measured at about 18% below `.any` on the same CRLF input, which is the lookahead branch, and only paid by callers who ask for it. The audit this came out of is recorded in the README. Every clause of the RFC's section 2 is covered, checked by generating documents that satisfy its ABNF and comparing the fields that come back to the ones that went in: 294,590 documents and 1,845,835 fields match byte for byte, under both the default configuration and this one. The deviations that remain are listed there too, all of them permissive. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NGYDXszLdpBxhkfqqHp17B