Your robots meet conditions no dataset predicted — new sites, new lighting, new terrain, new seasons. Basal Runtime lets each robot adapt its own perception on the hardware it already runs, so the fleet gets more accurate the longer it operates.
An on-device continual learning runtime for Physical AI.
Basal Runtime is a hardware-agnostic runtime that runs alongside the perception model you already trained. It is a continual learning runtime: it keeps your model accurate as the environment shifts, applying small, bounded updates directly on the device — with no round-trip to a cloud to collect data, label it, retrain, and redeploy. You keep full control of your model. Basal Runtime is the layer that keeps it current.
A perception model is accurate on the day you ship it and starts drifting the moment it meets the real world. Every new deployment — a different farm, warehouse, mine, season, or lighting condition — shifts the data distribution the model was trained on. The standard fix is to gather field data, label it, retrain in the cloud, validate, and push a new model to every device. That loop is slow, and its cost grows with every robot and every environment you add. Across a large, heterogeneous fleet, the MLOps cost of keeping every model current stops scaling.
Our approachBasal Runtime closes that loop on the device. Your trained model stays frozen; Basal Runtime wraps it in a lightweight runtime that applies small, tightly bounded updates in the field, adapting the model to the conditions each robot actually sees. The updates are constrained by design to fit a strict compute and memory budget and to protect what the model already knows, so adaptation does not come at the price of forgetting. Because it runs over ONNX Runtime, the same runtime deploys across the ARM, Intel, and NVIDIA processors already in your robots — you do not change your hardware or your model to get continual learning.
Each robot adapts to its own site, not to a fleet average.
No data pipeline back to the cloud just to keep models current.
One runtime across mixed hardware.
Works where connectivity is unreliable or absent.
Basal Runtime works alongside the system you already use — like ROS2 — adding the autonomy layer on top, without replacing anything that's already running.
each robot adapts to its own environment
Basal Runtime wraps your frozen perception model in an on-device adaptation loop. Each robot learns from the conditions it actually sees and keeps its predictions accurate — without a retraining round-trip to the cloud.
Basal Runtime is an on-device continual learning runtime for autonomous robot fleets. It is a hardware-agnostic runtime that runs alongside the perception model you already trained and keeps that model accurate as conditions in the field change. Instead of sending data back to a cloud to be labeled and used for retraining, Basal Runtime applies small, bounded updates directly on the robot. The result is a fleet whose models stay current on their own, on the hardware already deployed. Basal Runtime does not replace your model or your stack — it is the adaptation layer that sits on top and keeps everything working as the real world drifts away from your training set.
Edge Autonomy, in the Physical AI sense, is a robot's ability to keep operating correctly without a human or a cloud service constantly correcting it. Most “autonomous” robots today are only autonomous at inference time: they run a fixed model, and when the world changes they wait for engineers to collect data, retrain, and redeploy. True Edge Autonomy means the system also adapts — it improves its own perception in response to the environment it is actually in, on the device, in real operating conditions. That is the layer Basal Runtime provides. It turns a static model that degrades over time into one that adjusts to each robot's site, which is what AI Autonomy has to mean once a fleet is spread across many different environments.
Cloud retraining is a batch loop: collect field data, move it to a server, label it, retrain the model, validate it, and push it back to every device. It works, but it is slow and its cost climbs with every robot and every new environment. Basal Runtime moves adaptation to where the data already is — the device — and does it continuously, in small bounded steps, without a labeling or data-transfer pipeline. You still own and version your base model; cloud retraining and Basal Runtime are complementary. Many teams keep periodic cloud retraining for large changes and use Basalostat to absorb the constant, local drift in between.
No. Basal Runtime is deliberately model-agnostic and non-invasive. Your trained model — your architecture, your weights, your training data — stays yours and stays frozen. Basal Runtime wraps it in a runtime that applies adaptation on top, so you are never handing over your core IP or rebuilding your perception stack to adopt it. If you remove Basal Runtime, you are back to your original model. This matters most for teams who have invested heavily in their own perception and are not looking to swap it out, only to keep it accurate in the field.
Basal Runtime runs over ONNX Runtime, which makes it hardware-agnostic across the processors common in field robotics — ARM, Intel, and NVIDIA — under constrained memory. The same runtime and the same integration work across mixed fleets, so you are not maintaining a different build for every board. It ships as an SDK you integrate into your existing pipeline rather than a separate appliance or a hosted service. That design is intentional: continual learning is only useful at fleet scale if it deploys on the hardware you already have, without a hardware refresh.
Yes. Basal Runtime runs fully on the device and does not need a connection to keep the model learning — adaptation happens locally, in the field, whether or not the robot is online. When connectivity is available, it can sync telemetry and observability data so you can see how the fleet is behaving; when it is not, the robot keeps adapting on its own. This makes it a fit for agriculture, mining, and remote industrial sites where connectivity is intermittent or absent and a cloud-dependent update loop simply is not an option.
That is the central risk in any continual learning system, and it is what Basal Runtime is built to control. Updates are small and tightly bounded by design, and they are constrained to protect what the model already knows, so the goal is adaptation to new conditions without erasing prior performance. It is not an open-ended fine-tuning process running loose on the robot; it operates within a strict budget with guards against the model drifting in the wrong direction. The design intent is that a robot ends up more accurate for its own environment, not less accurate overall. Validating these guarantees on real customer workloads is exactly what our pilot program is for.
Basal Runtime is built for teams that have their own perception model but no infrastructure to keep it current across a growing, heterogeneous fleet — typically robotics manufacturers and integrators in field autonomy. If your models are accurate in the lab and in the first deployment but degrade as you add sites, seasons, and conditions, and if cloud retraining is becoming a cost and logistics bottleneck, you are the intended user. It is less relevant if your robots operate in a single controlled environment that never drifts, or if you do not run a learned perception model at all.
By default, nowhere off the robot. Adaptation happens on the device, so the raw sensor data a robot uses to keep its model current never has to leave that robot. Only the telemetry and observability data you choose to sync — not the underlying imagery — moves off-device, and only when you have connectivity and opt in. For customers in sensitive or regulated environments, keeping field data local by design is often as important as the accuracy benefit itself.
Start with the technical documentation to see how Basalostat integrates with your existing ONNX pipeline, then request a pilot. A pilot runs the runtime against your model and one of your real deployment environments, so you can measure adaptation on your own workload rather than on a benchmark. Because Basalostat is non-invasive and hardware-agnostic, integration does not require changing your model or your hardware, which keeps the evaluation low-risk. From there, we scope a rollout with you.
We're onboarding a small group of developers and fleet operators — by invite.
Basalostat Edge Autonomy