Majromax

> I was told by our school electrician that long ago the clocks were adjusted by the power company. So around 2am DST they would either send power at 59Hz* to fall back or 61Hz* to spring forward. This was from the era when power grids were separate and analog.

That wouldn't have worked.

Grid-tied synchronous clocks (https://en.wikipedia.org/wiki/Electric_clock) were once ubiquitous and did derive their timekeeping stability from the grid frequency, but that is only suitable for keeping time once set. It works because electric grids are frequency-controlled and stabilized, where deviations from the reference frequency are corrected over long intervals.

In principle you could send power at 59 or 61Hz to adjust these clocks, but there are two problems:

1. The grid frequency isn't arbitrary, it's also directly coupled to the rotary inertia of every turbine that powers the grid. This is why power fluctuations cause frequency changes: temporary oversupply or undersupply causes these turbines to slow down or speed up respectively, using their inertia as power storage. Potentially screwing up every other piece of mechanical equipment tied to the grid for the sake of clock changes is... a poor optimization.

2. A one-Hertz difference isn't enough to change the clocks in a timely way. To change time by an hour you need to gain or lose 3600 * 60 = 216k cycles, but a 1Hz change gains or loses one cycle per second. It'd take about 2.5 days to complete a one-hour change via this mechanism.

I'd argue that they're still open-source because inference code is fully public. In operation, a user can crack open the model and examine its internal state, and we also see that many people produce various modifications or fine-tunings of public models for their own goals.

In my mind, this meets the conceptual and technical bars of an 'open source' designation. We can also imagine the opposite, where inference itself has to pass via an inscrutable binary blob that keeps the model's technology stack fully proprietary.

You're correct that we're missing the training data, the training recipe/curriculum, and any secret sauce that went into optimization of same, but I don't think that's an essential feature of an open source designation.

Instead, I think that the model weights are a kind of rendered artifact, and it should be evaluated on that basis. We don't treat permissively licensed images as something lesser, even if the photographer or illustrator supplies only the final image rather than the full camera raw file and/or Photoshop layer stack.

The difference, of course, is that the rendered artifact (weight blob) in a language model is so much more important than a typical photograph.

> I wrote the article. How you define quality is exactly the issue.

I agree, but I think you're using an unintuitive definition of quality. Since SynthID essentially acts as a seeded RNG, you will not be able to tell the difference between natural output and SynthID outputs with one sample per prompt.

We wouldn't be talking about "quality loss" if a model provider just ran `rng.seed(user_id)`, but it would have the same user-visible outcome.

This article is wrong. SynthID-style watermarking does not affect one-shot generation quality. When news about the watermarking went around a couple of months ago I too thought there must be a quality/detectability tradeoff (as there is for images), but I dug into the math more and realized that my intuition was incorrect.

They key idea is this: changing the random seed for LLM generation definitionally does not change the distribution of tokens in expectation over all seeds.

This can already be used to embed information in LLM streams, leading to LLM steganography work (https://arxiv.org/abs/2606.09135, but the idea dates back much further). Take your target message, whiten it via a one-time pad (stream cypher), then use it as the 'compressed stream' under an arithmetic decoding process (https://en.wikipedia.org/wiki/Arithmetic_coding) with the LLM-supplied logits as the assumed probabilitiy distribution.

SynthID pulls off the same kind of trick, save that its 'tournament structure' allows application after the sampling step rather than before. The random seed under SynthID becomes context sensitive (keying on the prior N tokens as well as the watermark seed), but in expectation the next-token distribution is still the same as the unwatermarked case.

If there's no change in token distribution, then there can't be a change in quality.

However, the article and its sources are right about one factor: random generation diversity will suffer. Applying SynthID to an LLM stream acts like fixing the PRNG seed. Repeated generations with the same prompt and same seed will deliver the same result, up to small amounts of nondeterminism in the architecture (mostly GPU scheduling and roundoff). This matters under the same circumstances that it would matter if the provider said "we sample using the XYZ PRNG with fixed seed '42'".

In my opinion, 'sample diversity' and 'sample quality' are not the same thing, and conflating the two concepts leads to poor intuition. SynthID and the like probably matter most if one is trying to repeatedly sample an LLM in order to infer the probability distribution (e.g. using a commercial LLM provider as a Jev-style classifier, looking for calibrated answers).

> The rocket launch was only achieved through significant ‘manual’ effort on Sol’s part as it papered over its late-game failures to connect certain production systems by repeatedly ferrying supplies between areas of the factory.

Looking through the video, around 12m one can see the Sol trace report the cancellation of a conflicting 'courier' (hand-feeding) script.

Rather than implement 'manual' effort, it seems like Sol considered the Engineer to be just another unit of automation!

That's not exactly within the intent of the challenge, but it's not too far out of bounds either. It's also a hard loophole to close if the agent interacts with the game through a scripting layer.

> Luna < Terra < Sol < Astra, fine. But does Terra 6.1 beat Sol 6? Does Fable 5.1 beat Opus 5.5? If I build something around this Terra 6.1 release, then when Luna 6.2 is released in a month, should I swap?

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.

Also less useful than one might think at first.

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.

> Why would you leave out the form specified by the GP? Representative (republican) government where the 40 members would hold an election to nominate a smaller number of representatives to decide on what should be done and bind everyone to abide by their decisions.

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.

> If you do not have a mandate to govern from the people, you need unanimity from all homeowners. Those are the alternatives.

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).

> One thing that's different about Sinai is that it keeps the code author and reviewer in separate agents with separate context. At the time we built it, we suspected that this would lead to better outcomes, but again, we haven't validated that it does.

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.

Funny that we've automated meeting hell. Definitely a truism that we reimplement the org chart in software.

> You would need sufficient evidence to support a claim that NVIDIA intentionally lied, which you obviously don't have otherwise you would have mentioned it in your post.

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.

> They should just offer to settle at a reasonable value

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.

> This feels like an obvious jab at Navier-Stokes, but where we get to shift the numbers around to hide where the compute actually is being spent ... compute is being spent. It's either being spent in amortization to make the search smarter ahead of time, during training, or its being spent after.

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.

I can't speak for the authors' mindsets, but the Stars! map had pointwise movement rather than via strict stellar/planetary waypoints. When fleet interceptions can happen midcourse[1], there's not a whole lot of design room within the Win16 style.

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

Wasn't the shareware version fully featured, such that only the key was necessary?

> The cyclone prediction thing is very interesting to me in particular (not quite sure how you go from the ML matrices to "here's a path the cyclone might take")

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.

> It’s crazy we’ll never have forecasts as good as dark sky again.

'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.

A barometer will give you surface pressure, but that's a field that tends to vary relatively slowly over the surface of the Earth. The calibrated weather stations that exist at every airstrip do a reasonable job of providing these conditions over land, and the residual of "pressure from phones" probably won't help all that much.

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...).

