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.

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

https://openai.com/api/pricing/

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.

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.

https://github.com/valinet/ExplorerPatcher/

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.

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.

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.

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.

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.

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.

https://prunt3d.com/

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."

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.

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.

1 - https://en.wikipedia.org/wiki/Geometric_modeling_kernel

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.

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.

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.

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.

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