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

GPT-5.4

openai.com

Post reply on HN
Print view View original

321–330 of 868 posts

Re: GPT-5.4

#321

Post by netinstructions »

Flashtoo wrote: post #260
netinstructions wrote: post #207

Earlier quoted context omitted.

People (and also frustratingly LLMs) usually refer to https://openai.com/api/pricing/ which doesn't give the complete picture. https://developers.openai.com/api/docs/pricing is what I always reference, and it explicitly shows that pricing ($2.50/M input, $15/M output) for tokens under 272k It is nice that we get 70-72k more tokens before the price goes up (also what does it cost beyond 272k tokens??)

> Prompts with more than 272K input tokens are priced at 2x input and 1.5x output for the full session for standard, batch, and flex.

Thanks, it looks like the pricing page keeps getting updated.

Even right now one page refers to prices for "context lengths under 270K" whereas another has pricing for "<272K context length"

Re: GPT-5.4

#322

Post by adwn »

steve1977 wrote: post #42
mattas wrote: post #5

"GPT‑5.4 interprets screenshots of a browser interface and interacts with UI elements through coordinate-based clicking to send emails and schedule a calendar event." They show an example of 5.4 clicking around in Gmail to send an email. I still think this is the wrong interface to be interacting with the internet. Why not use Gmail APIs? No need to do any screenshot interpretation or coordinate-based clicking.

One could argue that LLMs learning programming languages made for humans (i.e. most of them) is using the wrong interface as well. Why not use machine code?

> One could argue that LLMs learning programming languages made for humans (i.e. most of them) is using the wrong interface as well.

Then go ahead and make an argument. "Why not do X?" is not an argument, it's a suggestion.

Re: GPT-5.4

#325

Post by gallerdude »

kgeist wrote: post #317

>Today, we’re releasing GPT‑5.3 Instant >Today, we’re releasing GPT‑5.4 in ChatGPT (as GPT‑5.4 Thinking), >Note that there is not a model named GPT‑5.3 Thinking They held out for eight months without a confusing numbering scheme :)

Tbf there was a 5.3 codex

Re: GPT-5.4

#326

Post by Someone1234 »

Folcon wrote: post #284
thyb23 wrote: post #269

Earlier quoted context omitted.

This is exactly how it should work. I imagine it as a tree view showing both full and summarized token counts at each level, so you can immediately see what’s taking up space and what you’d gain by compacting it. The agent could pre-select what it thinks is worth keeping, but you’d still have full control to override it. Each chunk could have three states: drop it, keep a summarized version, or keep the full history.…

I do find it really interesting that more coding agents don't have this as an toggleable feature, sometimes you really need this level of control to get useful capability

Yep; I've actually had entire jobs essentially fail due to a bad compaction. It lost key context, and it completely altered the trajectory.

I'm now more careful, using tracking files to try to keep it aligned, but more control over compaction regardless would be highly welcomed. You don't ALWAYS need that level of control, but when you do, you do.

Re: GPT-5.4

#327

Post by the_af »

Sharlin wrote: post #261
mikkupikku wrote: post #161

Earlier quoted context omitted.

My computer ethics teacher was obsessed with 'teledildonics' 30 years ago. There's nothing new under the sun.

There are many games these days that support controllable sex toys. There's an interface for that, of course: https://github.com/buttplugio/buttplug . Written in Rust, of course.

> Written in Rust, of course.

Safety is important.

Re: GPT-5.4

#328

Post by hu3 »

gavinray wrote: post #84

The "RPG Game" example on the blogpost is one of the most impressive demo's of autonomous engineering I've seen. It's very similar to "Battle Brothers", and the fact that RPG games require art assets, AI for enemy moves, and a host of other logical systems makes it all the more impressive.

indeed and I suspect it can be attributed to, at least in part, the improved playwright integration.

> we’re also releasing an experimental Codex skill called “Playwright (Interactive) (opens in a new window)”. This allows Codex to visually debug web and Electron apps; it can even be used to test an app it’s building, as it’s building it.

Re: GPT-5.4

#329

Post by itintheory »

kristianp wrote: post #270
mattas wrote: post #5

"GPT‑5.4 interprets screenshots of a browser interface and interacts with UI elements through coordinate-based clicking to send emails and schedule a calendar event." They show an example of 5.4 clicking around in Gmail to send an email. I still think this is the wrong interface to be interacting with the internet. Why not use Gmail APIs? No need to do any screenshot interpretation or coordinate-based clicking.

This opens up a new question: how does bot detection work when the bot is using the computer via a gui?

On it's face, I'm not sure that's a new question. Bots using browser automation frameworks (puppeteer, selenium, playwright etc) have been around for a while. There are signals used in bot detection tools like cursor movement speed, accuracy, keyboard timing, etc. How those detection tools might update to support legitimate bot users does seem like an open question to me though.

Re: GPT-5.4

#330

Post by nowittyusername »

tedsanders wrote: post #59
minimaxir wrote: post #8

The marquee feature is obviously the 1M context window, compared to the ~200k other models support with maybe an extra cost for generations beyond >200k tokens. Per the pricing page, there is no additional cost for tokens beyond 200k: https://openai.com/api/pricing/ Also per pricing, GPT-5.4 ($2.50/M input, $15/M output) is much cheaper than Opus 4.6 ($5/M input, $25/M output) and Opus has a penalty for its beta >200…

Yeah, long context vs compaction is always an interesting tradeoff. More information isn't always better for LLMs, as each token adds distraction, cost, and latency. There's no single optimum for all use cases. For Codex, we're making 1M context experimentally available, but we're not making it the default experience for everyone, as from our testing we think that shorter context plus compaction works best for most p…

Personally what I am more interested about is effective context window. I find that when using codex 5.2 high, I preferred to start compaction at around 50% of the context window because I noticed degradation at around that point. Though as of a bout a month ago that point is now below that which is great. Anyways, I feel that I will not be using that 1 million context at all in 5.4 but if the effective window is something like 400k context, that by itself is already a huge win. That means longer sessions before compaction and the agent can keep working on complex stuff for longer. But then there is the issue of intelligence of 5.4. If its as good as 5.2 high I am a happy camper, I found 5.3 anything... lacking personally.
Post reply on HN