Skip to main content
Team and Enterprise Hosted model jobs run on Nitsor’s managed GPU run plane for Team and Enterprise, counted in model-assisted volumes. Nitsor runs no hosted compute for Community. Each proposal records its model provenance for a person to accept or correct. One model is on the roster: SAM 2.1 (hiera large), Apache-2.0, packaged as a container image published on 13 September 2026 and pinned by digest. It runs as an auto-label stage of a pipeline on a managed GPU run plane in region us. A stage takes one prompt source, points or human-box, and the model works slice by slice with bounded propagation; this execution shape does not run a volumetric model. Runs and Jobs are visible on the Executions page and through the API. Nitsor issues no calibration certificate or calibrated uncertainty guarantee on proposals.

How a stage runs and what its score means

An Auto-label stage names a model Agent, one or more categories, and a prompt source: points (1 to 32 positive and 0 to 32 negative landmarks on one slice) or human-box (a 3D box a person drew). SAM 2.1 is treated as a 2D model with slice propagation: the prompt sits on one slice and the mask propagates forward and backward inside an inclusive window of at most 64 slices. A target whose points spread across slices is not a harder case; it is a shape the model does not take. The Job a stage creates carries no calibration record. The model reports its own score and nothing calibrates it, so the editor marks every proposal the stage lands uncalibrated and says why: “The model reported its own score; nothing calibrated it.”
  • The score is the model’s own confidence. It controls no error rate, and a person still decides every proposal.
  • An uncalibrated run provides no calibrated risk guarantee.
  • The marker is an editor feature. The API’s Job records carry no calibration field.

What a Run costs and who confirms it

A Job is dispatched as a Run on the managed run plane. The image pin fixes the GPU class (L4), the cap (1800 seconds) and the confirmation ceiling (300 seconds). A Run moves through queued, pilot, quoting, awaiting-confirmation, running, draining and ends completed, completed-partial, failed or capped. Confirming a Run above its ceiling and cancelling one (drain or kill) need operate on the project. The Run record in the public contract stores duration (including the billableDuration field), cap, ceiling and its quote in seconds; these are internal cost and resource measures, not customer prices. Provider usage, invoices, raw logs and aggregate metrics are marked unavailable in the contract. The paid-launch billing policy is not active. It counts completed scan/model results under the existing identity and settlement rules, with all objects produced included, rather than slices, masks, objects or elapsed runtime. Both Team options include 250 volumes per monthly usage period, then $0.25 per additional volume. Failed runs and same-period repeats of the same model version on the same scan are free. At paid launch, Nitsor shows you the volumes, price and maximum charge and asks for confirmation before execution. Nitsor will publish the supported models and scan-size scope before paid launch. You agree an explicit fixed quote before an exceptionally expensive workload runs. Billing remains deferred; these prices are not active charges. See Plans and billing.

What a proposal is

The runner writes masks and a proposals document. Each proposal lands in the editor as model-authored content that a person marks accepted or corrected. Provenance is part of the annotation hash, so a mask taken from a model is not the same annotation as one a person drew, and a corrected proposal is shown as corrected. A model Agent holds at most contribute and never judges human-authored work.

Prelabeling

From an Auto-label stage to a decided proposal

Model-assisted prelabeling path as builtAn Auto-label stage receives a Task with a prompt. A Run is dispatched to the managed run plane, the runner writes masks and proposals, the proposals land in the editor marked uncalibrated because the score is the model’s own, and a person accepts or corrects each one. Uncalibrated runs carry no calibrated risk guarantee.Auto-label Taskpoints or human-boxRun on the run planeSAM 2.1, L4, region usProposalsmasks + documenta person accepts or correctsprovenance stays model-authoredevery proposal is marked uncalibratedproposals carry no calibrated uncertainty guaranteenever: a Dice or IoU guarantee

The path an Auto-label stage takes, from the prompt to a decided proposal.

Why this sits with the review concepts

A proposal is a recorded outcome, in the same way a rejected review is. Both say what happened and what or who produced it, rather than leaving a gap a later reader has to guess at. Read Review and rework for the human half of the same idea, and Roles and provenance for why model-authored work stays identifiable.

Model label outcomes

The task and proposal outcome routes report what people did with each model label by the time their work on its scan was approved, using kept_as_is, style_fix, small_fix, big_fix, deleted, wrong_class or missed; changed geometry is split into style_fix, small_fix and big_fix by surface Dice at a tolerance of the larger of 2 mm and one voxel spacing, with scores of at least 0.95, at least 0.80 but below 0.95, and below 0.80, respectively. They also report how a deleted model label left, as discarded, deleted_after_import or not_imported. A close that sends work back records no outcomes; only a review close that approves the work makes a record final, and records from other closes are provisional.

Next step

Read Annotate and review for how a proposal reaches a person, then Plan an integration for the evidence to demand from a model run.
PlansTeam and Enterprise
Last verified2026-09-30