There's a sentence engineers say to each other that sounds like a complaint and is actually a description of the job:

"My concern is always time. And you can't really buy time."

The engineer who said it works in R&D at Frore Systems, and he was explaining the one constraint that governs everything else he does. Not budget, not headcount, not compute. Time, and in particular the fact that the work arrives in a line, one item behind another, when the calendar wants it all at once.

TLDR:

• Serial CFD workflows force a queue of one: mesh rebuild, converge, boundary sweep, repeat, each step waiting on the last.

• Parallelizing those paths means you decide what runs next, instead of waiting on what ran before.

• HPC job submission scripting and other CFD-adjacent work can be automated alongside the solves themselves.

• Plain-English prompts remove the menu-archaeology bottleneck when your team picks up a new simulation package.

• Cosmon gives hardware engineers a plain-English interface to the simulation tools they already own.

The company

Frore Systems builds thermal solutions for electronics, a category that has quietly become one of the harder problems in computing as chips have gotten hotter faster than anyone's ability to cool them.

"There's mainly two products we develop. One is called the AirJet. It's sort of a MEMS-based, compact cooling solution for portable electronics. And then we also have our LiquidJet product, which is our cold plate solution for cooling chips in data centers."

The engineer we spoke to works on the core technology behind LiquidJet, the direct-to-chip coldplate Frore builds for data center GPUs. It's demanding work by any measure. Frore's LiquidJet specifications claim 600 W/cm² of hotspot cooling at a 40°C inlet, GPUs running 7.7°C cooler on NVIDIA's Blackwell Ultra, and headroom for parts drawing more than 4,000 watts. Getting there means an enormous amount of conjugate heat transfer simulation.

His toolkit is, in his description, the standard one: some CAD, a lot of CFD, a lot of data analysis and processing, and a lot of coding around all of it.

Before: everything in series

Ask what the work looked like before Cosmon and the answer is short.

"Before Cosmon, I guess obviously we drove everything manually. By everything, I mean CAD and CFD in particular."

Setup, meshing, post-processing, all of it by hand, every time. And the cost wasn't any single slow step. It was the shape that hand-driven work forces on a project: one thing, then the next thing, then the next. A queue of one.

That's the real expense, and it's the one that doesn't show up on a line item. An engineer with three questions to answer doesn't answer three questions; he answers one, waits, answers the second, waits. The program moves at the speed of the slowest serial path, and everything downstream inherits that pace.

In practice that means rebuilding a mesh after a geometry tweak, waiting for it to converge, then rerunning the boundary condition sweep from scratch. Each step takes hours. Each waits on the last. A full parameter study that could inform a decision sits days out.

The second problem: knowing what you want and not where it lives

The other constraint was different in kind, and anyone who has switched simulation packages will recognize it immediately.

"I have the basic theoretical background of doing CFD, but I have a lot less practical software-specific knowledge on how to do certain things, like where's this setting in this menu, and all that."

This is worth sitting with, because it's a strange kind of bottleneck. The engineering isn't the hard part. The physics is understood, the problem is well-posed, the answer would be recognizable on sight. What stands in the way is menu archaeology, knowing which of several hundred settings in a particular vendor's interface corresponds to the thing you already know you need. It is also why AI that works above individual platforms matters.

"It almost completely eliminates the barrier of entry to any new piece of software, as long as it's supported by Cosmon. So that's the case for a good number of my colleagues especially."

Note the last clause. This isn't one engineer's personal gap. It's the tax every team pays whenever the right tool for a problem happens to be a tool nobody on the team has mastered.

How it started

Not with a search. There was no evaluation, no vendor shortlist, no bake-off.

"Initially I wasn't really looking for one. One of my colleagues was approached by you guys (I don't remember how) and so he said take a look. But I somehow ended up being the main person driving Cosmon usage here."

What made it land was timing. He'd started using Claude Code seriously around the same moment:

"That sort of really opened my eyes on how powerful some of these tools can be. So that's when I really sort of dug into Cosmon."

Having seen what an agentic tool could do inside a codebase, the question of what one could do inside a CFD workflow stopped being abstract.

After: the line becomes a fan

Parallelization: the queue becomes a fan

The change he names first, and returns to throughout, is parallelization.

"It allows me to basically parallelize a lot of paths that I generally would have to do in series."

That single sentence contains the whole economic argument. Work that had to be queued can now be dispatched. The engineer stops being the bottleneck his own throughput creates, and starts being the person who decides what's worth running, which is the job he was hired to do.

A second kind of advantage: thinking out loud

But he was careful to say that treating it purely as a throughput tool undersells it:

