Yeah, I’d expect packing latency to be measured alongside retrieval and generation when taking this into production. The full count approach gives the example a straightforward correctness baseline, if profiling shows it's becoming expensive, an incremental counter is a sensible optimisation, validated against that existing path.

Keeping the example's full-count path as the baseline makes sense. For an incremental implementation, I would build the parity fixtures around boundary cases: an empty section, a source label containing non-ASCII text, a section admitted exactly at the budget, and one rejected just above it.

Assert the selected section IDs as well as the final count. Two counters can disagree only slightly yet choose different evidence at the boundary, which changes the model input even when both totals look reasonable. Profiling can then decide whether the extra implementation is justified.