CBLT

Yeah I also thought it was strange their pareto frontier didn't include cost.

I buried the lede in my suggestion. I was saying that a future would give enough time to build or expand the fab in order to fill it. This means the company can fill an arbitrarily large number of orders - both consumers and big players - because it will just build the capacity to meet it.

I'd come at this from a different angle: we still want this to be market system, so we need to make this priced into the market. How can we price this in?

I would try to solve this by making the market structure reflect the underlying difficulty: we have to decide what capacity to produce years in advance, to construct the memory fabs. So this should be a futures market, and a capacity crunch would affect short-term-futures, but leave full term futures at the same price. Because the companies supplying the memory can just construct more capacity to fill those futures at the same cost regardless of the AI demand.

The readme seems to say the answer is yes? You'll lose the disk-based cache, but it's not inherently unsafe because the only coordination is object storage.

If you don't have any kind of agent instructions saying "don't copy code into prose", you'll inevitably get text that reflects some previous state of the system instead of its current state.

I've only seen it in bigcorp cross-service typedefs, or in startup's code that re-implements the checks in every service.

There's a good amount of literature about this (check the other comments), but you can vastly simplify this into two things you need to do:

1. Your service that retries should have some retry budget. This is a good place to be "smart", because you can reason entirely locally instead of turning it into a distributed systems problem. The best library I've seen for this was doing Exponential Moving Average of requests per second sent down that pipe (not counting retries) and only allowing 20% more requests per second as retries, total. Each individual request could be retried 3 times. This was critical as it bounds the additional load from retries.

2. Whenever a service retries but has to give up, the error it sends to its callers should never be retried. There has to be some agreement that that HTTP code will never be retried. This prevents the multiplicative factor of retry on top of retry, which is why those storms can generate so much load.

Everything else is nice-to-have, but those two alone should bound the total requests you get in a retry storm.

Can you recommend any model that doesn't do this?

I also read that comment as an adversarial situation at work.

It used to be that when someone else at your company was asking for something that wasn't a priority, you would erect bureaucratic roadblocks to protect your time. Now, the new normal is to just forward their questions to AI and sling the slop back over to them.

I was bothered by the writing and fought through it, and carefully went through everything in the article... and you didn't miss anything. It's a tweet expanded to article length.

If you can actually time the market, sure. I cannot, so I don't pull money out of my stock indexes; I just send a larger fraction of my new investments into bonds.

I've been telling people the same thing. The tech industry has been cargo-culting "scaling the organization" where people are rewarded for org size. That zeitgeist has ended, and we've not even overcorrected much the other way.

> the CPUID example in the article [...] forgot to bind ECX as an input.

I'm not really familiar with this stuff, but the example uses what it calls a "pin" (which in their docs is a type of "binding") on ECX before calling CPUID.

The Google Drive link is to a simple tarball, not a git artifact.

Non-sequitor? They're not providing a (sha-1) hash, they're providing source code to integration partners using their business channels, not public git providers. Those business channels include contracts etc to "secure their supply chain".

You and I aren't in those business channels, and we're not being given anything with a hash. There's simply no hash to collide with?

It doesn't break supply chain security for anybody with power to change the situation.

Interestingly, this was tackled in this blog post[0] a month ago. They claim that plan files aren't token-efficient, because after reading the plan the workhorse model then reads all the relevant files anyways.

[0] https://news.ycombinator.com/item?id=48916512

That's a measure of the costs GitHub incurs to operate, not of its value as a platform.

I heat it bare, then seconds before I put the steak in I pour some peanut oil, which immediately begins smoking.

I've tried a blowtorch and a barbecue, but they're not as good as cast iron. Best results from just spending $15 on a second cast iron.

Article aside, I generally always use the "we" pronoun at work when writing prose. Saying "I" feels too adversarial when talking about negative effects, or too self-aggrandizing when talking about positive effects. For example: "We discovered a bug shipped at the end of the merge window, so we will restart validation with the rollback applied." I think in school they say the business-safe way to write is instead with the passive voice but I just can't do it.

Generating new conjectures is easy. It's generating novel conjectures that's hard.

I said "never called them on their plausible deniability" to mean I never pulled off the veil of the conversation, so there's nothing to talk about in front of a judge.

FWIW both the company I was leaving and the company I was joining were startups selling dynamic seat pricing systems to airlines. Your call if that's a conflict of interest :).

The only time I did that, the company I was leaving begged me to take one of their corp laptops with me so I could offer "consulting" to them on the side. I never called them on their plausible deniability, I just said I felt that would be a conflict of interest and they shut up real fast.

I'm trying to understand what you mean, because it's not obvious to me at all. If you read LKML you'll see stacked PRs has been the norm for years. I'm assuming you want the `gh stack` porcelain into the git cli? We'd first need to add PRs as a porcelain to the git cli for it to make any sense, right?

The interim policy you're proposing seems to have far different priors. The clearest indication of their stance is that they don't even want bug reports that have AI generate part of the text. You don't take a stand like that (imo) unless you've experienced some serious AI-related burnout.

SQL/PGQ (Property Graph Queries) is part of the SQL standard as of 2023. I found this project months ago _because_ they included PGQ in their name, I was searching for PGQ implementations.

Not by name, sure, but it does mention that you're going to be reading the same context into the second model. It specifically refutes your point that you're only reading the smaller plan:

> Opus reads base.py, signing.py, the test file (twenty cards of gray), then writes its plan and leaves. And what's the first thing Flash does with that beautiful document? It re-reads base.py and the test file, because a plan is not a file and you cannot edit prose. The gray reads just keep stacking, first at Opus prices, then again at Flash prices. There is no version of this where a second reader is the cost optimization.

Memory is a harness feature, not a model feature.

The author is probably only evaluating their own harness with different models, so Claude-Code-specifics like memory aren't part of their evaluation.

Linked your own project with an "All rights reserved" license? The only thing my company will allow me to do with that software is have AI steal it </s>