HN user
Sure, but the reason I'm confused by the pricing is that the pricing doesn't exist in a vacuum.
Pro barely performs better than Thinking in OpenAI's published numbers, but comes at ~10x the price with an explicit disclaimer that it's slow on the order of minutes.
If the published performance numbers are accurate, it seems like it'd be incredibly difficult to justify the premium.
At least on the surface level, it looks like it exists mostly to juice benchmark claims.
In particular, the API pricing for GPT-5.2 Pro has me wondering what on earth the possible market for that model is beyond getting to claim a couple of percent higher benchmark performance in press releases.
Input:
$21.00 / 1M tokens
Output:
$168.00 / 1M tokens
That's the most "don't use this" pricing I've seen on a model.
Spinning rust still typically holds advantages for archival storage, as well.
There was literally a headline on the front page here a few days ago re: data degradation of SSDs during cold storage, as one example.
It also eats vertical space with those huge icons, which is precious given the current popular screen dimensions.
This is one Windows gets wrong too, in fairness.
W11 killed the ability to move the taskbar to the left/right side of the screen. That's a real pain on ultrawide displays where you have absolutely miles of horizontal real estate and relatively limited vertical space.
Fortunately, ExplorerPatcher exists and can restore the functionality.
I think people who do this think that people who use Windows perceive that the Mac experience is smoother, and may have some sort of Mac envy.
There's an irony in this due to this:
b) WSL-based, VSCode-using devs who are one step away from just using Linux. These are the folk who fifteen years ago would have been using what was then still OSX. But these folk don't use Windows as Windows: they use it as a semi-Unix.
The people still doing the "hurr durr wind0ze suxx" routine are the ones stuck 15 years in the past. Modern Windows is an entirely different and vastly more capable beast and it still runs huge swathes of the enterprise world.
The best technologists I know don't really care all that much which desktop platform you stick them on anymore since most of what they really need is either available everywhere or running on a backend that isn't their desktop anyway.
It was a built-in expander. The bed was 4x6 in standard configuration and could pull out another 2 feet to get 4x8 when you needed it.
I'm firmly of the opinion that, as a general rule, if you're directly embedding the output of a model into a workflow and you're not one of a handful of very big players, you're probably doing it wrong.[1]
If we overlook that non-determinism isn't really compatible with a lot of business processes and assume you can make the model spit out exactly what you need, you can't get around the fact that an LLM is going to be a slower and more expensive way of getting the data you need in most cases.
LLMs are fantastic for building things. Use them to build quickly and pivot where needed and then deploy traditional architecture for actually running the workloads. If your production pipeline includes an LLM somewhere in the flow, you need to really, seriously slow down and consider whether that's actually the move that makes sense.
[1] - There are exceptions. There are always exceptions. It's a general rule not a law of physics.
(Healthcare in the US is nearly entirely Windows based).
This wasn't my experience in over a decade in the industry.
It's Windows dominant, but our environment was typically around a 70/30 split of Windows/Linux servers.
Cerner shops in particular are going to have a larger Linux footprint. Radiology, biomed, interface engines, and med records also tended to have quite a bit of nix infrastructure.
One thing that can be said is that containerization has basically zero penetration with any vendors in the space. Pretty much everyone is still doing a pets over cattle model in the industry.
Then compare this to something like a Kei truck and it's really quite pathetic.
I will forever be sad that Canoo was wildly (possibly fraudulently) mismanaged and went bust before they ever built any of their planned pickup trucks:
https://cars.usnews.com/cars-trucks/features/canoo-pickup-tr...
They were going to be built on the same platform as their vans and the best way to describe them is "Kei truck upsized and uppowered enough to be safe on US roads." They had neat party tricks like a compact bed for daily driving that could expand out to fit full size ply and fold out workbenches on all four sides of the truck.
I'm not even a truck guy and I desperately wanted one of these things. Just such a cool concept.
Anthropic feels like a one trick pony as most users dont need or want anthropic products.
I don't see what the basis for this is that wouldn't be equally true for OpenAI.
Anthropic's edge is that they very arguably have some of the best technology available right now, despite operating at a fraction of the scale of their direct competitors. They have to start building mind and marketshare if they're going to hold that position, though, which is the point of advertising.
Anthropic, frankly, needs to in ways the other big names don't.
It gets lost on people in techcentric fields because Claude's at the forefront of things we care about, but Anthropic is basically unknown among the wider populace.
Last I'd looked a few months ago, Anthropic's brand awareness was in the middle single digits; OpenAI/ChatGPT was somewhere around 80% for comparison. MS/Copilot and Gemini were somewhere between the two but closer to Open AI than Anthropic.
tl;dr - Anthropic has a lot more to gain from awareness campaigns than the other major model providers do.
Tangentially related, one of the more interesting projects I've seen in the 3D printing space recently is Prunt. It's a printer control board and firmware, with the latter being developed in Ada.
https://github.com/Prunt3D/prunt
It's kind of an esoteric choice, but struck me as "ya know, that's really not a bad fit in concept."
I don't entirely agree there.
In a vacuum for a standalone object, a 3D mesh app like Blender can be useful for brainstorming.
Most of my CAD usage is designing parts that have to fit together with other things. The fixed elements drive the rest of the design. A lot of the work is figuring out "how do I make these two things fit together and be able to move in the ways they need to."
There is still a lot of room for creativity. My workflow is basically "get the basic functionality down as big square blocks, then keep cutting away and refining until you have something that looks like a real product." My designs very rarely end up looking like what they started out as. But the process of getting them down in CAD is exactly what lets me figure out what's actually going to work.
It's a very different workflow, and it's definitely not freeform in the same way as a traditional mesh modeling app, but CAD is for when you have to have those constraints. You can always (and it's not an uncommon pattern) go back and use a mesh modeler to build the industrial design side of things on top once the mechanical modeling is done.
ETA:
I'd also add: I'm not sure "thinking in CAD" comes naturally to anyone; it's a skillset that has to be built.
Even with procedural and parametric modeling in Blender, you will always encounter issues with approximation and floating point precision, which are inherent to the data representation.
A common problem people run into with CAD models is importing a STEP file and modeling directly off of geometry in it. They later find out that some face they used as a reference was read by the CAD package as 89.99999994 degrees to another, and discover it's thrown the geometry of everything else in their model subtly off when things aren't lining up the way they should.
And that's with a file that has solid body representation! It's an entire new level of nightmare when you throw meshes into the mix.
The heart of any real CAD package is a geometry kernel[1]. There are really only a handful of them out there; Parasolid is used by a ton of 'big name' packages, for example. This is what takes a series of descriptions of geometry and turns it into clear, repeatable geometry. The power of this isn't just where geometry and dimensions are known. It's when the geometry and dimensions are critical to the function of whatever's being modeled. It's the very core of what these things do. Mesh modeling is fantastic for a lot of things, but it's a very different approach to creating geometry and just isn't a great fit for things like mechanical engineering.
Changing dimensions or previous sketches is usually fine, but anything more complicated often results in everything in your stack breaking with strange errors, leading it to just be easier to re-create the model.
This is usually the result of design workflows and how you avoid it is going to vary based on the CAD package. It definitely requires being pretty deliberate in design, which can make it harder to draft out an initial design. And the path of least resistance is often one that's more likely to break.
One example would be in Fusion, using projected faces in sketches is far more fragile than projecting a body -- but Fusion will happily project faces by default.
Which constraint types you use where are another common cause of breakage.
The thing that makes it frustrating is that none of this is really well documented anywhere and largely ends up being best practice wisdom passed from one person to another, since a lot of this stuff is really non-obvious. And it's confounded yet again by people cargo culting best practices from one CAD package to another that then gets repeated third and fourth hand.
All that said, as you work with it more and delve into more complex designs, you'll end up settling into workflows that result in more resilient models if you're deliberate about it. The "scrap it and start over" cycle is part of the learning experience, IME, as frustrating as it is at the time.
they would let random retailers fill the order with fake products
What made this all particularly insidious is that Amazon not only commingled inventory, but actively refused to track where inventory came from.
This meant you only needed one fraudulent seller to poison the entire inventory pool and there was no way know where the bad product came from because Amazon actively avoided being able to track it.
That's the aspect of it that always felt particularly malicious to me.
I just have to mention that IRC had these archives so repeat questions had a corpus to search. The walled gardens don't.
For many businesses, this is a feature, not a bug.
Internal communications are discoverable in litigation. If you have records, you can be compelled to turn them over.
I used to work in healthcare. Internal messages had a maximum retention of 30 days. That wasn't driven by IT or the users. That was a decision made by legal. In that space, you are always being sued by somebody. The lawyers want to minimize exposure and that's a fight they're basically always going to win.
To be clear: it's better if that's a decision made by the business. But it's also one of those cases where what the decision makers care about isn't necessarily aligned with what the users care about, so there's ultimately not a lot of incentive for Slack to care.
Roo has codebase indexing that it'll instruct the agent to use if enabled.
It uses whatever arbitrary embedding model you want to point it at and backs it with a qdrant vector db. Roo's documents point you toward free cloud services for this, but I found those to be dreadfully slow.
Fortunately, it takes about 20 minutes to spin up a qdrant docker container and install ollama locally. I've found the nomic text embed model is fast enough for the task even running on CPU. You'll have an initial spin up as it embeds existing codebase data then it's basically real-time as changes are made.
FWIW, I've found that the indexing is worth the effort to set up. The models are generally better about finding what they need without completely blowing up their context windows when it's available.
Anthropic's models are fantastic, but they are -- by far -- one of the most expensive providers on an API basis. That's a large part of what makes the Max plans a great deal, right now.
Even on a Max plan, it's not hard to completely blow through your usage limits if you try to use Opus heavily.
All it takes is another provider to land a combination of model and cost that makes Code less of a deal for vendor lock-in to become a problem.
Roo can use Claude Code as a provider.
I mostly use Claude Code with a Max plan via Roo. I have the option of sending prompts to OpenRouter if I've hit usage limits or if I want to try a particular task with a different model (e.g., I'll sometimes flip to Gemini Pro if a particular task could benefit its large context windows).
Pricing/usage will be very simple - a fixed subscription and we will no longer know the tokenomics because the provider will have greatly abstracted and optimized the cost per token, favoring a model that they can optimize margin against a fixed revenue floor.
Personally, I think it's far more likely that a year from now either SotA models will have shifted elsewhere or Anthropic will have changed their pricing model to something less favorable than the current MAX plans. Either of those scenarios could suddenly result in the current Claude subscription models either not existing or no longer being the screaming deal they are now. I think it's exceedingly unlikely we see any major provider go to an unmetered business model any time soon.
And if you've built your entire workflow around tooling specific to Anthropic's services, suddenly you have an even bigger problem than just switching to a more cost effective provider. That's one of the bigger reasons I'm very skeptical of these wrappers around CC generally.
Even Claude Code itself isn't doing anything that couldn't and hasn't been done by other tools other than being tied to a really cheap way to use Claude.
The thing about tiny islands isn't that every tool needs a sprawling ecosystem to thrive. It's that applications that don't develop a userbase tend to die. This is as true of open source apps as it is commercial ones.
Typically, applications develop a userbase when they offer something that people can't find elsewhere.
What I'm saying isn't "everyone should be using VScode extensions for this"; it's "I see nothing to distinguish this from a bunch of other functionally identical applications and people just keep building them." I literally don't see a single unique feature promoted on the landing page.
My fundamental point is that we're in a gold rush phase where people are all building the same thing. We'll eventually see a handful of apps get popular and effort swell around those instead of everyone reimplementing the same thing. And my money is on that looking a lot like it usually does: the winners will be the apps that find some way to differentiate themselves.
To be clear: having a diversity of tools is a good thing! I like having options.
My complaint is more that right now it feels like everybody is rushing to fill the exact same space with the exact same feature sets.
It's resulting in a lot of superficial diversity that's functionally homogenous. I want to see more applications that are pushing the capabilities of current AI tooling in creative directions.
If you're opposed to using VSCode for whatever reason, that's reasonable. Though, for me personally, the fact that it only lets you use Claude Code strikes me as a much larger negative on net. It's not at all agnostic in terms of AI provider.
That said, VSCode is a popular platform for this for exactly the reason I think consolidation is eventually inevitable: it's got a huge preexisting ecosystem. There are extensions for practically anything you could ask for.
There's likely room for some standalone, focused apps in this space. I just don't see the current wave of "we put a wrapper around Claude Code and gave it some basic MCP and custom prompt management tools like a dozen other applications this week" being sustainable.
They're all going to end up on their own tiny islands unless there's a reason for an ecosystem to develop around them.
That's kind of what I mean though.
Because I mentioned it and it's what I use daily: Roo is a VSCode extension. So you get the entire VSCode ecosystem for free. On the AI specific side, it has every feature this app highlights on its homepage and more. It works with just about any API provider and model you could ask for.
I could probably translate my existing workflow over to Claudia pretty easily, but what does that get me? A slightly different interface seems to be about it.
That's the question I keep hitting with these new tool announcements.
On the one hand, it's good that we're seeing a lot of exploration in this space.
On the other, the trend seems to be everyone developing a million disparate tools that largely replicate the same functionality with the primary variation being greater-or-lesser lock-in to a particular set of services.
This is about the third tool this week I've taken a quick look at and thought "I don't see what this offers me that I don't already have with Roo, except only using Claude."
We're going to have to hit a collapse and consolidation cycle eventually, here. There's absolutely room for multiple options to thrive, but most of what I've seen lately has been "reimplement more or less the same thing in a slightly different wrapper."
It's going to depend heavily on your usage.
I use Copilot because work is paying for it and it can be made usable, but requires being really deliberate about managing context to keep things on the rails. It's nice that it gives you access to a pretty decent selection of models, though.
At home, I'm mostly using the $100 Claude plan. It's definitely not cheap, but I've found it has a pretty decent balance for my casual experiments with agentic coding.
Another option to seriously consider is setting up an account with OpenRouter and just tossing some cash into your bucket on occasion. OpenRouter lets you arbitrarily make API requests to pretty much any model you want. I've been occasionally tossing $10 or so into mine and I'll use it when I've hit my usage limits with Claude or if I want to see how another model will attack a particular task.
FWIW, I use Roo code for all of this, so it's pretty easy for me to switch between models/providers as I need to.
They're multipliers against your quota of requests. GPT-4.1 is "free" with a copilot sub, and then the premium models would burn credits against a multiplier. So higher multipliers count more against your monthly quota.
GPT5, Sonnet 4, and Gemini Pro 2.5 are all 1x. Opus is 10x, for comparison.
https://docs.github.com/en/copilot/reference/ai-models/suppo...
Also worth keeping in mind that Copilot has reduced context windows even for the premium models, which has a very real impact on agentic performance.
Kinda?
The fact that they chose to tie it to and advertise it as "get paid to see ads" is a significant turn-off in my mind even if the rest of the ecosystem theoretically works in functionally the same way.
In my mind, the entire point is to get away from advertising as a revenue stream entirely. I want to pay for the things I consume. If the advertising market has decided that my page impression is worth less than pocket change, I'd far rather just give that money to the publisher directly and avoid ads being part of the equation.
The core idea behind BAT isn't bad, but the marketing is pretty terrible if you're targeting people like me.
A decade ago, I was really interested in the idea of using a crypto like what Doge was at the time for this specific use case. Back then, a dogecoin was a fraction of a cent so it was a better fit than its current valuations.
Any individual page impression is only worth a few cents to the publisher anyway. I still think there's a lot of potential value in something similar as infrastructure for facilitating ultra-microtransactions on that scale that don't get completely consumed by credit card processors, etc.
I'm not going to maintain subscriptions to every news source out there, but I'd be more than happy to toss something in the tip jar from a fund I could top-up on a regular basis.