winwang

Would be interesting if you could team a fast and slow agent together -- slow model can either act directly or maybe just communicate to the fast model.

Another commenter appreciated the move towards a sane/nice standard. I am definitely on that side of the table. I'd rather feel good about the move -- good enough to ignore the other implied issues, lol.

I also think your point has at least one decent reading: that the upvotes help other practictioners update their mental model of their tools. There's probably also some value due to being an implicit "Claude Code megathread" for commenters to congregate around. News so minor that it does't even really make sense to force people to fully stay on topic, hah.

Gotta say, it is hilarious that this is the current top HN post. I feel like it's gotta say something about our current AI zeitgeist, that there is such vigorous attention on a seemingly-minor change. Feels like something is on the tip of my tongue but I can't name it at the moment.

If anyone wants to write/link a much better-thought-out post, I'm all ears!

Having also played with Metal and WebGPU (at least years ago), I would say that CUDA is, amazingly, the best GPGPU API we have. Do I wish we had an open source parallel programming language as good or better than it? Yes. But asymmetrically hating on CUDA like this is how we continue to lag behind it in UX.

> The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually

Not to mention that this is a completely sane way to use CUDA as well.

Really exciting but it reads like Claude instead of what Nvidia posts have generally been like in the past. I don't need nor want my tech blogs to sound like a young adult novel.

(Without profiling or looking into this at all) I'd guess this has to with thread creation, inter-core communication/latency, and possibly having to merge results or otherwise interleave operations. SMT is another likely candidate.

Regardless, CPUs are really good at single-thread.

imo, partially because it's still not easy (in terms of code -> formal proof). With AI, I've been Lean-ifying a simpler (but non-trivial) algo. Pointing (current) AI at it only goes so far and in fact might go "too far" in certain cases, where a non-formalized argument would have sufficed. There's also "who watches the watcher" -- did it really prove what we're supposed to prove?

For something like these compression algos, though, I imagine it would be much easier since they already have actual proofs out there.

"maybe even psychologists" -- unironically true, but maybe I am talking about something different from you. The basis of (higher-level) math seem to mostly be "am I psychologically (emotionally...?) comfortable with accepting annoying ideas?" At least from my experience.

Every day, we stray closer to Haskell. Dare I say it: good!

(not the above poster but) I set up a local workspace for it to read/write from, so that edit is effectively just VSCode/vim. Unfortunately, it seems more verbose when writing out to file.

I decided to ask chatgpt for a fermi estimate of cores/datacenter, which you can check for yourself: 1~10 million physical cores. The surprising part of this for me was the "low" power usage (it used 20MW/"datacenter" as another point for estimation).

1MW ~ 6700 NYC citizens' residential usage, apparently, lol. I don't know exactly why, but that citizen number seemed a surprisingly large (well, probably because I've played with approximately-MW lasers).

Back of the envelope math, if anyone wants to correct my mental model: 2.1B (mincore)/week ~ 300M (mincore)/day. Assuming ~300k cores (~3k physical server CPUs, seems fine), that's 1k min/day. Seems about right, though obviously not uniformly distributed.

In any case, the number I'm focusing on here is the 300k cores part (x2 if you're counting in vcores). It does not seem like too much to ask for (significantly) more than that at github scale. It doesn't feel like a hardware issue, is what I'm getting at.

I don't GR but I'm fairly certain dipole does not work for gravitational waves (i.e. two objects accelerating straight at each other). Supposedly, there's a specific definition of "gravitational wave" here. You can, of course, detect the change in gravity though, regardless of "gravitational wave" or not.

Wouldn't discretion "just" be a really good rules engine?

I used Claude to generate technical SVGs (which are verifiable correct) because I wasn't going to take the time to draw the grid/arrows/etc.

... I don't think the original commenter said anything about mice being a non-model organism. But mice are far from humans, and I, at least, find the distinction rather important.

This is a big part of why I am in love in Posthog's design (though personally I have little belief in my own current ability to replicate it)

