An interactive multi-drone autonomy simulation powered by TypeSafe Jev, exploring a simple question: what happens when fast, typed System 1 reflexes can ask a slower System 2 reasoning model for advice without giving up control?
The fleet size is configurable from one to twenty drones. System 2 can be turned off entirely, making it easy to compare Jev operating independently against Jev augmented with strategic guidance.
Each drone navigates independently with Jev as its System 1 reflex layer. When confidence falls below the configured threshold, an optional System 2 planner provides one-use strategic guidance through OpenRouter. Jev keeps steering while the planner responds.
- A configurable fleet of one to twenty independently controlled drones
- Moving asteroids, debris, unknown signals, and other drones treated as sensed contacts
- A System 2 toggle for running Jev alone or enabling strategic advice
- Per-drone decisions, confidence, latency, strategy revisions, and collision outcomes
- Seeded scenarios for repeatable obstacle layouts
- Canvas rendering separated from React telemetry and controls
- JSON export for inspecting an entire mission after the run
If one drone collides, only that drone is removed. The remaining fleet continues toward the shared destination. Arrived drones leave the active flight lane.
React dashboard
├── experiment controls
├── per-drone telemetry
└── decision and latency charts
Canvas simulation loop
├── movement and collision detection
├── sensors and action projections
└── fleet rendering
System 1 — TypeSafe Jev
└── fast typed action decisions for every active drone
System 2 — OpenRouter / GLM 5.3
└── asynchronous one-use strategy advice when confidence is low
System 2 is advisory. It does not fly the drone directly, and Jev does not while waiting for it. The confidence chart uses purple only for a Jev decision that actually consumed returned System 2 guidance. The System 2 chart marks response arrival as a discrete event; wall-clock duration is shown separately in the latency chart.
Requirements: Node.js 22.13 or newer.
npm install
npm run dev
Open the printed local URL. The app starts with development mocks, so it works without provider credentials.
Useful checks:
npx tsc --noEmit
npm run lint
npm run build
Copy the example configuration and add your own keys:
cp .dev.vars.example .dev.vars
TYPESAFE_API_KEY=your_key
OPENROUTER_API_KEY=your_key
OPENROUTER_MODEL=z-ai/glm-5.3
Restart the development server, refresh provider status in the dashboard, and select TypeSafe Jev and OpenRouter. .dev.vars is ignored by Git; never expose these credentials through NEXT_PUBLIC_ variables.
The Jev adapter calls POST https://api.typesafe.ai/v1/systemone with jev-latest and a typed choice over the available flight actions. The System 2 planner uses OpenRouter's chat completions API with strict structured output. Server errors, rate limits, and context-size failures can retry through the configured fallback model.
- Choose the fleet size and scenario.
- Turn System 2 advice on or off.
- Select mock or live providers.
- Adjust the confidence threshold.
- Launch the mission and switch between drones to inspect their decisions.
- Export the mission JSON for deeper analysis.
The scenario seed controls the obstacle layout, but live provider latency can still change a trajectory. A seed is repeatable geometry, not a deterministic asynchronous replay.
- Green confidence: Jev made the decision using its current local context.
- Purple confidence point: that Jev decision consumed newly returned System 2 guidance.
- Purple System 2 bar: advisory response arrived at that mission time.
- Red System 2 bar: advisory request failed.
- Latency chart: measured wall-clock provider response time.
Exported telemetry includes the seed, fleet state, observations, probabilities, executed actions, confidence thresholds, provider timing, planner revisions, failures, and final outcomes.
This is an experimental autonomy visualization, not a production flight controller. The mock scenario and focused runtime checks cover the core simulation behavior. Live fleet success varies with model decisions, provider latency, seed, threshold, and fleet size.