> If we are unable to differentiate our models, platform, and applications from competing offerings through enhanced functionality, superior performance, better safety features and reliability, lower cost, or other factors, demand for our models, platform, and applications may decline. The rapid pace of technological change in AI means that models, platforms, and applications can quickly become outdated. We must continuously invest in research and development to maintain our competitive position, but there is no guarantee that our investments will result in models, platforms, and applications that customers prefer over competing alternatives.
My thought is that any competition to Anthropic is going to need to actually have the compute to serve all of Anthropics customers. Chinese labs certainly do not. It seems to be the crux of all these compute agreements.
Even then, Anthropic has the luxury of knowing exactly what hardware (even what datacenter!) will serve their models. This gives them the ability to co-design their model for the exact chips it will run on, something that Open Weights models are completely unable to do - even to the point that Deepseek fully open-sourced their inference engine, revealing that they're still running on only H100s and Huawei Ascend chips (https://github.com/deepseek-ai/DeepInfer/blob/main/README.md).
Anthropic will be running their 2027 Opus and Fable models on Vera Rubin, a chip which produces tokens for about 1/100th the cost of the H200. Seriously. 100x more efficient on GLM 5.3: https://inferencex.semianalysis.com/inference/glm-5-3 compared to what DeepSeek is able to use for inference.
Combined with Kimi K3.1's underperformance I'm honestly not too bullish on Chinese AI being able to catch back up. As an example, according to https://artificialanalysis.ai/, Kimi K 3.1 would need to be run 10x cheaper than its current inference cost in order to hit the Paraeto Frontier (matching 6.1 Sol Medium)
That's a really good point, I hadn't thought about that. If Anthropic have tied up almost a trillion dollars in compute commitments, that's going to make it a lot harder for their competitors to steal their customers (though OpenAI seem to be fine on that front, they've been hoarding compute for years.)
One of Anthropic's most interesting technical moats is that they can serve their models on NVIDIA hardware or Google TPUs or AWS Trainium - they talked about that in an incident postmortem last September: https://www.anthropic.com/research/a-postmortem-of-three-rec...
I have a tiny devboard collection habit, and gotta say coding agents work great with these. I've got a stick and a few dials running various hyper specific UIs for home assistant.
Well, that's too bad; as the main developer of https://github.com/nneonneo/ghidra-wasm-plugin it would have been really nice to get better support for all the new features that have been added into the spec over the last few years.
I also think that, for larger projects, it's still useful to have real decompilation support; for example, Il2CppDumper works in tandem with ghidra-wasm-plugin to enable decompilation of Unity Il2Cpp projects, which are often enormous (100MB wasm files are not uncommon) and for which the symbols + types are invaluable.
It's wild to think how efficient Internet services were prior to AI. The most expensive thing would probably have been something like encoding video. Now you've a substantial portion of a rack dedicated to a user in the case of something like fable
Best analogue we have is probably video streaming. Or maybe more so live streaming. Unless subscription based and limited time events it seems those don't do well. Twitch has lost money for how long? And most smaller players seem propped up in other ways.
So if there is real cost involved things start to look lot worse and might not be overcome. OpenAI is unlikely to be exception for me.
JBIG2 does glyph binning, as you say not exactly OCR, but similar. So chunks of the image that look sufficiently similar get replaced with a reference to a single instance.
It's not too hard, while they share some mechanics, the underlying use-cases and requirements are very different.
_______ Optical character recognition:
1. You have a set of predefined patterns of interest which are well-known.
2. You're trying your best to find all occurrences of those patterns. If a letter appears only once, you still need to detect it.
3. You don't care much about visual similarity within a category. The letter "B" written in extremely different fonts is the same letter.
4. You care strongly about the boundaries between categories. For example, "B+" must resolve to two known characters in sequence.
5. You want to keep details of exactly where something was found, or at the least in what order they were found. You're creating a layer of new details, which may be added to the artifact.
_______ "Glyph compression":
1. You don't have a predefined set of patterns, the algorithm is probably trying to dynamically guess at patterns which are sufficiently similar and frequent.
2. Your aren't trying to find all occurrences, only sufficiently similar and common ones, to maximize compression. If a letter appears only once, it can be ignored.
3. You do care strongly about visual similarity within a category, you don't want to mix-n-match fonts.
4. You don't care about clear category lines, if "B+" becomes its own glyph, that's no problem.
5. You're discarding detail from the artifact, to make it smaller.
Glyph binning looks for any chunks in the image that are similar to eachother, regardless of what they are. Letters, eyeballs, pennies, triangles, etc without caring what it is. OCR looks specifically to try and identify characters (i.e. it starts with a knowledge of an alphabet, then looks for things in the image that look like those.
If the image is actually text, both of them can end up finding things. Binning will identify "these things look almost the same", while OCR will identify "these look like the letter M"
Jbig2 dynamically pulls reference chunks out of the image, which makes it more likely to have insufficient separation between the target shapes.
It also gives a false sense of security when it displays dirty pixels that still clearly show a specific digit, since you think you're basically looking at the original.
You asked what the difference was, and I said the difference. Was it unclear that to fit the phrasing of your question, we add "OCR doesn't"? I would not personally call Jbig2 OCR.
Let me try rephrasing to make the response to your original comment as clear as possible.
Question: "How can we describe OCR that wouldn't match this definition exactly?"
Answer: This definition largely fits OCR, but "reference to a single instance" is a weird way to phrase it. A better definition of OCR would include how it uses builtin knowledge of glyphs and text structure, unlike JBIG2 which looks for examples dynamically. And that difference in technique gives you a significant difference in the end results.
Is that better?
The definition you quoted is not an "exact" fit to OCR, it's a mildly misleading fit to OCR, and clearing up the misleading part makes it no longer fit both.
There's a handful of Windows game emulators taking off for Android. Using a modern snapdragon GPU, folks are playing Witcher 3, GTA 5. Some suffering gamer is playing through Dark Souls 2 using touch controls
Problem is, I assume, being stuck relying on some brittle apps that might or might not still run after some OS upgrade or after buying a new device. Like the DOSBox app I use on my Android phone is amazing but knowing that eventually it will suddenly expire (when the developer abandons it), like the previous one, makes me enjoy the games a lot less than I do when I have a more stable platform set up like when playing using some fully open source emulator on a rpi or x86 desktop pc.
reply