Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GPT‑5.3‑Codex‑Spark

openai.com

Post reply on HN
Print view View original

121–130 of 415 posts

Re: GPT‑5.3‑Codex‑Spark

#121

Post by whism »

onlyrealcuzzo wrote: post #109
pjs_ wrote: post #66

Continue to believe that Cerebras is one of the most underrated companies of our time. It's a dinner-plate sized chip. It actually works. It's actually much faster than anything else for real workloads. Amazing

Nvidia seems cooked. Google is crushing them on inference. By TPUv9, they could be 4x more energy efficient and cheaper overall (even if Nvidia cuts their margins from 75% to 40%). Cerebras will be substantially better for agentic workflows in terms of speed. And if you don't care as much about speed and only cost and energy, Google will still crush Nvidia. And Nvidia won't be cheaper for training new models either.…

I believe they licensed smth from groq

Re: GPT‑5.3‑Codex‑Spark

#122

Post by vel0city »

nikkwong wrote: post #64
gamegoblin wrote: post #38

Earlier quoted context omitted.

I routinely leave codex running for a few hours overnight to debug stuff If you have a deterministic unit test that can reproduce the bug through your app front door, but you have no idea how the bug is actually happening, having a coding agent just grind through the slog of sticking debug prints everywhere, testing hypotheses, etc — it's an ideal usecase

I have a hard time understanding how that would work — for me, I typically interface with coding agents through cursor. The flow is like this: ask it something -> it works for a min or two -> I have to verify and fix by asking it again; etc. until we're at a happy place with the code. How do you get it to stop from going down a bad path and never pulling itself out of it? The important role for me, as a SWE, in the p…

You do things like ralph loops.

https://github.com/snarktank/ralph

Its constantly restarting itself, looking at the current state of things, re-reading what was the request, what it did and failed at in the past (at a higher level), and trying again and again.

Re: GPT‑5.3‑Codex‑Spark

#124

Post by dekhn »

azinman2 wrote: post #110
moralestapia wrote: post #105

Earlier quoted context omitted.

This comment doesn't make sense.

Sure it does. If it’s many small dies on a wafer, then imperfections don’t ruin the entire batch; you just bin those components. If the entire wafer is a single die, you have much less tolerance for errors.

Although, IIUC, Cerebras expects some amount of imperfection and can adjust the hardware (or maybe the software) to avoid those components after they're detected. https://www.cerebras.ai/blog/100x-defect-tolerance-how-cereb...

Re: GPT‑5.3‑Codex‑Spark

#125

Post by sailingparrot »

onlyrealcuzzo wrote: post #109
pjs_ wrote: post #66

Continue to believe that Cerebras is one of the most underrated companies of our time. It's a dinner-plate sized chip. It actually works. It's actually much faster than anything else for real workloads. Amazing

Nvidia seems cooked. Google is crushing them on inference. By TPUv9, they could be 4x more energy efficient and cheaper overall (even if Nvidia cuts their margins from 75% to 40%). Cerebras will be substantially better for agentic workflows in terms of speed. And if you don't care as much about speed and only cost and energy, Google will still crush Nvidia. And Nvidia won't be cheaper for training new models either.…

> let every part of the market slip away.

Which part of the market has slept away, exactly ? Everything you wrote is supposition and extrapolation. Nvidia has a chokehold on the entire market. All other players still exist in the small pockets that Nvidia doesn’t have enough production capacity to serve. And their dev ecosystem is still so far ahead of anyone else. Which providers gets chosen to equip a 100k chips data center goes so far beyond the raw chip power.

Re: GPT‑5.3‑Codex‑Spark

#126

Post by foobar10000 »

gaigalas wrote: post #37
capevace wrote: post #30

Seems like the industry is moving further towards having low-latency/high-speed models for direct interaction, and having slow, long thinking models for longer tasks / deeper thinking. Quick/Instant LLMs for human use (think UI). Slow, deep thinking LLMs for autonomous agents.

You always want faster feedback. If not a human leveraging the fast cycles, another automated system (eg CI). Slow, deep tasks are mostly for flashy one-shot demos that have little to no practical use in the real world.

I mean, yes, one always does want faster feedback - cannot argue with that!

But some of the longer stuff - automating kernel fusion, etc, are just hard problems. And a small model - or even most bigger ones, will not get the direction right…

Re: GPT‑5.3‑Codex‑Spark

#127

Post by speedgoose »

azinman2 wrote: post #79
arcanemachiner wrote: post #69

Earlier quoted context omitted.

Just wish they weren't so insanely expensive...

The bigger the chip, the worse the yield.

I suggest to read their website, they explain pretty well how they manage good yield. Though I’m not an expert in this field. I does make sense and I would be surprised if they were caught lying.

Re: GPT‑5.3‑Codex‑Spark

#129

Post by mnicky »

onlyrealcuzzo wrote: post #109
pjs_ wrote: post #66

Continue to believe that Cerebras is one of the most underrated companies of our time. It's a dinner-plate sized chip. It actually works. It's actually much faster than anything else for real workloads. Amazing

Nvidia seems cooked. Google is crushing them on inference. By TPUv9, they could be 4x more energy efficient and cheaper overall (even if Nvidia cuts their margins from 75% to 40%). Cerebras will be substantially better for agentic workflows in terms of speed. And if you don't care as much about speed and only cost and energy, Google will still crush Nvidia. And Nvidia won't be cheaper for training new models either.…

> What am I missing?

Largest production capacity maybe?

Also, market demand will be so high that every player's chips will be sold out.

Re: GPT‑5.3‑Codex‑Spark

#130

Post by Sohcahtoa82 »

moralestapia wrote: post #105
azinman2 wrote: post #79

Earlier quoted context omitted.

The bigger the chip, the worse the yield.

This comment doesn't make sense.

One wafer will turn into multiple chips.

Defects are best measured on a per-wafer basis, not per-chip. So if if your chips are huge and you can only put 4 chips on a wafer, 1 defect can cut your yield by 25%. If they're smaller and you fit 100 chips on a wafer, then 1 defect on the wafer is only cutting yield by 1%. Of course, there's more to this when you start reading about "binning", fusing off cores, etc.

There's plenty of information out there about how CPU manufacturing works, why defects happen, and how they're handled. Suffice to say, the comment makes perfect sense.

Post reply on HN