I understand how it can be confusing, but I don't think that this is exactly a problem.

Luna through Astra offer qualitative descriptions of the model's size. Presumably OpenAI trains its biggest model (Astra-ish, maybe even larger) first, then distills it to smaller sizes.

Verison numbers reflect something about the architecture or training dataset. Again, they keep these details close to their chest, but we should expect that weight-for-weight higher versions should beat lower versions.

This offers us two axes of 'better', but these axes are also not directly comparable. An earlier but bigger model may or may not beat a newer but smaller model. This is where 'spiky' intelligence comes in.

This is also where calls to 'run your own evaluation' really do start to matter. If you care enough about this performance[1], then you also have specific problems that you care about. No generic benchmark can fully answer that question, hence the need for a specific evaluation.

[1] — And you don't have to! A casual user is probably served reasonably well by anything put out in the past six months. I think Microsoft is still serving GPT-4o under some Copilot branding.

Lots of code "typos" aren't immediately syntactic errors. Misbalanced parentheses, for example, only bite when one needs to close the series. The solution is to go back and fix the original error, but that option is foreclosed to autoregressive LLMs. In the meantime, forcing the model off what it "wants" to generate might make the remaining syntactically valid tokens semantically meaningless, impairing future generation in a way that's hard to quntify.

Constrained generation for tool calls is certainly a type of syntax checking, but it's one that can be justified because the "hard" syntax choices come up front, both in the very format of the tool call itself to the name of the tool and its parameters. Errors are more likely to be detected in the same root-cause tokens that generate them.

Define 'bind', please.

If my neighbourhood elects representatives who decide that we should all have black trash bins, then how am I 'bound to abide by their decision' if I want to put out a green bin instead?

The problem is moot if the decision is unanimous, since a unanimous decision has no dissent by definition. It comes back with any rule from authority, even if that authority is republican in nature. Note that I said coercion, which is broader than a simple threat of violence; shame and shunning are some of the oldest coercive tactics in the book.

Majoritarian government is great because it offers an easy path to legitimacy, overcoming the 'who died and made you leader?' problem. However, my argument speaks to the leader part of that question, not the you part.

