Today, we're introducing nTop Engines, a new way to license nTop. An engine is a core concept of nTop and represents the scalable capability to manipulate geometry and execute trade studies. Teams now license engines instead of seats, and an engineer in the interface, a script, or an AI agent can each put one to work. We're also opening early access to distributed compute, which lets many simultaneous instances of nTop run the same study in parallel on a team's own cluster and produce dozens or hundreds of designs at once.
Introducing nTop Engines
For decades, engineering software has been licensed per seat, on the assumption that the person at the keyboard is where the work happens. That assumption is breaking down. More and more engineering work is done by scripts, optimization studies, and increasingly AI agents, with no one sitting at the interface at all, and a seat count has no way to measure it.
Every nTop notebook is a deterministic program: give it a set of input parameters, and it produces the matching geometry, the same way every time. An engineer can build and run one in the nTop user interface. An MDO study can run it from the command line to generate hundreds of variants. And as we build toward it, an LLM or an agent will be able to author a notebook from scratch and then run it end to end, with no one at the interface.
What all of these have in common is that they need nTop running, and that's what the engine model provides. The nTop GUI is one way to drive it, and the command line interface, a notebook authoring API (currently in development), and agents are others. A team licenses the engines it needs and puts them to work however its programs demand.
Early Access: nTop Orchestrate
nTop Orchestrate runs simultaneous instances of nTop across a team's own compute cluster, so many engines can work on the same study at once. When we talk with customers about their design studies, the model and the plan are usually in good shape, and running the study is where things slow down. Studies still run on one workstation, one variant after another, queued up on Friday and checked on Monday, while cluster or cloud capacity sits idle elsewhere. We're starting with an early access program so we can work closely with a small group of teams running real studies on their own infrastructure, and use what we learn to shape the full release.
Here's how it works. An engineer, an MDO tool, or an agent starts a study using the command-line interface for automation with one nTop notebook and a list of input sets. nTop Orchestrate, a service your IT team deploys on the cluster, queues each variant, hands it to an engine on an available machine, and returns the results organized by variant. Dozens or hundreds of designs come back from a single run, ready to feed an optimization or exploration study. A study can also run our integrated simulation in the loop, so each variant comes back with its analysis results alongside the geometry. It all runs on infrastructure you already have, using your licensed nTop Engine capacity.
That changes what a team can do with a design study in three ways.
Search the whole design space, not a sample of it
Each machine runs one engine, so a cluster with 20 engines works through 20 variants at a time instead of one. A design of experiments on an airframe can cover the parameter range at the resolution the problem calls for. When a payload or thermal requirement changes late in a program, the team can rerun the whole study rather than a hand-picked subset.
Keep engineers working while the study runs
The work happens on the cluster, so an engineer's workstation stays free for the next problem. Results come back organized by variant, with the inputs, outputs, and logs for each, so a failed or surprising case is easy to trace.
Generate training data for surrogate models
A surrogate model is only as useful as its coverage of the design space. Running nTop across a cluster makes it practical to generate thousands of geometries from the same notebook the team designs with, so the training data reflects the design logic already in use.
Today, the number of designs a team can evaluate is tied to headcount and machine hours. nTop running in parallel loosens both limits: engineers spend their time building the model and deciding what to explore, and the cluster handles the volume.
Proven at scale: valid geometry for every variant
The CoreWeave collaboration earlier this year shows what this looks like at real scale, not just in a demo. Working with CoreWeave, nTop set out to test whether NASA's 2030 CFD Vision targets, longstanding benchmarks for computational fluid dynamics throughput, are achievable today. A single engineer built a pipeline that generated 2,400 drone geometry variants and evaluated each at five angles of attack, for 12,000 CFD simulations run across 280 NVIDIA RTX Pro 6000 Blackwell GPUs. Every one of those 2,400 variants produced valid geometry, with zero geometry failures across the full run.
That's the same kind of workload nTop Orchestrate is built for: one nTop notebook, many machines, results organized and returned automatically. What took a dedicated engineering effort to set up for the CoreWeave benchmark is the kind of study we want early access teams running on their own programs, without that setup work.
Get started with nTop Engines and distributed compute
We're inviting a small group of engineering teams into early access for nTop Orchestrate. The best fit is a team with a study that's too big for one workstation, and a cluster or cloud capacity their IT team can deploy to. Participants work directly with our engineering team and help shape what ships. If that sounds like your team, apply for early access, or talk with us about how nTop Engines fit your program.