"It's more than a productivity boost. It's also a tool that can help me discuss with a copilot some technical details about the problem at hand. So beyond helping run things, it can also provide ideas and feedback."

Two different kinds of advantage, and the second one is easy to miss. One is about doing the same work faster. The other is about having somewhere to take a question at the moment you have it, instead of holding it until a colleague is free (a distinction worth reading about in the copilot vs. agent distinction).

An unexpected use: the work around the work

The most interesting thing he described wasn't a simulation at all.

"CFD isn't the only thing you can use it for. You can kind of use it for what I would call CFD-adjacent paths as well, to sort of help you do CFD better."

His example: he runs most of his CFD on an HPC cluster, which means a constant stream of job submission scripting and automation around every actual solve.

"It's setting up a lot of the automated job submission and things like that. Doing it all in Cosmon is convenient, because that's primarily how the solver is scripted."

This is the kind of use case that doesn't appear in any product roadmap because it isn't glamorous. It's the scaffolding labor that surrounds simulation: the scripts, the submissions, the plumbing between a question and a result. It's also, for anyone running CFD at scale, a genuine share of the week. Run a parameter sweep across dozens of inlet temperatures and flow rates, and that submission scaffolding multiplies with it, one script per job, each one hand-written before Cosmon.

What it adds up to

He was careful about the limits of his own vantage point. His role, he noted, isn't senior enough to speak to company-wide impact. What he could speak to was the logic of it:

"If you can do things faster, you can move faster, and that just trickles down to everything. And especially with a startup, speed of execution is everything."

Asked directly whether it had helped optimize parts of the LiquidJet development process that would otherwise have been out of reach, the answer was immediate: "Oh, absolutely." In practice, that meant the team could iterate on coldplate thermal designs faster than the NVIDIA Blackwell architecture hardware schedule would have otherwise allowed. For a broader look at where these workflows apply, see engineering AI agent use cases.

Asked what he'd tell a colleague considering it:

"I'd ask what you actually work on first. But after that, if I think it would be relevant to you, I would absolutely recommend it."

And more plainly, on who it's for:

"I think if you're a mechanical engineer doing CFD, I absolutely would recommend it."

His advice to anyone evaluating

We asked for closing thoughts. What we got was the most useful thing he said all conversation, and it's aimed squarely at people still deciding:

"There's really no reason not to try. The setup is incredibly simple. You just install this one thing where you have your CFD software, and you're pretty much ready to go. And especially if you have used something like Claude Code, this is getting closer to what Claude Code can do for coding, but for CFD. So any prospective customer, you're just potentially missing out on something that could be valuable to you if you don't even try it."

The comparison is the part worth keeping. Engineers who have already felt what an agent does inside a codebase don't need the concept explained. They need to know it exists for the tools they actually use.

Cosmon gives hardware engineers a plain-English interface to the simulation tools they already own, so the engineer who understands the problem is the one who can run the analysis.

FAQ

Can I use Cosmon for CFD workflows without deep knowledge of a new simulation package?

Yes. Cosmon accepts plain-English prompts, so if you understand the physics but not where a specific setting lives in a new solver's interface, you can describe what you need and Cosmon finds it. The Frore Systems engineer using it described this as "almost completely eliminating the barrier of entry to any new piece of software, as long as it's supported by Cosmon."

What's the best way to run parallel CFD parameter sweeps without rebuilding everything manually each time?

Dispatch your paths through Cosmon instead of queuing them by hand. Instead of waiting for each mesh rebuild and boundary condition sweep to finish before starting the next, you can script and submit multiple runs concurrently, with HPC job submission scripting handled alongside the solves themselves.

How does Cosmon handle HPC job submission scripting for CFD workflows?

Cosmon generates and submits HPC job scripts directly, so the scaffolding labor around each solve, one script per job in a parameter sweep, gets automated instead of hand-written. For engineers running CFD at scale across dozens of inlet temperatures or flow rates, that scripting overhead compounds quickly, and Cosmon handles it in the same environment where the solver is already scripted.

Cosmon vs. Claude Code for CFD and simulation work?

Claude Code works inside a codebase; Cosmon works inside simulation tools like Star-CCM+, Ansys, and Abaqus. The Frore Systems engineer who uses both put it plainly: Cosmon is getting closer to what Claude Code does for coding, but for CFD. If you've already seen what an agent does in a codebase, the concept translates directly to your simulation workflow.

How long does Cosmon take to set up for CFD work?

Setup takes one to two hours. You install one add-in alongside your CFD software and you are ready to go, with no weeks of training required before you can run meaningful work through it.