---
title: "Attritable systems are an engineering discipline"
description: "Attritable is not cheap or expendable. It is a design posture — and the hard part is running physical AI on low-SWaP-C hardware you can afford to lose."
pubDate: 2026-07-07T00:00:00.000Z
author: "Destack"
lang: "en"
audience: "defense"
depth: "advanced"
brief: "CB-001"
keywords: ["attritable systems", "physical AI", "low SWaP-C", "edge inference", "vision-language-action", "affordable mass"]
tags: ["attritable", "swap-c", "physical-ai", "edge-ai", "uxs", "defense"]
---
## TL;DR

"Attritable" is not a discount and it is not a synonym for "expendable." It is a
design posture: you accept a higher risk of losing the system because it is cheap
enough to lose and still capable enough to matter. On modern platforms "capable"
increasingly means physical AI — embodied models that perceive and act — and
getting that intelligence to run inside a low-SWaP-C budget is the hard
engineering problem, not the cost target itself.

## The word is a distraction

Most of the public argument about attritable systems is an argument about a word.
The Air Force has spent two years trying to stop saying it, and program leaders
now prefer "affordable mass" precisely because "attritable" got read as
"disposable."

The distinction that matters is loss tolerance, and it is a spectrum of cost. In
the Collaborative Combat Aircraft debate, one framing put it plainly: an
_expendable_ system at roughly \$3M is built to be used once; an _attritable_
system at roughly \$10M is reusable, but its occasional loss in combat is
acceptable; an _exquisite_ system at roughly \$25M is one whose loss is not
acceptable. The Congressional Research Service is careful: attritable systems are
"comparatively low-cost systems with which DOD tolerates a greater degree of risk
of system loss" — not throwaways, typically fielded on a three-to-five-year
horizon.

So the taxonomy is really a cost-tolerance scale. That is the useful part, and it
is where the engineering starts.

## Why the math forces it

The strategic driver is an exchange-rate problem. When a defender can generate
large volumes of low-cost systems, the cost-exchange ratio turns against the side
fielding a handful of expensive, irreplaceable platforms. Analysts now describe
the shift as one "from exquisite scarcity to intelligent mass," and the combat
experience of 2025 made the older assumption — that stealth and sophistication
guarantee survivability — much harder to defend. That thinking is behind the
Pentagon's Replicator initiative, which set out to field thousands of all-domain
attritable autonomous systems and drew directly on lessons from Ukraine.

Note the middle word: **intelligent** mass. Mass alone is just target practice.
The systems have to be autonomous enough to matter without a human on each stick,
which is where the engineering problem moves from the airframe to the compute.

## Attritable is a requirement, not a category

Here is the reframe we work from. When the acceptable loss cost of a system drops,
unit cost stops being a procurement outcome and becomes a design input — co-equal
with range, payload, and endurance. SWaP-C has always listed Size, Weight, Power,
and Cost together. On an attritable program the C finally carries the same weight
as the other three.

That sounds obvious and it is routinely ignored. "Design to cost" is easy to write
in a requirements document and hard to hold when every subsystem review wants to
add capability. Treating cost as a first-class constraint is a discipline, and it
shows up in the boring decisions, not the headline ones. Nowhere more than in the
autonomy.

## The hard part is the intelligence

A cheap airframe is straightforward. A cheap airframe that carries physical AI —
onboard perception, sensor fusion, and increasingly language-conditioned autonomy
— is not.