That line of reasoning has no end. If you use Antigravity on anything other than a Google Chromebook or Pixel, the hardware is a 'product not provided by them'. Is that a TOS violation?

If your maximum addressable market is “the whole economy,” as seen in SpaceX filings, then a city-sized call centre (distributed, of course) really is ‘t that much of an ask.

> But it’s just as likely to make an output better.

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.

> Hyperscalers don't run computing at some multiple more efficient than on prem.

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.

> As things settle down and commoditize, the value of switching on a dime diminishes as people lock into their favorite models

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.

You could say the same thing about compilers versus assemblers, high-level languages versus low-level ones, and services and libraries versus monolithic programs.

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.

> Is the ROI there to pay for the trillions in commitments that have been bet on that ROI? That looks like a clear no at this point.

That's only a potential crisis for those who have made concrete investments.

On the use side, the 'cost' of AI spans more than two orders of magnitude. Looking at recent models (<6mo) with reasonable performance (intelligence index >= 45) on OpenRouter, the output cost ranges from $50/MTok (Fable) to $0.153/MTok (DeepSeek Flash 0731).

From the perspective of a user of LLM/agent assistance, there's very likely a range where the benefits outweigh the costs.

If the ROI for the model developers isn't there, then that just impairs the future trajectory of the field. Current models are just bits that aren't going anywhere, and as long as they can be served (in inference) above their marginal cost they will continue to be so-delivered.

A reasonable guess about the algorithm is 'A Watermark for Large Language Models' (https://arxiv.org/abs/2301.10226). The idea is that each generated token (or bigram) seeds a strong PRNG that splits the vocabulary into a 'green' and 'red' set. The sampler then tries to select a 'green' next-token for generation.

After-the-fact checking only needs the vocabulary splitter, which is independent of the LLM. Over a sufficiently large text non-watermarked text would expect to use green and red tokens with the baseline probability, and that difference can easily become statistically significant over sufficiently long texts.

The basic algorithm has obvious knobs to tune, among them the initial ratio of red to green tokens and how hard the sampler tries to pick a green token. These would balance fidelity to the original distribution against watermark detectability (minimum required content length for statistical power).

> But unless you know the prompt, you don't fully know which choice the model faces. Surely a lot of coding space is wasted compensating for that uncertainty.

When you only need to encode one bit, the signal to noise ratio can be very low. If I try to write my own human words under the policy of "try a little bit to avoid the letter 'e' in every fifth word," then a sufficiently long text would still be 'watermarked' even if I only succeed in this dictum (e.g.) 10% more often than the baseline.

> Wouldn't one AI or another detect this deliberate backdoor and report it, as it'll look just like any other security vulnerability, the only difference being the intention?

That's precisely the author's point: deliberate backdoors will be more adversary-exploitable than ever before, but the demand for such from law enforcement agencies is likely to ratchet upwards.

> In the notebook, I compute a MiniLM embedding of every real Wayfair classification. I compute the embedding of the fake, hypothetical embedding from the LLM. I then dot product the fake embedding into the real ones to find the most similar. Producing: [the right answer]

Isn't this begging the question that the hallucinated classification will be more selective with respect to the real schema than the query itself? What would the dot product of <E(search query), E(schema)> have given?

Even if that is too vague, smaller LLMs are capable rerankers; return the top N matching true categories and ask for a contextual ordering.