When I saw Spark my mind went to Apache Spark and wondered if we were learning all the lessons in orchestration of driver/worker and data shuffling from that space.
GPT‑5.3‑Codex‑Spark
21–30 of 415 posts
Re: GPT‑5.3‑Codex‑Spark
#22The 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.
I disagree. This is great for bulk tasks: renaming, finding and searching for things, etc
Re: GPT‑5.3‑Codex‑Spark
#23Wasn't aware there was an effort to move to websockets. Is there any standards work for this, or is this just happening purely within the walled OpenAI garden?
> Under the hood, we streamlined how responses stream from client to server and back, rewrote key pieces of our inference stack, and reworked how sessions are initialized so that the first visible token appears sooner and Codex stays responsive as you iterate. Through the introduction of a persistent WebSocket connection and targeted optimizations inside of Responses API, we reduced overhead per client/server roundtrip by 80%, per-token overhead by 30%, and time-to-first-token by 50%. The WebSocket path is enabled for Codex-Spark by default and will become the default for all models soon.
Re: GPT‑5.3‑Codex‑Spark
#24In 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...)
Re: GPT‑5.3‑Codex‑Spark
#25This 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…
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?
Re: GPT‑5.3‑Codex‑Spark
#26Is this the first time one of the big 3 using Cerebras? I've been waiting for this day...
Re: GPT‑5.3‑Codex‑Spark
#27Anyway token eaters are upgrading their consumption capabilities.
Re: GPT‑5.3‑Codex‑Spark
#28Is this the first time one of the big 3 using Cerebras? I've been waiting for this day...
They were afraid for the untested tech but it looks like a leap in speed now
Re: GPT‑5.3‑Codex‑Spark
#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).
Re: GPT‑5.3‑Codex‑Spark
#30Seems 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.