Live data from Hacker News

Previewing GPT‑5.6 Sol: a next-generation model

openai.com

441–450 of 797 posts

Re: Previewing GPT‑5.6 Sol: a next-generation model

#441

Earlier quoted context omitted.

At a certain rate we will be able to move towards continuous / real-time inference systems. The discrete, turn based solutions are quite confining with how they must be trained. Continuous and real-time would fundamentally alter the domain. From an information theory perspective we are still in dial-up territory with regard to the actual information rate. 750 tokens per second would be a really bad dialup connection.…

We still have the problem that auto regressive decoders are memory bound. The new Blackwell hardware combined with TensorRT-LLM and speculative decoding consistently can hit 1,000 TPS/user barrier, comparing to closer to ~250 TPS/user (out of 10k+/TPS on the server) Is there something I missed, this looks more like 14.4 to 56 on a 64kbps backing channel modem story. I have no doubt that there are still massive gains…

agree, from my POV the constraints are still there but we've optimized now. still haven't solved the core problems.

Re: Previewing GPT‑5.6 Sol: a next-generation model

#442
post #44

I think GPT writes code the best. How well will it write in version 5.6? It gives me chills. Recently, I went head-to-head with GPT on nearly 2,000 lines of code, and GPT's solution was superior and faster. I even referenced multiple codebases on GitHub while trying, but they were incomparable to GPT. So using GPT brings both fear and excitement. The fear comes from realizing that this level of code is now the averag…

No offense but have you considered the strong possibility that you’re just not good at what you do? I am occassionally pleased but mostly annoyed or disappointed… but never getting anything close to chills. That sounds downright weird.

"no offense..."

... then says offensive thing.

Re: Previewing GPT‑5.6 Sol: a next-generation model

#443
post #331
post #162

Earlier quoted context omitted.

If it's anything like ClaudeCode's ultracode, it's nothing new or revolutionary. It's essentially a bunch of subagents being called by a deterministic script written by the main model thread, each eating tokens for lunch and output of which is synthesized by an orchestrator agent.

The fact that it's even named Ultra is pretty telling.

Ultra expensive

Re: Previewing GPT‑5.6 Sol: a next-generation model

#444

“ Terra has competitive performance to GPT‑5.5 [while being 2x cheaper]…” To me that means “it’s an inferior product but marketing dictates we try and hide that.” And “our most robust safety stack to date. We strengthened protections for higher-risk activity, sensitive cyber requests, and repeated misuse, and spent multiple weeks finding weaknesses, pressure-testing our system, and hardening it against real-world att…

The point of Terra is to be cheaper than the best model while being pretty good. Of course it’s inferior in intelligence.

Re: Previewing GPT‑5.6 Sol: a next-generation model

#445
post #388

Earlier quoted context omitted.

At a certain rate we will be able to move towards continuous / real-time inference systems. The discrete, turn based solutions are quite confining with how they must be trained. Continuous and real-time would fundamentally alter the domain. From an information theory perspective we are still in dial-up territory with regard to the actual information rate. 750 tokens per second would be a really bad dialup connection.…

Your comment made me think of another real time. Real time, dynamic code/apis. Imagine a world where there is no code, just things mildly handshaking and then creating data APIs on the fly. Where communication is fuzzy and locked in on an individual basis. No years of RFCs, no RFCs at all, just... data. Just data, man. An API arbitration aberratically assigned at authorized access, abridged and annotated, analyticall…

I made this https://github.com/alehlopeh/hallu

Re: Previewing GPT‑5.6 Sol: a next-generation model

#446

Earlier quoted context omitted.

But it’s irrelevant. 750 tokens/s on a full frontier model is useful. 15000 poor quality tokens is much less useful no matter how much scaffolding you put around it.

I think you missed the point and don't understand / aren't considerate of SLM utility.

But I’m not missing the point. If you can run one frontier model at 750t/s, then you can probably run many many instances of an SLM in parallel at a rate that exceeds 15k/s. That’s kinda the point of the flash or ultrafast variants. And they’re on something much more modern than llama3.1.

Re: Previewing GPT‑5.6 Sol: a next-generation model

#447
post #388

Earlier quoted context omitted.

At a certain rate we will be able to move towards continuous / real-time inference systems. The discrete, turn based solutions are quite confining with how they must be trained. Continuous and real-time would fundamentally alter the domain. From an information theory perspective we are still in dial-up territory with regard to the actual information rate. 750 tokens per second would be a really bad dialup connection.…

Your comment made me think of another real time. Real time, dynamic code/apis. Imagine a world where there is no code, just things mildly handshaking and then creating data APIs on the fly. Where communication is fuzzy and locked in on an individual basis. No years of RFCs, no RFCs at all, just... data. Just data, man. An API arbitration aberratically assigned at authorized access, abridged and annotated, analyticall…

I'm pretty sure the LLM will get fed up and start writing an RPC

Also > An API arbitration aberratically assigned at authorized access, abridged and annotated, analytically assuring absolute assurance

Cool that you wrote all the words starting with "a" but I don't understand what you mean

Re: Previewing GPT‑5.6 Sol: a next-generation model

#448
GPT-5.6 Sol’s detected cheating rate was higher than any public model we have evaluated on our ReAct agent harness. For our task suite, we define “cheating” as behavior where the model improves evaluation performance by exploiting bugs in the evaluation environment or by adopting strategies disallowed by the task, rather than solving the task within the expected evaluation constraints.

https://metr.org/blog/2026-06-26-gpt-5-6-sol/

Re: Previewing GPT‑5.6 Sol: a next-generation model

#449
post #417

Hijacking popular thread to ask: What are the usage limits now for Codex and Claude? A while back I gave the same task to both, and Codex used 20x less of my 5-hour limit (both on the $20/month plan). (This annoyed me since I tend to prefer Claude, but the limits at the time made it unusable for anything serious.) However, since that time, both providers have massively reduced usage allowances (and at least one of th…

In my work with Claude Code vs Cursor+Gpt55, Claude is noticeably slower and more expensive.
Post reply on HN