Physical AI is embodied: vision-language-action (VLA) models and world models that
map what a machine senses to what it does. They are also, today, memory- and
compute-hungry. A 2025 survey of efficient VLA models opens by naming the
conflict directly — their "massive computational and memory demands ... conflict
with the constraints of edge platforms ... that require real-time performance"
([Guan et al., 2025](https://arxiv.org/abs/2510.17111)). On an attritable platform
that conflict is the whole problem, because the compute budget is set by a power
budget that is set by a cost and endurance target.

The framing we find most useful comes from a 2026 survey of embodied foundation
models at the edge, which puts it bluntly: deployment is "fundamentally a systems
problem, not just a problem of model compression," bound by "strict size, weight,
and power constraints" where memory bandwidth, compute latency, and safety margins
interact. It even separates the failure modes — autoregressive VLA policies are
limited mostly by memory bandwidth, diffusion-based controllers by compute
latency. You do not solve that by shrinking a model in isolation. You solve it by
co-designing the model, the accelerator, and the control loop together, which is
the same discipline attritable demands everywhere else.

## It is tractable — with the right engineering

"Run capable autonomy on cheap hardware" is a solved-in-principle problem that a
lot of recent work is turning into practice:

- **On-device VLAs are getting real.** LiteVLA-Edge runs a 4-bit-quantized
  vision-language-action model fully on a Jetson Orin-class module at roughly
  150 ms per decision (about 6.6 Hz), with no reachback.
- **Classic perception already flies onboard.** AERO puts YOLO detection with
  TensorRT on a Jetson Xavier at about 15.5 FPS on a UAV
  ([Koubâa et al., 2023](https://doi.org/10.3390/rs15071873)).
- **Compression is a lever, not magic.** Action-chunk discretization let
  QUART-Online reach controller-rate inference and lift task success by 65%
  ([Tong et al., 2024](https://arxiv.org/abs/2412.15576)); INT8 quantization and
  pruning routinely cut edge inference latency and energy by 20–30%.
- **The subfield has a name.** "Tiny robot learning" — machine learning on
  low-cost, resource-constrained robots — is defined by exactly the "size, weight,
  area, and power (SWaP) constraints" attritable programs live under
  ([Neuman et al., 2022](https://doi.org/10.1109/AICAS54282.2022.9870000)).

The techniques are known: quantization, pruning, distillation, hardware-aware
architecture search, action compression. Applying them so a model still meets the
mission on the specific processor you can afford, at the power you can carry, is
the engineering.

## The architecture question: what runs when the link is gone

There is a tempting shortcut: keep the big model off-board and stream to it. Recent
work like [AsyncVLA](https://arxiv.org/abs/2602.13476) does exactly that — a large
foundation model on a workstation for slow semantic reasoning, a lightweight
onboard adapter for fast reactive control. The fast/slow split is right.

But attritable systems earn their keep in contested, comms-denied environments —
the same conditions that make you willing to lose them. If the reachback link is
jammed, whatever intelligence is not onboard is not there. For this class of
system the requirement inverts: assume the link is gone, and make the onboard
autonomy carry the mission by itself. That pushes more of the physical AI onto the
low-SWaP-C processor, and makes compute-under-budget the central problem rather
than an optimization.

## What it takes in hardware

Cost-to-field at volume is won or lost in the bill of materials and the process
that builds it, and increasingly in the compute you can afford to carry:

- **Design to cost from the first schematic.** The BOM is a requirement, not a
  report. Every part earns its place against a target unit cost.
- **Set the power budget first.** Power drives compute, compute drives how much
  autonomy runs onboard, and endurance falls out of both. On a physical-AI payload
  it is the constraint that decides which models are even on the table.
- **Buy commercial where it survives the environment; ruggedize only what must
  be.** Blanket MIL-spec on every component is how an attritable system quietly
  becomes an exquisite one.
- **Build for manufacturability at thousands, not tens**, and keep interfaces
  **open and modular** (MOSA) so a payload — or an accelerator — can change without
  a board respin.

## What it takes in software

The software has to assume the hardware is cheap, changing, and occasionally lost:

- **Autonomy inside a power and compute budget.** Edge inference on a
  SWaP-constrained processor is a different problem than a model in a datacenter;
  pretending otherwise is how programs miss their endurance numbers.
- **Assume loss.** Nothing irreplaceable lives on the airframe. Graceful
  degradation, fleet behavior over single-unit heroics, no secret whose capture
  would matter.
- **Portability across a moving BOM.** When the cost target forces a part or
  accelerator swap mid-program, the autonomy stack should ride open interfaces and
  come along without a rewrite.
- **Assurance that scales to mass.** Test and verification have to hold across a
  production run of thousands — including the behavior of a compressed model, which
  is not identical to the one you trained.

## The trap: cheap is not attritable

The failure mode we see most is the one that sounds like success: make it cheap.
Cheap without capability is just money you lost faster. Attritable means cheap
_enough to risk_ and capable _enough to matter_ — at the same time — and on a
modern system "capable" is carried by the physical AI onboard. Holding both ends
of that is the actual engineering problem, and it is where most "low-cost drone"
efforts quietly fall off one side or the other.

That balance is the work. It is also, once you take the cost term seriously, what
"low SWaP-C" has meant all along.

## What's next

Engineering systems where cost-to-field is a first-class requirement — and where
physical AI has to run inside the power budget — across defense, uncrewed
platforms, and the physical edge, is the work we do. If the C in SWaP-C is doing
real work in your requirements, [get in touch](/contact).

## References

- Guan, W. et al. (2025). _Efficient Vision-Language-Action Models for Embodied Manipulation: A Systematic Survey._ [arXiv:2510.17111](https://arxiv.org/abs/2510.17111)
- Grover, U. et al. (2026). _Embodied Foundation Models at the Edge: A Survey of Deployment Constraints and Mitigation Strategies._
- Neuman, S. M. et al. (2022). _Tiny Robot Learning: Challenges and Directions for Machine Learning in Resource-Constrained Robots._ [DOI:10.1109/AICAS54282.2022.9870000](https://doi.org/10.1109/AICAS54282.2022.9870000)
- Tong, X. et al. (2024). _QUART-Online: Latency-Free Large Multimodal Language Model for Quadruped Robot Learning._ [arXiv:2412.15576](https://arxiv.org/abs/2412.15576)
- Hirose, N. et al. (2026). _AsyncVLA: An Asynchronous VLA for Fast and Robust Navigation on the Edge._ [arXiv:2602.13476](https://arxiv.org/abs/2602.13476)
- Koubâa, A. et al. (2023). _AERO: AI-Enabled Remote Sensing Observation with Onboard Edge Computing in UAVs._ [DOI:10.3390/rs15071873](https://doi.org/10.3390/rs15071873)
- Williams, J. et al. (2026). _LiteVLA-Edge: Quantized On-Device Multimodal Control for Embedded Robotics._