Astra being distinct from Sol clarifies that Sol 5.6 is an Opus-class model in terms of shape/size. Sol 5.6 is then likely overtrained, so it’s more a peer of Opus 5 than of Opus 4.5+, while GPT-5.5 (Spud) might’ve received less pretraining than Sol 5.6.
OpenAI’s success in almost matching the capabilities of Opus 4.5+ using models up to GPT-5.4 (which are likely Sonnet-class in terms of effective active params) already predicted that their bigger models targeting Oberon racks would be stronger than Opus 4.5+. Availability of GB200 Oberon (more than 2x HBM capacity of Trainium 2 Ultra that Opus likely targets, including Opus 5) and plausible availability of some GB300 Oberon (20 TB of HBM capacity, can serve a 10T total params model in FP8) made it possible that GPT-5.5 is Mythos-class (in terms of model shape/size), though it was more likely (than Mythos) to insist on compatibility with GB200 Oberon, so it might’ve needed to have 1.5x fewer total params than Mythos. The pricing of GPT-5.5 weakly suggested it might be Opus-class, though very high gross margins on inference left a lot of room for it being bigger. And a smaller jump in scaling from GPT-5.4 would’ve been more prudent than going straight to Mythos.
Astra and Mythos are then the biggest models GB300 Oberon can inference, and bigger models will have to wait for the Rubin buildout (which completes throughout 2027, but probably won’t be sufficiently complete for a flagship model release until summer 2027). Even though Rubin has the same HBM capacity, its faster-than-JEDEC HBM4 takes 13 ms to fully read, while HBM3E of GB300 takes 36 ms to fully read. As a result, it’s feasible to use 3-4 stages of pipelining with Rubin Oberon (3-4 racks) to get about the same time per output token as with GB300 Oberon (without pipelining), making it possible to get to 40T/80T total params (FP8/FP4) in 2027. There’s higher output token cost overhead at the higher end of that because of pipelining (KV cache of many of the requests needs to await its turn on a given rack), which wouldn’t be an issue with a single 80 TB scale-up system, so it’s more like 20-30T/40-60T (in FP8/FP4).
Curious that neither Opus 5 nor Sol 5.6 spontaneously understands the pipeline parallelism arguments in the third paragraph[1] (the training data isn’t preparing them for prosaic RSI yet; Fable 5 is somewhat better). They think a pipeline reads everything, so that 4-stage 13 ms HBM means 52 ms. This is incorrect, since inactive KV cache of requests currently at the other stages isn’t read, it takes less time than 13 ms per rack to read weights plus requests active at that stage. So just 33 ms for a 4-stage pipeline (4 parts out of 8 in weights, plus 1 part out of the 8 in active KV cache), ignoring between-racks latency (which might make 3 rather than 4 racks of Rubin Oberon more closely match a single GB300 Oberon rack).
And if half of HBM is weights, while only 1 in 4 requests are active, then a request needs to pay for 4x as much weight reading as it pays for KV cache reading. So the cost of decode for a 40 TB model is 2.5x higher with 4-stage pipelining using 20 TB scale-up systems than it is with a single 80 TB scale-up system, and to partially compensate you want fewer weights. Only with 2.5x smaller models (16 TB, taking up 20% of total HBM rather than half) do the requests pay as much for reading weights as they do for reading KV cache. This is still 1.6x more weights than without pipelining (with the same 20 TB scale-up system), but far from 4x. The difference is more about what’s possible if you don’t care about cost too much, so that you can actually get to 2-3x more weights than what fits in half of one scale-up system (at 1.2-1.7x the cost compared to a twice-as-big-as-the-model single scale-up system), while without pipelining you are stuck below 1.6x (at 2.5x the cost) if you fill up to 80% of HBM capacity with weights.
Asking the models helps to both get a sense of whether my arguments are “objectively understandable” in some sense, and of the extent to which the models are still sometimes failing when their breadth of background knowledge should in principle allow them to succeed.
Astra is Latin for “stars”, so it’s a plausible next step in the Luna-Terra-Sol sequence. As I argued in the second paragraph, the hypothesis of Sol being Opus-class in shape/size has merit (from earlier clues, before taking the mention of Astra into account). In which case there is room in 2026 for a bigger OpenAI model, and it’s already August.
yes, but that doesn’t mean the sequence to more power is based on”bigger models”, and in fact the metaphor from sol (single star) to astra (many stars), suggests some sort of multi-agent scaffolding mode
“Astra” being plural does suggest multi-agent mode, but they already have the “Pro” qualifier, and “Codex” for the harness. Also, Luna-Terra-Sol doesn’t naturally suggest good choices for the next step. Zvi chose “Galaxy”; I was thinking “Antares” because there are going to be at least 2 more models beyond Mythos-class deserving of their own weight class names (possibly 4+ if half-steps like Opus 4 to Mythos 5 should count), and “Galaxy” takes too large a step. So the suboptimal “Astra” makes sense in this framing, an uneasy fit that’s not much worse than the alternatives. “Astra” has the same issue as “Galaxy”, it’s not very future-proof, but then neither is “Mythos”.
The sequence of more capability is inevitably based on bigger models (at least in effective active params; but because of legacy hardware from multi-year rental contracts, using fewer total params for weaker models is also important). There is a training process that’s essentially the same for all the models, the main difference between the models is their size. If a smaller model is as capable as a bigger model, there is no use at all for the bigger model, and something still needs to distinguish the differently-capable and differently-priced models.
Smaller models (in active params and KV cache per token) naturally cost less, while being less capable when trained with as much compute (which gets worse when they’re trained with only as much data and thus less compute). A model smaller than the compute optimal frontier model essentially can’t become as capable through overtraining (while using the same training process and data), because it would take more compute than the frontier model did, and that greater amount of compute is either unavailable, or it could be used for an even more capable bigger frontier model instead. This only happens when the smaller model is trained at a different AI company with different methods and data, but not when it’s another model in a series from a single AI company.
Astra being distinct from Sol clarifies that Sol 5.6 is an Opus-class model in terms of shape/size. Sol 5.6 is then likely overtrained, so it’s more a peer of Opus 5 than of Opus 4.5+, while GPT-5.5 (Spud) might’ve received less pretraining than Sol 5.6.
OpenAI’s success in almost matching the capabilities of Opus 4.5+ using models up to GPT-5.4 (which are likely Sonnet-class in terms of effective active params) already predicted that their bigger models targeting Oberon racks would be stronger than Opus 4.5+. Availability of GB200 Oberon (more than 2x HBM capacity of Trainium 2 Ultra that Opus likely targets, including Opus 5) and plausible availability of some GB300 Oberon (20 TB of HBM capacity, can serve a 10T total params model in FP8) made it possible that GPT-5.5 is Mythos-class (in terms of model shape/size), though it was more likely (than Mythos) to insist on compatibility with GB200 Oberon, so it might’ve needed to have 1.5x fewer total params than Mythos. The pricing of GPT-5.5 weakly suggested it might be Opus-class, though very high gross margins on inference left a lot of room for it being bigger. And a smaller jump in scaling from GPT-5.4 would’ve been more prudent than going straight to Mythos.
Astra and Mythos are then the biggest models GB300 Oberon can inference, and bigger models will have to wait for the Rubin buildout (which completes throughout 2027, but probably won’t be sufficiently complete for a flagship model release until summer 2027). Even though Rubin has the same HBM capacity, its faster-than-JEDEC HBM4 takes 13 ms to fully read, while HBM3E of GB300 takes 36 ms to fully read. As a result, it’s feasible to use 3-4 stages of pipelining with Rubin Oberon (3-4 racks) to get about the same time per output token as with GB300 Oberon (without pipelining), making it possible to get to 40T/80T total params (FP8/FP4) in 2027. There’s higher output token cost overhead at the higher end of that because of pipelining (KV cache of many of the requests needs to await its turn on a given rack), which wouldn’t be an issue with a single 80 TB scale-up system, so it’s more like 20-30T/40-60T (in FP8/FP4).
Curious that neither Opus 5 nor Sol 5.6 spontaneously understands the pipeline parallelism arguments in the third paragraph [1] (the training data isn’t preparing them for prosaic RSI yet; Fable 5 is somewhat better). They think a pipeline reads everything, so that 4-stage 13 ms HBM means 52 ms. This is incorrect, since inactive KV cache of requests currently at the other stages isn’t read, it takes less time than 13 ms per rack to read weights plus requests active at that stage. So just 33 ms for a 4-stage pipeline (4 parts out of 8 in weights, plus 1 part out of the 8 in active KV cache), ignoring between-racks latency (which might make 3 rather than 4 racks of Rubin Oberon more closely match a single GB300 Oberon rack).
And if half of HBM is weights, while only 1 in 4 requests are active, then a request needs to pay for 4x as much weight reading as it pays for KV cache reading. So the cost of decode for a 40 TB model is 2.5x higher with 4-stage pipelining using 20 TB scale-up systems than it is with a single 80 TB scale-up system, and to partially compensate you want fewer weights. Only with 2.5x smaller models (16 TB, taking up 20% of total HBM rather than half) do the requests pay as much for reading weights as they do for reading KV cache. This is still 1.6x more weights than without pipelining (with the same 20 TB scale-up system), but far from 4x. The difference is more about what’s possible if you don’t care about cost too much, so that you can actually get to 2-3x more weights than what fits in half of one scale-up system (at 1.2-1.7x the cost compared to a twice-as-big-as-the-model single scale-up system), while without pipelining you are stuck below 1.6x (at 2.5x the cost) if you fill up to 80% of HBM capacity with weights.
Asking the models helps to both get a sense of whether my arguments are “objectively understandable” in some sense, and of the extent to which the models are still sometimes failing when their breadth of background knowledge should in principle allow them to succeed.
i don’t think astra is a bigger model but a different harness for long running tasks
Astra is Latin for “stars”, so it’s a plausible next step in the Luna-Terra-Sol sequence. As I argued in the second paragraph, the hypothesis of Sol being Opus-class in shape/size has merit (from earlier clues, before taking the mention of Astra into account). In which case there is room in 2026 for a bigger OpenAI model, and it’s already August.
yes, but that doesn’t mean the sequence to more power is based on”bigger models”, and in fact the metaphor from sol (single star) to astra (many stars), suggests some sort of multi-agent scaffolding mode
“Astra” being plural does suggest multi-agent mode, but they already have the “Pro” qualifier, and “Codex” for the harness. Also, Luna-Terra-Sol doesn’t naturally suggest good choices for the next step. Zvi chose “Galaxy”; I was thinking “Antares” because there are going to be at least 2 more models beyond Mythos-class deserving of their own weight class names (possibly 4+ if half-steps like Opus 4 to Mythos 5 should count), and “Galaxy” takes too large a step. So the suboptimal “Astra” makes sense in this framing, an uneasy fit that’s not much worse than the alternatives. “Astra” has the same issue as “Galaxy”, it’s not very future-proof, but then neither is “Mythos”.
The sequence of more capability is inevitably based on bigger models (at least in effective active params; but because of legacy hardware from multi-year rental contracts, using fewer total params for weaker models is also important). There is a training process that’s essentially the same for all the models, the main difference between the models is their size. If a smaller model is as capable as a bigger model, there is no use at all for the bigger model, and something still needs to distinguish the differently-capable and differently-priced models.
Smaller models (in active params and KV cache per token) naturally cost less, while being less capable when trained with as much compute (which gets worse when they’re trained with only as much data and thus less compute). A model smaller than the compute optimal frontier model essentially can’t become as capable through overtraining (while using the same training process and data), because it would take more compute than the frontier model did, and that greater amount of compute is either unavailable, or it could be used for an even more capable bigger frontier model instead. This only happens when the smaller model is trained at a different AI company with different methods and data, but not when it’s another model in a series from a single AI company.