> ## Documentation Index
> Fetch the complete documentation index at: https://docs.biohub.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# design_binder

> Fields of a design_binder item submitted to the Batch API.

Use [Batch Submit](/api/protein/models/batch_submit) with `endpoint: "design_binder"` and one or more items in `payload`.
One item is one design trajectory: the service picks a starting binder, folds it with the target, and descends a distogram loss.
There is no synchronous design operation, and an item does not name a model.
The schema below describes one payload entry.
See the [Batch API overview](/api/protein/models/batch_overview) for submission, polling, and downloads.

## Limits and validation

| Constraint | Value |
| - | - |
| Target plus binder | At most 680 residues. |
| Target chains | At most 26. |
| Hotspots | Nonempty list of valid chain-local addresses. |

The submission ceiling and the hourly quota are stated on [Batch Submit](/api/protein/models/batch_submit), under `repeat` and the `429` response.
They are generated from the values the service enforces, so read them there rather than here.

The target must leave room for the longest binder the deployed format configuration can produce.
Worker configuration can impose a smaller target limit.
Read the allowed length from the validation error rather than assuming the full complex budget is available to the target.

The recipe steers its losses toward the hotspots and measures the contacts the binder reaches.
An unknown design-payload field is ignored, so a caller-supplied `label`, recipe version, binder length, or trajectory time limit does not configure the run.
`custom_scaffold` is explicitly unsupported and must be omitted or null.

The batch handler checks the envelope and limits; scientific payload validation occurs in the worker.
A `200` submission response can therefore be followed by a failed item with a validation error.