Most "get started" guides ask you to install three things, create an account, and read a concepts page before you see anything move.
Ours asks for one Python file and about sixty seconds.
We just opened the Cascade Dynamics beta, and the fastest way to understand what the platform does is to watch it do it. So instead of a feature tour, here is a walkthrough of the actual quickstart — what runs, what you see, and why the two most important moments are the two where something gets refused.
The local half — no account required
Clone one repository and run one file:
git clone https://github.com/Cascade-Dynamics-AI/hello-swarm
python3 hello-swarm/hello_swarm.pyZero dependencies. Python 3.8+. No key, no signup.
It simulates a fleet of agents crossing a grid — first with no coordination, then with a coordinator — using the same random seed both times, so the only variable is coordination itself. You watch a table fill in:
At six agents, the uncoordinated fleet racks up a couple of collisions. At ten, eleven. At sixteen, thirty-six. At twenty, fifty-one. The coordinated fleet, running the exact same paths: zero, every time.
That collision count climbing superlinearly while the coordinated column stays pinned at zero is the thesis of the company, rendered in about fifteen lines of arithmetic. No model. No tokens. Just a reservation table deciding who yields. It is deliberately small enough to read in one sitting — the point is that coordination is arithmetic, and arithmetic does not get slower, more expensive, or less predictable as the fleet grows.
The live half — a free beta key
Now the same idea, against production. Sign up (no card), create an API key in Settings → API Keys, export it, and run the script again. This time it talks to the real platform, and about fifteen seconds later you will have watched, in order:
Your key becomes a short-lived token. API keys are credentials, not long-lived bearer tokens — the script trades yours for a one-hour token. That is the whole authentication model.
Two simulated ground units spin up. Real device rows, no hardware needed. The simulator uses the exact same adapters and API surface as physical robots, so everything you see here is the production path with the hardware swapped for sim.
A mission is created from one English sentence. "Survey the north field perimeter with two ground robots. Hard ceiling 15 metres." That sentence is the input format. The platform compiles it into a structured, executable mission.
Preflight tells you what would stop the launch. Not after you try — before. The platform surfaces its blockers up front.
Then the two moments that matter.
The first refusal
The script deliberately tries to launch the mission without confirming the safety gates the mission type requires. And the API refuses — with a `400`, and the exact missing gates named: `alt-ceiling`, `no-fly-zones`.
This is intentional, and it is the point. A safety system you cannot watch say no is indistinguishable from one that does not work. Most platforms treat safety as a document — a policy that lives in a PDF and is enforced by hope. Here it is enforced at the moment a command is issued, and you can watch it happen. Confirm the gates, and the same launch succeeds and runs to completion in about ten seconds, every step recorded.
The tamper test
When the run finishes, it produces a signed evidence bundle — an Ed25519 signature over a canonical form of the run record. The script downloads it, fetches the signing key's public half with no authentication at all (that is what makes verification independent rather than a matter of trusting our API), and checks it:
genuine bundle : valid = True
one flipped bit : valid = FalseThat last pair of lines is the product. It is a record of what your autonomous machines did that someone who trusts neither you nor us can verify — and that fails the instant a single bit is altered. If you `pip install cryptography`, the script re-runs the entire verification offline, using its own independent implementation, never asking our servers for an opinion.
What you can do next
Everything in that script uses the same API you would use to drive real hardware. From here, the beta gives you:
- Simulated fleets, instantly, for building and testing coordination logic with no hardware in the loop.
- Plain-language mission planning — the intent-compilation step that turns a sentence into a structured plan.
- The evidence chain on every run.
- Hardware adapters (ROS 2, PX4/ArduPilot) when you are ready to point it at something that actually moves. The pairing flow, conformance suite, and arm/kill live-control gating are the same ones we use to drive TurtleBots in our own lab.
The honest part
It is an early beta. The core is solid — we validated the full signup-to-evidence flow repeatedly with fresh accounts before opening the doors — but you will find rough edges, and we want you to. Every performance number we publish is measured, and the ones we tested and retired are published too. If something looks broken, that is a bug we want to hear about.
The fastest way to disagree with anything we have claimed is to run the sixty-second demo and check. That is the entire point of shipping it as one readable file.