spenczar5

This is still $150M of pure gravy every single year.

The issue is rate of return. They are evidently spending $4.85bn on Xbox per year. The US federal interest rate is 3.5% so if you just put that money in US bonds you would get about $175M per year of much purer simpler gravy.

Sometimes you get there by accident. You make a thing, it grows or is used in unexpected ways, now suddenly performance matters.

Sometimes Python is just the language used in the domain. Lots of sciences live on Python because it is easy to teach to grad students and the package ecosystem is strong.

It's in the first sentence of your quote:

"our continued collaboration with Anthropic"

Read this as: "we get discounts, rate limit increases, a direct line to responsible product managers; in exchange we participate in friendly marketing." It's extremely common in this line of business - typical of database vendors, software tool companies, etc.

Yep! The industry term is "co-marketing" and its hard to avoid seeing once you spot it.

No, but they go on strike when negotiating their collective contracts, and put terms in the contract that govern how failures like this are investigated and punished.

A correction was made on May 6, 2026: An earlier version of this article misstated the country where Guy Goma grew up. He is from the Republic of Congo, not the Democratic Republic of Congo.

Right guy, wrong Congo! You can't even make this stuff up.

Does it matter that pen and paper dominate? How much of the business's expenses are overhead?

Sure, llms.txt is a convention for this.

Compare https://docs.firetiger.com with https://docs.firetiger.com/llms.txt and https://docs.firetiger.com/llms-full.txt for a realy example.

That's a pretty interesting idea! I guess 160+ is sort of doing some of that for us - it compiles to SQL WHERE clauses, right - but generally, we found good results giving it a SQL dialect directly.

I think some of the reason is that there's so much coverage of writing SQL in its training set.

Yes! This works really well from Sonnet 4.5 onwards, in our experience. Sonnet 4.0 was a little rocky - we had to give it tons of documentation - but by now it works without much effort.

One thing that works very well is just giving it one or two example valid programs/statements in the custom language. It usually picks up what you're getting at very quickly.

When it slips up, you get good signal you can capture for improving the language. If you're doing things in a standard agent-y loop, a good error message also helps it course-correct.

Author here! I am pretty jazzed about these ideas and happy to dig into more detail than a blog post allows.

Is this a clone of the Google AIPs? Like https://aep.dev/160/ seems to just copy https://google.aip.dev/160.

"Cheap" how? I have a friend who works on Seattle's bus planning. Removing a stop is a _lot_ of political work. When an elderly person depends on that bus stop being within a block so they can get to their doctor, and you're proposing to move it six blocks further away, that's essentially a _political_ cost.

It might better in the system throughput, and those benefits may even outweigh the misery put on that one person. But in the US, we largely sort that out by using cool-down times, hearings, and "community input."

Net result, according to my friend at least, is that bus stops feel _very_ sticky and hard to change.

Its unexported for that reason. You only change it in tests.

It's in the article that you're commenting on, https://www.spacex.com/updates#xai-joins-spacex.

I feel like I see an independent low-noise phone project like, every 3 months. Clearly there is some latent demand here. I wonder why the big players (Google, Apple, Samsung, HTC) haven't made a big-corp product for this market.

I am always reluctant to jump on with these independent ambitious projects. The first version is understandably rough, and the company seems to fold before they get to a second or third version.

But maybe advances in manufacturing in China are making high-quality, small-batch products like this more tractable?

"But accepting the full S3Client here ties UploadReport to an interface that’s too broad. A fake must implement all the methods just to satisfy it."

This isn't really true. Your mock inplementation can embed the interface, but only implement the one required method. Calling the unimplemented methods will panic, but that's not unreasonable for mocks.

That is:

    type mockS3 struct {
        S3Client
    }

    func (m mockS3) PutObject(...) {
        ...
    }

Defining a zillion interfaces, all the permutations of methods in use, makes it hard to cone up with good names, and thus hard to read.

no, "pdf" is a very typical shortening for "probability density function," its correct.

Its JSON schema, well standardized, and predates LLMs: https://json-schema.org/

Thanks for the detailed answer!

I use DuckDB today to query Iceberg tables. In some particularly gnarly queries (huge DISTINCTs, big sorts, even just selects that touch extremely heavy columns) I have sometimes run out of memory in that DuckDB instance.

I run on hosts without much memory because they are cheap, and easy to launch, giving me isolated query parallism, which is hard to achieve on a single giant host.

To the extent that its possible, I dream of being able to spread those gnarly OOMing queries across multiple hosts; perhaps the DISTINCTs can be merged for example. But this seems like a pretty complicated system that needs to be deeply aware of Iceberg partitioning ("hidden" in pg_lake's language), right?

Is there some component in the postgres world that can help here? I am happy to continue over email, if you prefer, by the way.

Very cool. One question that comes up for me is whether pg_lake expects to control the Iceberg metadata, or whether it can be used purely as a read layer. If I make schema updates and partition changes to iceberg directly, without going through pg_lake, will pg_lake's catalog correctly reflect things right away?

I think I don't understand postgres enough, so forgive this naive question, but what does pushing down to the remote tables mean? Does it allow parallelism? If I query a very large iceberg table, will this system fan the work out to multiple duckdb executors and gather the results back in?

sure, but that is a fairly trivial tool call too. Ask it to name the distribution family and its parameter values.

Frankly, yes.

The models are one part of the story. But the software around it matters at least as much: what tools does the model have access to, like bash or just file reading or (as in your example!) just a cache of files visited by the IDE (!). How does the software decide what extra context to provide to the model, how does it record past learnings from conversations and failed test runs (if at all!) and how are those fed in. And of course, what are the system prompts.

None of this is about the model; its all "plain old" software, and is the stuff around the model. Increasingly, that's where the quality differences lie.

I am sorry to say but Copilot is just sort of shoddy in this regard. I like Claude, some people like Codex, there are a bunch of options.

But my main point is - its probably not about the model, but about the products built on the models, which can vary wildly in quality.

Where (vaguely, of course) do you live? That sounds so different from my experience in a city.

I agree, but there are other possibilities in between those two extremes, like Quivr [1]. Schemas are good, but they can be defined in Python and you get a lot more composability and modularity than you would find in SQL (or pandas, realistically).

1: https://github.com/B612-Asteroid-Institute/quivr

Isn't the original post about servers? A minimal client doesn't help with server security.

I would endorse your idea, though, speaking more broadly! That does sound useful.

I dont know, arguing that http/2 is safer overall is a... bold claim. It is sufficiently complex that there is no standard implementation in the Python standard library, and even third party library support is all over the place. requests doesn't support it; httpx has experimental, partial, pre-1.0 support. Python http/2 servers are virtually unavailable at all. And it's not just Python - I remember battling memory leaks, catastrophic deadlocks, and more in the grpc-go implementation of http/2, in its early days.

HTTP 1.1 connection reuse is indeed more subtle than it first appears. But http/2 is so hard to get right.

Yes, I think that sounds like Warp.

Personally, I find warp a bit disorienting, but it is indeed a more integrated approach.

JITting bytecode VMs really seem fantastic at this. A similar trick works in Avro in Python (https://journal.spencerwnelson.com/entries/avro.html).

I suppose the insight is that schema documents are programs, just in a weird language, and compiled programs are fast.