KOM CLOUDSERVICE
All entries

We lose time in the transitions

Friday: all 15 checks in 219.5 seconds, down from ten minutes two days before, 8th for the day, and a lesson from the leader about the gaps between the clocks.

Shaded passages were held back from the public edition while the event ran.

Friday was the second live race. All 15 checks came back CORRECT, and the last one landed 219.5 seconds after the release.

Two days earlier that number was ten minutes and forty-four seconds.

It was also the first race with the release jump, warmups polling its own challenge name instead of waiting on the day list. On Days 14 and 15 the robot found out the race had started 17 and 20 seconds late. On Friday it saw Day 16 the instant warmups answered, a fifth of a second before the list did.

The run

  • Mobile, JNI Boundary: 11.5 seconds. Right on the first try.
  • Script, Same Same, But Different: 20.5 seconds. 1,095 of 1,095 on the first try.
  • Warmups, Dot Com: 83.5 seconds. Morse code stacked over hex, and the engine had never heard of Morse.
  • Metadata, Return to Sender: 96.5 seconds. An email thread, and nothing in the robot could read an email yet.
  • Binary, Wasm Up: 219.5 seconds. WebAssembly, built two different ways. The first try banked 154 of 160 answers in 20 seconds. The last six took about three minutes.

Same lesson as Thursday, only louder. The lanes our engines already knew were done in about 20 seconds. Every second after that went to things the robot had never seen: a new file format, a new alphabet.

All three slow lanes went to the lane agents, the AI sessions on standby that write new code when the robot meets something it cannot read. On warmups the engine stopped and raised its hand 4.2 seconds in, and an agent wrote a Morse step in about a minute. On metadata the generic fallback could only offer whole header lines when the question wanted a bare Message-ID, so an agent wrote a proper email reader. The last six binary answers were an agent’s work too.

Wasm Up had a nice twist. The binary lane always hides a config blob somewhere, and this time it was tucked into the WebAssembly data segment. The same scan that found it all week found it here too, without parsing a byte of WebAssembly. A week of the same prize in a new wrapper paid off.

What cost us was the hash slots again: the grader numbered them in the order the files sat in the zip, same as Thursday. That rule is now permanent.

8th

I came out of Day 16 8th for the day. The top three finished at roughly 50, 90 and 170 seconds after release.

We were close enough to see them now.

The robot also caught its own slip that morning. The first poll of the day did not go out until 09:00:09.996, almost ten seconds late. The script that waits for the release had read the clock, done a twelve second cache refresh, then slept as if no time had passed. The leader saw the list at 2.8 seconds. Ten seconds late was a bug, but it also showed how little slack we had, so I moved the first poll earlier twice, to 08:59:53 that afternoon and to 08:59:45 that night, and fixed the bug that night too. Polling early costs nothing. Seeing the release late costs the day.

”We lose time in the transitions”

Later that day the competition leader said something that stuck with me: we lose time in the transitions. Not on the clocks. Between them.

The robot went and checked. They were right.

On mobile, the Single Solve to the finished Mastery took 9.6 seconds of wall time, but only 2.5 of them were on the server’s clocks. On script it was 15.1 seconds against 5.4. The rest was the robot asking for status, waiting on its own safety checks, and re-reading files it had already read. That night it cut those gaps: run the Mastery’s safety checks while the Time Trial is still going, trust a CORRECT verdict without asking again, and trace every call so the next gap shows up on its own.

Asking “what if”

Then I asked the robot the question I should have been asking every night: “if we had implemented what we’re doing now last night, would it have made today’s solve significantly quicker?”

It built a way to answer that. For Day 16 the answer was yes: about 83.5 seconds instead of 219.5.

From then on that question was how we judged every fix. Being right was no longer enough. A fix only mattered if it would have made the morning faster.

The tool takes the code as it stood the night before a race, applies the day’s fixes on top, and replays that morning’s release against a fake Game Master, a local stand-in for the event’s server that plays back recorded days. It is strict about hindsight: each lane only gets what existed the night before, or the answer means nothing. With Friday’s fixes, metadata and binary would have been right on their first try, and the Morse step would have become the slowest thing left.

A race of agents

The bigger idea of the day was about the agents themselves. When a lane needs new code, why send one model? Send several, let them race, and take whichever comes back right first. The agents never submit anything. They write small rule files, and the engine checks those rules against the real file before a single answer goes out.

The robot built it that evening with a cheap, fast pair on each lane: one Sonnet and one Opus, both at low effort. On replays of the two previous races it finished Day 16 in 54.6 seconds and Day 15 in 65.5, 15 for 15 both times. Inside the one-minute window, on paper. Saturday would say whether paper held up.

How we built it: the Day 16 dev log

Why the agents write rules, not answers. The model stays off the submit path. An agent writes a small rule file, the engine runs it against the real file, and the engine, not the model, sends the answers. The rule files went in behind a switch, off by default, because the first review found rule code running inside the release process itself. They stayed off until that was fixed.

Why we tested small. That afternoon a big benchmark of models and effort levels, plus several builders, chewed through my usage limit in a few hours. I told the robot to take it easy and test smaller. From then on a model run gets sized to the question, and nothing heavy runs near 09:00, when the live agents need the same limit.

Why a miss stops the walk. When a timed answer is wrong for a reason the robot does not understand, walking down its list of guesses under the clock just burns the clock. With my go, a systematic miss now stops the walk and leaves the question to an agent’s ticket, the short report the robot writes when it cannot answer something.

What we left alone. The transitions work also built a way to keep each lane’s worker loaded and warm before the release. We left it switched off: on the fake Game Master it saved about half a second per lane, and the review cleared the batch to land only with it off.