Bands

List the currently offered bands and, per band, whether strict data handling is supported. Use this to decide which band to select on an agent, thread, or run, and whether to set dataHandling: 'strict'.

A band is a stable named identity for a reasoning/cost envelope. Novo handles the routing behind it (model, delegation, and managed-tool configuration), and the band identity does not change when the underlying routing improves.

Right now 'lite', 'core', and 'frontier' are offered, and 'core' is the default when you don't set one. Future bands may appear in this endpoint when they are publicly offered, so use it rather than hardcoding assumptions about availability.

Methods

| Method | Route | |---|---| | novo.bands.list() | GET /v1/bands |

Type signature

type BandInfo = {
  object: 'band';
  band: 'lite' | 'core' | 'frontier';
  dataHandling: {
    strict: { available: boolean };
  };
};

type BandsNamespace = {
  list(): Promise<Page<BandInfo>>;
};

list() returns the standard Page<BandInfo> envelope and includes only bands that are currently offered. The catalog is static for a given release, so hasMore is always false, nextCursor is null, and limit equals the number of returned bands.

Example

const { data } = await novo.bands.list();

for (const band of data) {
  if (band.dataHandling.strict.available) {
    console.log(`band ${band.band}: strict data handling available`);
  }
}

// Require strict data handling if the band offers it:
await novo.runs.start({ threadId, input: 'sensitive', dataHandling: 'strict' });

Backing model/provider choices are not the public contract: band is the stable selector, and Novo routes each task to the best available configuration for the role. Strict availability is computed from the band's effective strict route, which may differ from its standard route. Strict data handling propagates to subagents.

How bands stay current

Bands exist so model churn is Novo's problem, not yours. When a stronger model ships, Novo re-points the routing behind the affected bands (after integration testing at the model's recommended configuration), and the band name, your API, and the shape of your pricing stay put. You never migrate a prompt chain because a vendor deprecated a model.

Concretely:

• The contract is behavioral, not vendored. A band names a reasoning/cost envelope. What serves it is Novo's routing policy, which improves in place.
• Re-points are release-noted. Material routing changes appear in the changelog; the band identity never changes underneath a running thread mid-run.
• Usage stays provider-neutral. Receipts report a stable, generic modelLabel per resource kind (see Usage), so your dashboards don't churn either.

GET /v1/bands is the whole selection surface: what's offered today, and whether strict data handling is available per band.