Live data from Hacker News

GPT‑5.3‑Codex‑Spark

openai.com

131–140 of 415 posts

Re: GPT‑5.3‑Codex‑Spark

#131

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.

You can just do dynamic binning.

Re: GPT‑5.3‑Codex‑Spark

#132

Earlier quoted context omitted.

It worked for me several times. It's easy to say that these increasingly popular tools are only able to produce useless junk. You haven't tried, or you haven't "closed the loop" so that the agent can evaluate its own progress toward acceptance criteria, or you are monitoring incompetent feeds of other users.

I'm definitely bullish on LLM's for coding. It sounds to me as though getting it to run on its own for hours and produce something usable requires more careful thought and setup than just throwing a prompt at it and wishing for the best—but I haven't seen many examples in the wild yet

well, you can start with https://github.com/rcarmo/go-textile, https://github.com/rcarmo/go-rdp, https://github.com/rcarmo/go-ooxml, https://github.com/rcarmo/go-busybox (still WIP). All of these are essentially SPEC and test-driven and they are all working for me (save a couple of bugs in go-rdp I need to fix myself, and some gaps in the ECMA specs for go-ooxml that require me to provide actual manually created documents for further testing).

I am currently porting pyte to Go through a similar approach (feeding the LLM with a core SPEC and two VT100/VT220 test suites). It's chugging along quite nicely.

Re: GPT‑5.3‑Codex‑Spark

#133

First thoughts using gpt-5.3-codex-spark in Codex CLI: Blazing fast but it definitely has a small model feel. It's tearing up bluey bench (my personal agent speed benchmark), which is a file system benchmark where I have the agent generate transcripts for untitled episodes of a season of bluey, perform a web search to find the episode descriptions, and then match the transcripts against the descriptions to generate f…

I wonder why they named it so similiarly to the normal codex model while it much worse, while cool of course.

Re: GPT‑5.3‑Codex‑Spark

#134
post #68

Earlier quoted context omitted.

Models haven't been trained enough on using skills yet, so they typically ignore them

Is that true? I had tool use working with GPT-4 in 2023, before function calling or structured outputs were even a thing. My tool instructions were only half a page though. Maybe the long prompts are causing problems?

They're talking about "skills" which are not the same thing as tools. Most models haven't been trained on the open SKILL spec, and therefore aren't tuned to invoke them reliable when the need occurs.

Re: GPT‑5.3‑Codex‑Spark

#135
post #62

Earlier quoted context omitted.

In my AGENTS.md file i have a _rule_ that tells the model to use Apache ECharts, the data comes from the prompt and normally .csv/.json files. Prompt would be like: "After slide 3 add a new content slide that shows a bar chart with data from @data/somefile.csv" ... works great and these charts can be even interactive.

What about other ad hoc diagrams like systems architecture, roadmaps, mind maps, etc. These are the bane of any staff engineers life - lol. Because people above need to know a plan in art form. So seriously interested on how I can make it easier

You could try something like mermaid (or ASCII) -> nano banana. You can also go the other way and turn images into embedded diagrams (which can be interactive depending on how you're sharing the presentation)

Re: GPT‑5.3‑Codex‑Spark

#136

First thoughts using gpt-5.3-codex-spark in Codex CLI: Blazing fast but it definitely has a small model feel. It's tearing up bluey bench (my personal agent speed benchmark), which is a file system benchmark where I have the agent generate transcripts for untitled episodes of a season of bluey, perform a web search to find the episode descriptions, and then match the transcripts against the descriptions to generate f…

Can you compare it to Opus 4.6 with thinking disabled? It seems to have very impressive benchmark scores. Could also be pretty fast.

Re: GPT‑5.3‑Codex‑Spark

#137

Earlier quoted context omitted.

I built something similar using an MCP that allows claude to "outsource" development to GLM 4.7 on Cerebras (or a different model, but GLM is what I use). The tool allows Claude to set the system prompt, instructions, specify the output file to write to and crucially allows it to list which additional files (or subsections of files) should be included as context for the prompt. Ive had great success with it, and it r…

Why use MCP instead of an agent skill for something like this when MCP is typically context inefficient?

MCP is fine if your tool definition is small. If it's something like a sub-agent harness which is used very often, then in fact it's probably more context efficient because the tools are already loaded in context and the model doesn't have to spend a few turns deciding to load the skill, thinking about it and then invoking another tool/script to invoke the subagent.

Re: GPT‑5.3‑Codex‑Spark

#139
post #89

Earlier quoted context omitted.

The real question is what’s their perf/dollar vs nvidia?

I guess it depends what you mean by "perf". If you optimize everything for the absolutely lowest latency given your power budget, your throughput is going to suck - and vice versa. Throughput is ultimately what matters when everything about AI is so clearly power-constrained, latency is a distraction. So TPU-like custom chips are likely the better choice.

> Throughput is ultimately what matters

I disagree. Yes it does matter, but because the popular interface is via chat, streaming the results of inference feels better to the squishy messy gross human operating the chat, even if it ends up taking longer. You can give all the benchmark results you want, humans aren't robots. They aren't data driven, they have feelings, and they're going to go with what feels better. That isn't true for all uses, but time to first byte is ridiculously important for human-computer interaction.

Post reply on HN