Blog
From Robot Runtime to Research Node:
How OpenCastor Turns Idle Robots Into a Harness Optimizer
March 19, 2026 · Updated March 21, 2026 · Craig Merry
"How long before someone launches SETI@Home but the AGI era?"
— Chris Albon (@chrisalbon), Director of ML at Wikimedia Foundation
March 19, 2026
What is OpenCastor?
Before the feature, some context. OpenCastor is an open-source runtime layer that sits between a robot's hardware and its AI. It doesn't prescribe what your robot looks like. A Raspberry Pi on a desk. A ROS2 rover with a Jetson. A warehouse AGV running Ubuntu. An educational arm in a classroom. If it has a compute board and can run Python, OpenCastor can be its runtime.
It handles what every robot needs but nobody wants to build from scratch: authentication and access control, safety invariants, telemetry streaming, agent harness management, skill execution, and a standardized API. You bring the hardware and the AI model. OpenCastor connects them safely.
The entire project is open source on GitHub.
RCAN: The protocol robots speak
OpenCastor implements the RCAN specification — the Robot Communication & Authentication Network. RCAN is an open protocol that defines:
Robot URI (RURI)
A canonical identifier for every robot — like a URL for physical machines. rcan://registry/manufacturer/model/version/serial
Scopes & Permissions
A hierarchy of access levels: discover, status, chat, contribute, control, safety. A guest can check status but can't drive motors.
Message Types
Standardized commands, responses, telemetry, and safety signals — 35+ message types that work across any RCAN-compatible robot.
Safety Invariants
Protocol-level guarantees like P66 (priority preemption) enforced in code, not prompts. Lower-priority work always yields to commands.
RCAN is maintained by ContinuonAI with reference SDKs in Python and TypeScript.
The Robot Registry
Every OpenCastor robot registers with a canonical identity. Each gets a unique RRN (Robot Resource Name), live telemetry streaming, and fleet-level visibility through the OpenCastor client app. The registry is an abstraction — our reference uses Firebase Firestore, but you can back it with any database.
This registry is what makes fleet coordination possible. You can't coordinate idle compute across robots if you don't know what robots exist, what hardware they have, and whether they're busy.
The SETI@Home parallel
SETI@Home ran from 1999 to 2020. At its peak, 5.2 million volunteers donated their home PCs. Folding@home proved it could do real science during COVID-19. But both relied on humans installing software on personal computers. Robots are different.
An OpenCastor robot — any OpenCastor robot — is already networked, already authenticated, already reporting telemetry. It might have a Hailo-8L doing 26 TOPS, or a Coral TPU doing 4, or a Jetson Orin doing 40, or just a 4-core ARM CPU. The runtime detects whatever hardware is present and profiles it automatically. The coordinator matches work to capability.
The idle compute problem
Robots idle. A lot. Our reference robot "Bob" idles about 20 hours a day, but that's true of most robots — they spend the majority of their time waiting for commands, charging, or standing by. Whatever compute they have goes to waste.
The raw numbers depend on fleet composition. A fleet of NPU-equipped robots contributes more raw TOPS. A fleet of CPU-only robots contributes less per-unit but still adds up. The point isn't any single robot's specs — it's that the aggregate waste across a fleet of heterogeneous robots is significant, and the infrastructure to coordinate it (RCAN, registry, telemetry) already exists.
What castor contribute does
Enable it in your robot's config:
After the idle threshold, the runtime fetches a candidate harness configuration from the research queue, evaluates it against real robotics benchmark tasks (see OHB-1 below), and submits the score. The moment a real command arrives, the work unit is cancelled within 100ms and the robot returns to full duty.
Hardware-agnostic by design
The hardware profiler detects what's available and reports it to the coordinator:
NPU-equipped robots
Hailo-8L (26 TOPS), Coral TPU (4 TOPS), etc. Get NPU-optimized inference work units — model scoring, classification, object detection.
GPU-equipped robots
Jetson Orin, CUDA GPUs. Get batch inference or training work units that leverage GPU compute.
CPU-only robots
Any ARM or x86 board. Get CPU-appropriate tasks — data preprocessing, lightweight inference, aggregation.
Sensor-equipped robots
Cameras, microphones, depth sensors. Could contribute situated data — BirdNET bioacoustics, species identification, environmental monitoring.
What your robot is actually doing
🤖 Harness Design Research LIVE
The only active project today. Every OpenCastor robot is searching a space of 263,424 possible harness configurations to find the optimal AI agent setup for robotics tasks. Each work unit evaluates one candidate config against 30 real scenarios using OHB-1, our open benchmark. As of March 2026, contributors have explored 435 configurations (0.17% of the space) and the current champion scores 0.6541 on the benchmark — a real number, on a real model.
🌍 Climate Modeling Planned Q3 2026
climateprediction.net runs ensemble climate simulations — thousands of independent models, embarrassingly parallel, ~15 minutes each. We're building a real BOINC client integration, not a placeholder. Target: Q3 2026.
🧬 Protein Folding Planned Q3 2026
Rosetta@home work units involve scoring protein conformations — pure matrix math that NPUs and GPUs excel at. Edge inference at a fraction of the power cost of data center GPUs. BOINC integration planned alongside climate modeling.
Safety: P66 preemption
CONTRIBUTE_CANCEL
to the coordinator and returns to full duty within 100ms. This is enforced at the runtime level and
cannot be disabled by configuration.
The contribute scope sits at level 2.5 in the RCAN hierarchy — above chat (2)
so conversation doesn't interrupt computation, but below control (3) so any real command
takes immediate priority. Science gets the leftovers. In a fleet of idle robots, the leftovers add up.
The full ecosystem
What makes this different from "just run BOINC on a computer" is the integration across an open-source robotics stack — protocol, runtime, SDKs, client app, and registry working together:
| Layer | Component | What it does |
|---|---|---|
| Protocol | RCAN v1.9 | contribute scope, Castor Credits protocol, telemetry schema |
| SDKs | rcan-py / rcan-ts | Message types, scope validation in Python & TypeScript |
| Runtime | castor/contribute/ | Coordinator, runner, hardware profiling, fleet coordination |
| API | REST endpoints | /api/contribute, /start, /stop, /history |
| CLI | castor contribute | Status, start, stop, history from terminal |
| Client | Flutter app | Real-time stats, enable/disable toggle, project selection |
| Registry | Firestore telemetry | Live contribution stats visible across the fleet |
OHB-1: The benchmark that makes it real
We didn't want to optimize against a simulated score. So we built OHB-1 (OpenCastor Harness Benchmark v1) — a real, reproducible benchmark that runs on-device using a local language model (gemma3:1b via Ollama). No API cost. No cloud dependency. Same model on every robot.
30 real tasks
10 home scenarios (navigation, manipulation, safety), 10 industrial (inspection, emergency response, coordination), 10 general (planning, error recovery, reasoning).
4 scoring dimensions
Task success (40%), P66 safety compliance (30%), cost efficiency within the harness cost_gate_usd (20%), latency vs. deadline (10%).
Reproducible
Same config + same task → deterministic enough for comparison. Low temperature (0.1) keeps variance minimal across runs on the same hardware.
Current baseline
Champion lower_cost scores 0.6541. 21/30 tasks passed. Three tasks time out — complex multi-step planning hits the 30s wall. That's the target for the next champion.
The benchmark spec is published in opencastor-autoresearch.
You can run it yourself: python -m harness_research.run --benchmark.
The current champion config and score are always at
opencastor-ops/harness-research/champion.yaml.
Live now: Community-tuned harness configs
This isn't "coming soon" anymore. Every robot already broadcasts its
hardware_tier — pi5-hailo, pi4-8gb, server,
and so on. The research pipeline uses that metadata to match work units to hardware profiles
and build champion configs that are specific to your setup.
When your Pi 5 + Hailo-8L robot idles, it runs harness evaluation scenarios tuned to its exact hardware combo. How aggressive
should thinking_budget be when the NPU is handling inference? What context_budget
saturates the memory bandwidth? What retry policy actually improves outcomes on a robot with 100ms camera
latency? These questions have hardware-specific answers, and only a fleet of real robots can answer them.
| Hardware profile | Key tunables explored | What contributors unlock |
|---|---|---|
| Pi 5 + Hailo-8L NPU | nexa_enabled, thinking_budget, NPU model routing | Optimal on-device inference split between NPU and cloud |
| Pi 5 · 8 GB (no NPU) | context_budget, fast_model selection | Best local model for each task class without NPU offload |
| Pi 4 · 4 GB | cost_gate_usd, aggressive thinking_budget floor | Minimal-cloud config that still produces reliable behavior |
| Waveshare ALPHA | Arm-manipulation HITL thresholds, retry policy | Consent + safety gates tuned to physical manipulation latency |
| Unitree Go2 | Gait-aware drift detection, parallel fork config | Navigation harness that doesn't fight the onboard locomotion stack |
| Server-class (Jetson, x86) | Higher context_budget, multi-model tiers, parallel branches | Full-power harness that saturates available VRAM without waste |
The nightly pipeline finds the winning config across all contributors and stores it as a pending update for each robot. You decide when to apply it — per robot, or fleet-wide. Champion configs are never pushed automatically. You can also enable auto-apply per robot if you prefer.
- Enable
castor contribute(opt-in, one line) - Your robot's idle cycles run OHB-1 benchmark tasks on candidate harness configs
- Results feed the nightly aggregation pipeline alongside other contributors with the same hardware
- The winning config is stored as a pending update for your robot in the app
- You review it and apply it — to one robot, or the full fleet — on your schedule
- Your contribution stats show which configs your robot helped evaluate and your credit share
This is the flywheel. More contributors → more hardware-specific benchmark data → better harness configs for everyone with that hardware → easier to get good results out of the box → more people adopt OpenCastor → more contributors. The research pipeline improves the default harness. The fleet makes it specific.
The infrastructure already exists
Chris Albon asked how long before someone launches SETI@Home for the AGI era. The answer is: the
infrastructure already exists. OpenCastor gives any robot a standardized runtime. RCAN gives it an
identity and a protocol. The registry gives it fleet visibility. castor contribute is just
the natural consequence — if you have the infrastructure, the idle compute question answers itself.
It's opt-in, it's safe, it's preemptible, and it's open source. Your robot was going to idle anyway. Might as well cure something — and tune your harness while you're at it.