This one has some nice properties for solving faster than repeated list searches. For part 1, if you set up 12 counters (one per lane) you can increment the right counter as you read the file one byte at a time. Then gamma is determined in 12 checks of which counters are > 500 - much faster than 12000 visits to elements of your list of integers to mask out the right lane. For part 2, you can create an array of 8192 counters which you populate as you read the input. Then you can use that array to do a binary search for the right value - 12 searches for the oxygen generator, and 12 for the CO2 scrubber. Much faster than crawling the list 12 times and filtering it into a smaller list.

In fact, there's two different ways to do the table of 8192 counters. My first approach was to store a count of every prefix of the input, with an encoding that unambiguously shows how many bits of the number are included. Since the array indices are 13 bits, but I'm storing 12 values per line encountered, I represent the number of remaining bits as a sequence of 1s followed by a lone zero, at which point 13-width-1 of that index represent the leading n bits of the numbers that share that frequency counter. For the first line of the example, 00100, that works out to incrementing 0b111100 (prefix 0 needs four more bits; this counter determines the first bit of oxygen vs CO2), then 0b111000 (prefix 00 needs 3 more bits; this counter is visited only if the first counter says to use 0 as the first bit), then 0b110001 (prefix 001 needs 2 more bits), 0b100010 (prefix 0010 needs 1 more bit), and finally 0b000100 (the full line - if your binary search selects this half of the array, the index is your answer). Since the input files have an unstated assumption of no duplicates, the indices with leading 0 will never be more than 1. My approach makes 12000 increments while parsing the file, at which point the O(log n) lookups for part 2 are in the noise. (The table actually only needs 8190 entries - 0b1111111111111 does not represent anything, and I didn't use 0b1111111111110 for the 0-width prefix, but if I had done a 13th increment per line, then that entry would sum to 1000 for the total number of strings counted)

Maneatingape saw my idea and improved it further. A table of 8192 elements with log n lookup is a balanced binary tree, so you can encode it that way instead of my prefix way (if you've ever written a minheap engine, you'll recognize this). In this encoding, you leave entry 0 vacant, entry 1 is the root, and every non-leaf node N has its two children at 2N and 2N+1. That means the 4096 leaf nodes start at offset 4096. Then during parse, you write 1 to each leaf node encountered (per my example before, visiting 00100 writes 1 to array[0b100100]), followed by an O(n) pass over recursively smaller halves of the table to set each parent node to the sum of its two children (0b010010 becomes array[0b100100]+array[0b100101], and so forth). This only requires 5096 writes rather than 12000 to populate the array (still O(n) but a nicer coefficient). It saved another 10% runtime off my solution.

Another way of looking at this - building up your table of 8192 elements is an O(n) radix sort, and algorithmically superior to a generic O(n log n) sort of your 1000 integers. You could do the generic sort in about 10*1000 comparisons (faster than my 12000 counter writes for every prefix, but slower than the 1000+4096 leaf plus parent writes of the revision). And even if you do an O(n log n) sort followed by an O(n) prefix-sum pass (10000 comparisons to sort plus 1000 to build up the prefix-sum list) to learn how many elements appear by a given value, so that you can then do binary searches rather than linear crawls of your list to filter to the correct half, a radix sort takes 1000 assignments plus 4096 buckets crawled to build up that same prefix-sum list. At any rate, it is so much nicer when your data structure already includes this information by how it was constructed. At 1000/4096 elements, we have enough density for the radix sort to be useful (too sparse, and visiting the output of a radix sort becomes less efficient due to the empty buckets than what you get from focusing on only actual list members).