karelpeeters

The website seems a bit barebones indeed, but it does list the processor used: NXP Layerscape LS1046A. The youtube channel links to discord/email, so he's probably reachable there.

Great to see people are still doing UTTT competitions! I remember spending months working and competing with a friend on our own bots for theaigames.com, which was a similar site that has since shut down. I never got good enough to score highly on the leader board, but the experience taught me a lot about tree search, (micro)optimizing algorithms and programming in general.

In general that's true, but to reason about boolean circuits like in this challenge we only need a SAT solver. Z3 is just used for it's convenient API.

Degate is even a bit overkill, it is meant for when you only have images of the physical chip. This challenge has the full GDS files, which are the files that are sent to the fab for manufacturing. They still contain information about all of the separate layers. In this case they even contained the stdcell names, making even full transistor and logic function extraction unnecessary.

No, I think the comment you're responding to is actually correct. Look at this quote from the Anthropic blog post again:

> The design should have been simple: if a session has been idle for more than an hour, we could reduce users’ cost of resuming that session by clearing old thinking sections. Since the request would be a cache miss anyway, we could prune unnecessary messages from the request to reduce the number of uncached tokens sent to the API. We’d then resume sending full reasoning history. To do this we used the clear_thinking_20251015 API header along with keep:1.

They clearly make the same distinction between the cache and the context. They're saying "we could reduce users’ cost of resuming that session by clearing old thinking sections". They intentionally created a behavior different between cached and uncached requests, specifically they clear thinking sections from the context for requests that miss the cache.

What would be the point of embedding Redis into an application? What's the advantage of using Redis over using the builtin (or third party) data structures of the language the application is developed in?

I'm asking as a non-webdev who never quite got what Redis actually does, but would love to learn.