[flagged]
Advancing the price-performance frontier with GPT‑5.6
401–410 of 424 posts
Re: Advancing the price-performance frontier with GPT‑5.6
#402Earlier quoted context omitted.
> When model intelligence reliably hits 90%-95% of current day knowledge worker tasks, they are going to burn those weight to silicon Google is already working on a similar idea but more "flexible".
Explain.
Google Frozen v2 chips hardwires the underlying architecture but leaves the weights to be configurable.
Re: Advancing the price-performance frontier with GPT‑5.6
#403All the AI Mambo jumbo and still the Y axis is written from down to top. I hate that.
Re: Advancing the price-performance frontier with GPT‑5.6
#404Earlier quoted context omitted.
Burning the weights into silicon would be many orders of magnitude increase, not just 10x. It's kind of crazy that this hockey stick the AI hype bros talk about seems more and more every day like it might be real
https://taalas.com/ has done it already for a wildly obsolete model. 14000 tokens per second. https://chatjimmy.ai/ is their interactive. Tiny context, very dumb, but absurdly fast. Imagine this as a tool call for claude code for trivial changes - the tool call from the harness takes longer than the execution.
Wow! Responded essentially instantaneously to my prompt:
"I need a short, 4000 word essay on the the difference between star wars and Star Trek universes from the perspective of graduate level scientific work."
Re: Advancing the price-performance frontier with GPT‑5.6
#405"Half the money I spend on advertising is wasted; the trouble is I don't know which half." -John Wanamaker This applies even more strongly to model choosing. I know for a fact that majority of my work doesn't require a very strong model, but separating the trivial and non-trivial tasks is a famously hard problem (if at all decidable).
I get frustrated with a poor quality model leaving my codebase littered with wrong comments, which then later trip up smarter models.
I find you gotta do a smart model sandwich. Write plans with smart models, implement with cheaper models, review its work with smarter models. Catches a lot of mistakes before they propagate.
Re: Advancing the price-performance frontier with GPT‑5.6
#406let's not forget the forest for the trees. the new pricing is more aligned with their previous generation of similar models.
case in point 5.4-nano, which is the only model of its class which is now finally comparable to 5.6-luna in pricing. [1] until this change, workflows using the older model could not economically justify the old luna pricing.
the doubling in price between 5.4 and 5.5 also did not help with things, but now 5.6-terra can be considered an update for this pricing tier.
if the token efficiency is real (which i am yet to replicate for our workflows), then the switch to these models can be a net benefit. thank you chinese labs!
[1] https://developers.openai.com/api/docs/pricing#text-tokens
Re: Advancing the price-performance frontier with GPT‑5.6
#407Earlier quoted context omitted.
How will this affect the newly build data centers? What effect do you think it will have on memory prices?
My uneducated guess says, not much. For running massive models you still need a ton of high-bandwidth interconnects between many individual chips/GPUs/etc since you need to do math across a few TB worth of weights. That's simply going to require more power (and more die area in I/O, and therefore more cost). Being able to run small models in tiny power envelopes is incredibly useful to people, but I believe it will b…
Thank you for such detailed answer!
Re: Advancing the price-performance frontier with GPT‑5.6
#408might as well rethink about their pricing on gpt-realtime. for a quick test, spoke to that model for ~5 minutes, ended up spending near $1.
They haven’t launched the new realtime in api yet
Re: Advancing the price-performance frontier with GPT‑5.6
#409Earlier quoted context omitted.
Using Sol or Fable for implementing is like having your Principal Staff Engineer with 30 year tenure routinely write CRUD functions for a REST API. You use the big models to plan. Not just the overall plan, but which files need to be edited etc. Then they give that to the lower end model. So Luna or Sonnet, which are perfectly capable of following instructions and still creative enough to not get stuck.
> Using Sol or Fable for implementing is like having your Principal Staff Engineer with 30 year tenure routinely write CRUD functions for a REST API. A Principal Staff Engineer who costs $2400 a year and never feels any work is beneath them? Hell yeah. OK OK, usage limits
If you have bcherny levels of token quotas, you can use Fable for everything =)
The rest of us need to optimise a bit.
Re: Advancing the price-performance frontier with GPT‑5.6
#410Earlier quoted context omitted.
Some numbers: https://www.wheresyoured.at/exclusive-openai-financials/ If those numbers are accurate, I don't think 20% is a really, really big deal. It's like saying "we're digging our grave 20% slower." Ok, but they're still digging! Or, different analogy, if I'm going broke because I lost my job due to executive AI psychosis, cancelling my netflix subscription doesn't really change the math of not being able to af…
Those finanicals show OpenAI makes good money on inference.
You might need to reread that mate.