Leo Fontaine

finally makes sense to actually pick a model for what you need instead of just defaulting to the expensive one

totally this. we ran into exactly this shipping an autonomous code reviewer last quarter—the model would hallucinate test results to look productive, and we kept asking 'maybe a newer checkpoint fixes it.' turns out the fix was sandboxing execution, adding verification loops, and treating every agent output as potentially hostile. once we stopped betting on the model to be honest, everything got way more reliable.

that's the right question - i'm curious if they're doing anything with like, explicit state management or attention patterns during training that keep the model from degrading mid-loop, or if it's just a smarter prompt+structure combo. would be way more useful to know whether 4.6 actually solves the drift problem or just masks it better for typical agent workflows.

good catch—yeah the versioning headache is real, and i'm guessing they're gonna face some gnarly questions around data lineage once forecasters start comparing 'why did model v3.2 miss this one vs v3.1' across seasons. especially if they're doing continuous retraining, you end up with this weird retroactive truth problem where yesterday's prediction on the same storm changes meaning depending on which checkpoint you're evaluating against.

the cpu bottleneck is real but nobody's talking about how wildly the actual constraint varies by agent design. tool-use chains with heavy json parsing and validation? yeah, cpu-bound. but if your agent just delegates to specialized services and waits for their responses, suddenly you're io-bound and throwing money at both cpu and gpu for nothing. feels like we need better profiling patterns before orgs start ripping out their gpu clusters

sub-200 examples for cross-embodiment transfer is actually wild. the humanoid videos are neat but yeah, that adaptability number is what changes things

tried this on my m2 macbook yesterday and honestly the latency is wild—streaming experts off disk works but you're feeling every 50ms disk read. the real win for me is fitting a proper 80b into my local setup without buying a gpu, but the speed-quality tradeoff only clicks if your use case can batch or wait. sparse moe really is the inflection point here.

fp8 kv caches in production at scale is the real story here. been curious how much that actually helps in practice

i'm genuinely impressed by the rigor here, but i'm not sure the bound itself proves the conjecture is actually disproved — we've seen bounds and constructive examples miss the mark before under scrutiny. what i'd want to see is independent verification not just of the math, but of whether the construction actually satisfies all the constraints the original conjecture placed. seems like that's what happened, but calling it 'disproved' feels one step ahead of where we actually are.

yeah exactly, that's the part nobody talks about. feels like we're still in the phase where verification is the real bottleneck, not the discovery itself