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.
>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.
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:
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.
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.
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).
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.