Almost completely disagree. Slightly more expensive, but significant better on a per-prompt basis? For non-trivial projects, the former is a small linear increase, the latter is a (somewhat-)exponential(-ish) cost/time/sanity savings.

I found 4.6 more amenable than 4.8 to style directions, we'll see how 5.0 does. Super-small-sample-size: I think part of its "Claude-ism" style comes from its propensity to try and "proactively" move the conversation/work along. Not sure how this would fare in non-obviously-productive environments, I'd guess "it's still annoying" considering your evidence.

I'm also thinking of another benchmark: (quantified) stylistic range across different prompts. Just putting it out there if anyone wants to do the work for me :D

Several other commenters have disparaging the design seemingly mostly due to its AI-generated nature, or maybe they actually do dislike cyberpunk.

Personally, I think being able to have these design languages be easily prototypable is fucking awesome. Great tests! (But a tad low-performance/janky, somehow). Though, I also like the cyberpunk aesthetic. Very on-brand(?) that AI generates it, hah.

> This isn't a real product.

The most disappointing part q_q

How bad is it for you? Are you on ultra or xhigh/max? I typically ask it (5.5, now 5.6-sol) to use subagents for specific things anyway. On the Pro 20x plan, I'm seeing like ~1% usage per 20-30 min per session (on max effort), which is in line with 5.5. Currently trying out ultra on a personal project, feels like ~3x more expensive per unit time. (No idea on quality yet, for obvious reasons.)

I find it interesting that no one here has mentioned the increased (usable) context window 258k -> 353k. That's huge, but I wonder if it means we pay long context (2x) for the ones past 272k still.

I would pay $200/mo for Opus 4.8 already. Fable 5 is just a cherry on top (although, without it, Codex 5.5 is the better buy imo).

Honestly quite excited to see what can happen here, I think biology has generally had a lack of data science expertise.

(Yes, not yet, but...) As a Scala afficionado, "free"/freer runtime performance is very welcome :)

Fun read.

(Based off 2-3 month-old recollection, take with a grain of salt)

I had wanted to use it for my agent "network". A2A didn't fit the use case of "trusted agent, and was bloated due to "what if rogue actor". Of course, I could have used it, with all of its roughness, but chose to just vibe my own (before Claude Teams, though I haven't really used that, I think). In the process of creating a server to handle this (I already set up a Scala webserver to administrate/orchestrate hooks). Would love to hear others' suggestions for this.

Not saying you're doing this specifically, but I'd be careful with thinking that "company" in China means the same as "company" in America (or in the West more generally).

Love this. I've shifted in the past few months to using highly expressive types in Scala 3 to have types carry more and more compile-time proofs (without macros, though a couple are warranted). Not only does it help with agentic test "sprawl", it seems to prevent agents from falling into lower-quality modes of operation. One of the more annoying things I've been preventing is what I call "noun accretion", where agents try and make a new monomorphic type for everything, instead of clearly genericizing when sensible. My bet is on formal-method-shaped tooling (including languages with strong type systems) to accelerate decent-quality agentic coding.

When I say "highly expressive types", I mean techniques I'd likely not want to ship in a typical codebase, unless the team was already on the typelevel programming bandwagon (i.e. having HKT and type functions being basic blocks already, not weird). Agents are better at "math" than basically most devs (even category-theory-pilled ones), at least in terms of knowledge. Better yet, they are decent at pedagogy, especially when considering they have "infinite" patience for dialogue.

In a more personal setting, I've had Codex Lean-ify a couple of my hobby proofs, it was extremely easy. Note: not saying it did this 100% "correctly" (gotta learn more Lean 4 to check more thoroughly), but it also seems to check for classic proof gotchas by default. Very excited for the future of formal methods.

Minor note, 2x $/tok is not 2x cost. Personally, I see Fable being significantly more token-efficient than Opus 4.8. Then, there's also the compounding costs of quality.