I'm incredibly salty about this - they're essentially monetizing intensely something that allows them to sell their inference at premium prices to more users - without any caching, they'd have much less capacity available.
I tried ChatGPT over the holidays (paid) vs. claude.ai (paid).
After trying some prompts that worked well on Claude in ChatGPT, I understand why people are so annoyed about AI slop. The speech patterns in text output for ChatGPT are both obvious and annoying, and impossible to unsee when people use them in written communication.
Claude isn't without problems ("You're absolutely right"), but I feel that some of the perception there is around the limited set of phrases the coding agent uses regularly, and comes less from the multi-paragraph responses from the chatbot.
> Out of curiosity, what are some good use cases for a MBP now with the MBAs being so powerful?
Local software development (node/TS). When opus-4.6-fast launched, it felt like some of the limiting factor in turnaround time moved from inference to the validation steps, i.e. execute tests, run linter, etc. Granted, that's with endpoint management slowing down I/O, and hopefully tsgo and some eslint replacement will speed things up significantly over there.
That doesn't seem to support your claim; guessing you mean:
> "2. Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy."
'Safe' languages don't need to do that, if they can verify the array access is always in bounds at compile time then they don't need to emit any code to check it. That aside, it seems like they are saying:
for (int i=0; i<10; i++) {
foo(array[i]);
}
in C might become the equivalent of:
for (int i=0; i<10; i++) {
if (i >= array_lower && i < array_higher) {
foo(array[i]);
} else {
??? // out of bounds, should never happen
}
}
in a 'safe' language, and i will always be in inside the array bounds so there is no way to test the 'else' branch?
But that can't be in SQLite's checks as you claim, because the C code does not have a branch there to test?
Either way it seems hard to argue that a bounds test which can never fail makes the code less reliable and less trustworthy than the same code without a bounds test, using the argument that "you can't test the code path where the bounds check which can never fail, fails" - because you can use that same argument "what if the C code for array access which is correct, sometimes doesn't run correctly, you can't test for that"?
Correct, that's what I mean. I trust SQLite's devs to know more about this, so I trust what they wrote. There are parts of Rust code that are basically:
do_thing().expect(...);
This branch is required by the code, even if it can't be reached, because the type system requires it. It's not possible to test this branch, therefore 100% coverage is impossible in those cases.
That’s not my requirement, that’s SQLite’s requirement. If you want to dispute their claim, I recommend you write to them, however I strongly suspect they know more about this than you do.
Not having bound checks does not make sqlite sqlite. If that was the case, you couldn't compile it with https://clang.llvm.org/docs/BoundsSafety.html turned on and still call it sqlite for example.
> I had assumed that reasoning models should easily be able to answer this correctly.
I thought so too, yet Opus 4.6 with extended thinking (on claude.ai) gives me
> Walk. At 50 meters you'd spend more time parking and maneuvering at the car wash than the walk itself takes. Drive the car over only if the wash requires the car to be there (like a drive-through wash), then walk home and back to pick it up.
And on the flip side, even without thinking, Gemini 3 flash preview got it right, with the nuance of the possibility of getting supplies from the place (which tbh I as a human first thought this was about when I opened this thread on HN).
> Since you are going to the car wash, the choice depends entirely on *how* you plan to wash the car:
### 1. Drive if:
* *You are using a drive-through or self-service bay:* You obviously need the car there to wash it.
* *You are dropping it off:* If you are leaving it for a professional detailing, you have to drive it there.
* *The "50 meters" is on a busy road:* If you have to cross a major highway or there are no sidewalks, it’s safer to just drive the car over.
### 2. Walk if:
* *You are just going to buy supplies:* If you have a bucket at home and just need to run over to buy soap or sponges to bring back to your driveway.
* *You are checking the queue:* If you want to see if there is a long line before you commit to moving the car.
* *You are meeting someone there:* If your car is already clean and you’re just meeting a friend who is washing theirs.
*The Verdict:*
If you intend to get the car washed at that location, *drive.* Driving 50 meters is negligible for the engine, and it saves you a round trip of walking back to get the vehicle.
At $workplace, we have a script that extracts a toolchain from a GitHub actions windows runner, packages it up, stuffs it into git LFS, which is then pulled by bazel as C++ toolchain.
This is the more scalable way, and I assume it could still somewhat easily be integrated into a bazel build.
Keeping CI entirely out of windows desktop development is the biggest efficiency and cost improvement I've seen in the last 15 years. Our CI toolchain broke so we moved back to a release manager doing it manually. It takes him 20x less time to build it and distribute it (scripted) than it does to maintain the CI pipeline and his desktop machine is several times faster than any cloud CI node we can get hold of.
Edit: Uses a shit load less actual energy than full-building a product thousands of times that never gets run.
One other thing I'd assume Anthropic is doing is routing all fast requests to the latest-gen hardware. They most certainly have a diverse fleet of inference hardware (TPUs, GPUs of different generations), and fast will be only served by whatever is fastest, whereas the general inference workload will be more spread out.
This was my assumption - GB200 memory bandwidth is 2.4x faster than H100, so I think personally that's all it is. Doesn't really make sense otherwise as yes there are tricks to get faster time to first token but not really for the same model in throughput terms (speculative decoding etc, but they already use that).
I'm happy to be wrong but I don't think it's batching improvements.
Depends on the residence. I have personally seen a large house in Brooklyn with dual 200 amp 120/208 volt three phase services (two meters, each feeding a panel.) I have seen someone setup an old SGI rack scale Origin 3000 systems in their garage. I think they even had an electrician upgrade their service to accommodate it.
100% this. But don't forget the garden hose running full blast so you can cool it! It's not impossible to get up and running for fun for an hour, but this isn't a run 24/7 kinda setup any more than getting an old mainframe running in one's garage is practical.
> I’m currently using a mix of Zed, Sublime, and VS Code.
Can you elaborate on when you use which editor?
I'd have imagined that there's value in learning and using one editor in-depth, instead of switching around based on use-case, so I'd love to learn more about your approach.
Different user, but I prefer to use different editors for:
- project work, i.e. GUI, multiple files, with LSP integration (zed)
- one-off/drive-by edits, i.e. terminal, small, fast, don't care much about features (vim)
- non-code writing, i. e. GUI, different theme (light), good markdown support (coteditor)
I don't like big complex software, so I stay away from IDEs; ideally, I'd like to drop zed for something simpler, without AI integration, but I haven't found anything that auto-formats as well.
My workflow isn't very common. I typically have 3-5 projects open on the local machines and 2 cloud instances - x86 and Arm. Each project has files in many programming languages (primarily C/C++/CUDA, Python, and Rust), and the average file is easily over 1'000 LOC, sometimes over 10'000 LOC.
VS Code glitches all the time, even when I keep most extensions disabled. A few times a day, I need to restart the program, as it just starts blinking/flickering. Diff views are also painfully slow. Zed handles my typical source files with ease, but lacks functionality. Sublime comes into play when I open huge codebases and multi-gigabyte dataset files.
in my case, I use zed for almost everything, and vscodium for three things:
search across all files; easier to navigate the results with the list of matching lines in the sidebar, and traversing the results with cursor up/down, giving full context
git; side-by-side diff, better handling of staging, and doesn't automatically word-wrap commit messages (I prefer doing that myself)
editing files which have a different type of indentation than what is configured in zed, since zed does not yet have autodetect
I'm incredibly salty about this - they're essentially monetizing intensely something that allows them to sell their inference at premium prices to more users - without any caching, they'd have much less capacity available.
reply