# Compute Backend API

Tensormorph's five built-in backends - CPU, WebGPU, CUDA, ROCm, and Metal (see [GPU Backend Compatibility](/docs/reference/gpu-backend-compatibility)) - aren't a closed set. An `AcceleratorBackendPlugin` is how support for an additional accelerator gets added without changing Tensormorph's core scheduling logic.

## What a backend plugin provides

The scheduler that places operations by capability and cost (see [How backend selection works](/docs/reference/gpu-backend-compatibility#how-backend-selection-works)) doesn't know about specific hardware - it knows about backends that can each answer "can you do this operation, and at what estimated cost." An `AcceleratorBackendPlugin` implements that same contract for a new accelerator:

-   Which operations it supports, and at what capability level.
-   A cost estimate for a given operation on that backend, so the scheduler can compare it fairly against the built-in backends.
-   The actual execution path for a supported operation.

## Never hardware-name branching

A backend plugin should never require core Tensormorph code to special-case its hardware by name. Adding an accelerator means implementing the same capability-and-cost contract every other backend implements - if adding your backend required editing Tensormorph's scheduler, something about the plugin contract is being bypassed rather than used.

This is the same principle [GPU Backend Compatibility](/docs/reference/gpu-backend-compatibility) describes for the built-in backends, extended to third-party ones: the scheduler's job is choosing among backends that all speak the same contract, not knowing about any of them individually.

## Partial support is expected

A new backend doesn't need to support every operation Tensormorph can perform on day one - where it lacks a specific capability (a particular quantized kernel, for instance), the scheduler falls back to a backend that does support it, the same way built-in backends already handle uneven kernel coverage. Declaring narrower support honestly is preferable to claiming broad support and failing at runtime.

## Related resources

-   [GPU Backend Compatibility](/docs/reference/gpu-backend-compatibility) - the scheduling model a backend plugin integrates with.
-   [Extension API](/docs/developer-platform/extension-api) - the general plugin ABI and trait system.
-   [Quantized Models](/docs/working-with-models/quantized-models) - a common case of uneven backend kernel coverage.