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

31–40 of 415 posts

Re: GPT‑5.3‑Codex‑Spark

#31

Post by behnamoh »

properbrew wrote: post #24
behnamoh wrote: post #4

In my opinion, they solved the wrong problem. The main issue I have with Codex is that the best model is insanely slow, except at nights and weekends when Silicon Valley goes to bed. I don't want a faster, smaller model (already have that with GLM and MiniMax). I want a faster, better model (at least as fast as Opus). When they partnered with Cerebras, I kind of had a gut feeling that they wouldn't be able to use the…

I was using a custom skill to spawn subagents, but it looks like the `/experimental` feature in codex-cli has the SubAgent setting ( https://github.com/openai/codex/issues/2604#issuecomment-387... )

Yes, I was using that. But the prompt given to the agents is not correct. Codex sends a prompt to the first agent and then sends the second prompt to the second agent, but then in the second prompt, it references the first prompt. which is completely incorrect.

Re: GPT‑5.3‑Codex‑Spark

#32

Post by kachapopopow »

behnamoh wrote: post #4

In my opinion, they solved the wrong problem. The main issue I have with Codex is that the best model is insanely slow, except at nights and weekends when Silicon Valley goes to bed. I don't want a faster, smaller model (already have that with GLM and MiniMax). I want a faster, better model (at least as fast as Opus). When they partnered with Cerebras, I kind of had a gut feeling that they wouldn't be able to use the…

That's why I built oh-my-singularity (based on oh-my-pi - see the front page from can.ac): https://share.us-east-1.gotservers.com/v/EAqb7_Wt/cAlknb6xz0...

video is pretty outdated now, this was a PoC - working on a dependency free version.

Re: GPT‑5.3‑Codex‑Spark

#33

Post by zozbot234 »

jryio wrote: post #10

This is interesting for offloading "tiered" workloads / priority queue with coding agents. If 60% of the work is "edit this file with this content", or "refactor according to this abstraction" then low latency - high token inference seems like a needed improvement. Recently someone made a Claude plugin to offload low-priority work to the Anthropic Batch API [1]. Also I expect both Nvidia and Google to deploy custom s…

Note that Batch APIs are significantly higher latency than normal AI agent use. They're mostly intended for bulk work where time constraints are not essential. Also, GPT "Codex" models (and most of the "Pro" models also) are currently not available under OpenAI's own batch API. So you would have to use non-agentic models for these tasks and it's not clear how well they would cope.

(Overall, batches do have quite a bit of potential for agentic work as-is but you have to cope with them taking potentially up to 24h for just a single roundtrip with your local agent harness.)

Re: GPT‑5.3‑Codex‑Spark

#34

Post by XCSme »

nikkwong wrote: post #29

> Our latest frontier models have shown particular strengths in their ability to do long-running tasks, working autonomously for hours, days or weeks without intervention. I have yet to see this (produce anything actually useful).

Their ability to burn through tokens non-stop for hours, days or weeks without intervention.

Re: GPT‑5.3‑Codex‑Spark

#35

Post by jusgu »

antirez wrote: post #20

The search for speed is vain. Often Claude Code Opus 4.6, on hard enough problems, can do the impression of acting fast without really making progresses because of lack of focus on what matters. Then you spin the much slower GPT 5.3-Codex and it fixes everything in 3 minutes of doing the right thing.

disagree. while intelligence is important, speed is especially important when productionizing AI. it’s difficult to formalize the increase in user experience per increase in TPS but it most definitely exists.

Re: GPT‑5.3‑Codex‑Spark

#36

Post by varispeed »

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.

Are they really thinking or are they sprinkling them with Sleep(x)?

Re: GPT‑5.3‑Codex‑Spark

#37

Post by gaigalas »

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.

Re: GPT‑5.3‑Codex‑Spark

#38

Post by gamegoblin »

nikkwong wrote: post #29

> Our latest frontier models have shown particular strengths in their ability to do long-running tasks, working autonomously for hours, days or weeks without intervention. I have yet to see this (produce anything actually useful).

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

Re: GPT‑5.3‑Codex‑Spark

#39

Post by wxw »

Great stuff. People are getting used to agents as the interface for everything, even work as simple as "change label X to label Y". More speed on that front is welcome. The Codex "blended mode" they refer to will be useful (similar to Claude Code bouncing between haiku and opus).

I imagine it's a win-win. This could significantly help their tokenomics.

The example showing a plan being generated instantaneously is interesting. Human understanding will end up as the last, true bottleneck.

Post reply on HN