the 8 hours vs 2 weeks framing is the part i'd want more on. generating candidates got cheap, checking them didn't. what does the funnel actually look like ,of the candidates from an 8 hour run, how many make it to synthesis?

asking because i hit the same shape in a much dumber domain and what got me was that the failures were quiet. nothing errored, output looked normal, it was just wrong in a way only someone who knew the domain would catch.

You can see from our the benchmark that only one of the candidates proposed was determined to be worth synthesizing. Each individual candidate generation is quick, 8 hours is required for the model to iterate with various tools to find ones worth submitting.

We found that speaking to domain experts was critical in desigining a rubric that could catch these silent synthesis recipe failures, before we attempt the longer 2 week synthesis effort.

Neither of the recent ones was actually a container escape though. The OpenAI one in July found a misconfig in the sandbox network, and Kimi K3 last week just walked out to grab answers off GitHub during an eval.

Both went through stuff the sandbox was set up to allow.

Rippling had a writeup on this. 40% of R&D payroll going to tokens, one engineer at $50k/month. They got it down 37% just by routing cheap stuff to cheap models, no usage cut.

The warm-pool tree (kernel → base runtime → app) with CoW memory pages is a nice design — that's the part that makes 3ms believable rather than marketing.

Question on the shared SQLite: with multi-writer CRDT replication and eventual consistency, how do you handle operations that need global agreement — unique usernames at signup, or "did my vote count exactly once"? The HN-clone demo has both auth and voting, so I'm curious whether the HTML app model resolves those at the CRDT layer or accepts last-write-wins and tolerates the edge cases.

useful skill! thks :)