You don't strictly need a mandate from the people; authoritarian governments can be legitimate despite not having such a mandate. However, it's an impossible trilemma: successful action needs at least one of unanimity (parent commenter's approach), threat of coercion (government), or tolerance of free-riding (charity).

I use a similar process for a local agent swarm approach (locally hosted Qwen-3.8-27b or Qwen-Flash-Next), used so far for personal-grade projects. Through tool and process accretion, the review stages are told to check both the work and reasoning of the implementation stage, via processing the pi.dev session log.

Through parsing the jsonl log, the reviewer sees the subagent prompt, the tool call sequence, and non-thinking narration along the way. That allows the reviewr to audit the implementer's process (e.g. were tests run?) and spot procedure violations or gross hallucinations. The reviewer also independently runs the test suite, so even a hallucinated pass is caught.

It's relatively expensive both in tokens and time spent running ideally duplicate tests, but the independent workflow has nonetheless caught errors that would very likely have been missed by a same session, same context review.

Would even an intentional lie act to to reset the limitation period here? The hypothetical lie wasn't a deep secret exposed by some whistleblower, it came to light by... reading the vesting agreement. Since AFAIK limitation periods run from "know or ought to have known," I can't see a viable construction to keep the dispute live after 30 years.

Since litigation is costly, the acceptable range for a settlement is centered around the expected outcome of a trial, plus or minus each party's cost of litigation (including opportunity cost).

In this case, "the claim is barred by the statute of limitations" implies that the expected outcome of litigation would be approximately $0. The net range for a settlement is then the 'nuisance value' of a lawsuit including any PR damage for airing the case publicly; that would be orders of magnitude below the $1bn claim.

I think that argument is recursive? These posts aren't very complicated for either of us, but they're written on devices that are fabricated with billions of dollars of semiconductor equipment. At what point do we just acknowledge that we stand on the shoulders of giants?

To me, the distinguishing factor is that the expense not special-purpose but upfront. The model here is trained without foreknowledge of what problems it will solve. Solutions like nine loops are genuine expressions of a pre-existing model capability, even if that capability has not pre-existed for very long.

[1] — If I remember correctly, there even was some special-case code for ship pursuit cycles.

In a high-level view, it's the result of specialized decoding heads.

Traditionally one would take gridded forecast outputs, then process those with comprehensible actions like "find all local pressure minima in the ocean, then filter to ones which correspond to warm cores, etc." to infer (diagnose) the presence of a cyclone.

One problem with this is that gridded forecasts suffer from known biases and tradeoffs. For example, a forecast on a ~25km grid is just on the edge of being able to represent the eye of a hurricane (50km scales), and it certainly can't accurately represent the sharp transition of wind in the eyewall. That means that the forecast winds are almost certainly a smoothed (and therefore less intense) version of what observers would see.

The WN2 approach (paper: https://www.nature.com/articles/s41586-026-10953-2) adds a direct readout head to the model: given latent-space access to the full forecast, it tries to predict the bona-fide cyclone observations (https://www.ncei.noaa.gov/products/international-best-track-...).

It's kind of like a post-processing or bias correction (see for example https://www.ecmwf.int/en/about/media-centre/aifs-blog/2026/a..., which applies in physical space), but by having access to the model latent space and by being included in model training it is (probably!) higher-quality than a pure, after-the-fact approach.

'Nowcasting' is an area of active research, both with machine learning and with physics-informed or visual flow approaches.

Part of the problem from the machine learning side is that these are _huge_ problems. NVidia's StormCast (https://research.nvidia.com/publication/2024-08_kilometer-sc...) works globally at kilometer scales, and you can imagine how big those grids are. Even with patch training, you're dealing with very large datasets.

At the same time, this is not exactly a high-profile area of research. National weather centres focus on actionable medium-range weather predictions, and meteorologists can look at radar themselves and perform mark-one-eyeball predictions for very short-range watches and warnings. Some private-sector actors will pay for short range predictions, but they're often looking for something hyperlocalized (e.g. weather at this particular construction site, for crane safety) or specialized (near-real-time cloud and wind predictions for renewable energy).

Most public-accessible weather predictions are downstream of either a public-sector effort (which doesn't internalize benefits, leading to under-resourcing) or a byproduct of another private-sector offering.

The data that would be most valuable to initial conditions is upper-atmosphere winds -- this is the kind of data given by weather balloons. In clear air there's no great way to measure this from either the ground or from space.

One important supplemental data source here are aviation reports, from planes flying at altitude and particularly trans-oceanic routes. When air traffic was largely curtailed during the early phase of the Covid pandemic, weather forecasting suffered a bit for the lack of data (see eg https://www.ecmwf.int/en/about/media-centre/news/2020/drop-a...).

No, for any particular output token the model's true logits are definitionally the 'best' that the model can achieve.

This is inherently probabilistic. The model's top-1 guess is not guaranteed to be optimal, but it should be so a proportionate fraction of the time. Same with the top-2, top-3, etc.

Watermarking necessarily alters the output distribution away from the model-set distribution, and that alteration is inherently 'worse' in expectation.

You can liken this to a weather forecast. If there's a 25% chance of rain, the forecast should say so (or a 'sampled' deterministic forecast should predict rain 25% of the time). If the forecast is 'watermarked' and predicts rain 27% of the time under identical circumstances, it's a worse forecast.

That being said, this is a case of hiding a message in a noisy channel. Watermarking only needs to communicate one bit ('yes watermark'), so the effects can be arbitrarily small provided one is willing to tolerate an increase to the text size needed for reliable detection.

I'd disagree here. I see two avenues for an efficiency multiple, albeit a single-digit multiple:

* Client aggregation allows a hyperscaler to average out demand spikes from uncorrelated clients, reducing the peak:average demand ratio and allowing better budgeting of compute.

* Dynamic batching allows typical requests to run in batches of more-than-1 and/or overlap, offering better internal compute utilization ratios (e.g. interleaving output and input streams). The small limit of on-device LLMs will run with batch sizes of one with strong memory bandwidth bottlenecks.

For an example of these factors in action, see the API cost differential between batch, standard, and 'fast' processing. OpenAI prices these tiers at a 1:2:4 ratio.

I can imagine just the opposite outcome from the same scenario: as people settle into their favorite but commoditized models, competition for marginal inference cost will take over. A company like OpenRouter that promises the cheapest tokens by the minute becomes essential on the low-cost margin.

I think that OpenRouter and equivalents get pushed out of the market only if the froth calms down (as you posit) and winning models stay proprietary, perhaps with their own unique API surfaces.

All other things being equal, increasing the speed of some part of the development process will increase the overall pace of development. However, By Amdahl's law that increase will be sublinear, and that is why we should take "pull requests" as an imperfect metric.

We also don't get to pick the form that 'better technology products' take. While we'd probably like to keep cost(/effort) and complexity constant and increase robustness and performance, the market equilibrium might be 'worse is better' and reward whiz-bang features and lower effort.