leodavi

How does that apply to AI Overview in Search, though? As far as I can tell it's pure spend on every search, which I know adds up even for nano models.

Running two tasks simultaneously with Fable and Opus 4-8 on ultra reasoning

That's abnormally heavy usage for Pro plans which don't include a whole lot of usage to begin with. Opus is generally too much for them but you can get a lot of mileage out of Sonnet.

How is this meaningfully different than simonw's pelicans riding a bicycle? If anything, this seems to be of a higher caliber?

I agree with you that labs are benefiting from those outputs but I'm skeptical that labs are purposefully training the models to produce those outputs.

Raw pre-training data includes plenty of conversations between professional builders and some of those include estimates.

I believe the outputs are a training coincidence with consequences that are opportunitistic for the labs.

Insincere apologies ought to be mocked to shit but this apology seemed well-meant. (I know you're not mocking them and the last sentence is actually something Claude would say.)

I post this angry comment because LLMs are colonizing the language we use for creating an earnest and genuine tone in online discussion and I sometimes wonder if the suspicion surrounding LLM-ish language is worse for the health of our online spaces than the LLM slop itself. Thinking about it, I don't think it is; and it would be impossible to measure anyway.

I want more of this. Trees using coordinated cell transpiration to control the weather is so fictional but so possible. It's the kind of thing that makes Earth so cool. What do you read? Anything digestible to a curious layman with ~20 minute reading sessions on the train rides?

Well, in C++ the constructor must return a value of its class type - you can't return an Option<T> from a constructor on T, for example, and since constructors are the canonical way to construct an object, it creates stylistic and idiomatic friction when you start using free functions to create a Maybe<T> instead of constructors.

in a highly controlled and predictable environment

Why this constraint? A common sentiment I see online (sorry, to group you in) is "[tool] will be capable, actually, but only in a context that trivializes its usefulness."

I think modern post-training like RLVR + inference-time output token scaling can _probably_ scale so the agents can solve any computable task, even when placed in noisy or misconfigured environments. But it won't be economical for a long while. But it already seems largely capable of that today.

Probably not. The active parameter set may change from token to token, based on my understanding of MoE, so you'd be streaming (at the worst case, unlikely for a real scenario but frames the problem) 49B parameters from SSD for every output token...

The narrative style reminds me of the novel-game Caves of Qud. Very well done.

To the author: this work you've published rests on some background knowledge that I'm familiar with but also a lot of background knowledge that's foreign to me. For the parts I was able to follow, I thought the mental gear-turning was enjoyable and interesting! But pursuing these intersections between algebra and computer science is often not so interesting, at least, when I research it myself. Is this something you've learned in university? I ask because I fear that without a formal learning environment, I may never pick up on the more advanced logic halfway through the article. Anyway, cheers to the good work.

A visual editor for creating video games on the browser and on Linux desktop: https://stickyfingies.github.io/g2ngine

I've done this with C++ in the past, but ran into substantial friction with the CMake toolchain, specifically w.r.t:

- cross-platform compilation with large dependencies (vcpkg ports)

- running multiple compiler chains in the same build step

That second point is necessary if, for example, there's some AOT asset processing work that uses a native tool, and you're building for web. Expressing that some targets should use the emscripten toolchain while others should use the native toolchain, and interleaving between them, was a mess. TBF, I haven't done that with cargo or build.rs yet and it may prove to be equally frustrating.

Other features:

- undo/redo using a stack of swappable states

- serialization to disk (native) and LocalStorage (web) with some integration tests in progress but I am not satisfied with the correctness of my implementation: I want to *guarantee* that all information is preserved round-trip, but I also want a Patek watch.

- OBJ, GLTF, GLB models are loaded as "blueprint scenes" which are distinct from the "world scene." I made this distinction at the type-level because "scenes" are groups of entities that use newtype IDs (`LightId(u64)`, `MeshId(u64)` etc.) as primary and foreign keys to refer to each other, and I wanted to make it impossible for an entity in scene A to hold an ID for an entity in scene B. Instantiating a blueprint requires creating new IDs for every object.

- W.I.P. Alpha rendering, depth sorting, overhauling the material system to support multiple shaders (tough) that may be compiled after the engine itself (even tougher, a lot of runtime dynamic state and schema validation stuff), physics, scripting - oh yeah!

- Scripting using JS on both web (runs in browser itself) and desktop (uses a packaged JS runtime `Boa`) but Boa doesn't perform well on desktop in debug mode so I'm exploring other options.