Skip to main content
All plans Use this register to compare what Nitsor does on each plan. Planned launch pricing and billing are marked separately from current capabilities. The paid-launch billing policy is not active. Billing remains deferred, with no paid-launch date set. Plans and billing explains pricing and setup.

​
Capabilities by plan

A capability marked “Not included” is absent from that plan. What each capability does states the scope and limits of each row. On Community, the Account roles and permissions, Review, Volumetric viewer and editor, and Analytics and progress reporting rows need the Nitsor application. The self-host stack does not include the Nitsor application, so a Community deployment has none of them today. The authenticated operations in the Public HTTP API and Python SDK rows need an agent credential. It is issued in the Nitsor dashboard, so a Community deployment cannot run them today. Installing the self-host stack needs no credential, and neither does anonymous discovery through the OpenAPI document and GET /api/v1/capabilities. Both still work. The Datasets and Dataset Versions row needs the run plane and the data-plane Workers: on Community the run plane is off and the stack runs neither Worker, so a Community deployment cannot build or read a Dataset Version today.

​
What each capability does

  • Hosted workspace and sign-in. The hosted dashboard runs at app.nitsor.com. Team signs in through WorkOS AuthKit with email and password, Google or Microsoft. Enterprise uses its identity provider. Workspaces have invitations and four member roles.
  • Account roles and permissions. Four account roles over a fixed permission set; four project rungs (read, contribute, operate, admin) held through grant rows; agent credentials capped at operate, hosted model Agents at contribute; clearances against export markings.
  • Recorded authorization decisions and attribution. A write that reaches guarded authorization records an allow or deny Decision; a read check refuses without persisting one. A Ledger entry ties each accepted event to its Decision and principal. Both are served by GET /api/v1/decisions and GET /api/v1/ledger. No dashboard screen presents them.
  • Project record and event history. Projects carry Overview, Tasks, Data, Versions, Guidance, Pipeline and Settings tabs, and the Settings tab holds the General and Access pages; project groups file them. Every governed write is an event on a branch, replayable into derived records.
  • Version model (branches, commits, merges). Branches, commits with a recorded kind, landmarks, and typed three-way merges with typed conflicts are served by the API. Commits happen when a task ends with something to record. The dashboard’s Versions tab lists commits per branch on its Commits and branches page; there is no branch or merge screen.
  • Review. Review verdicts (accept, correct, reject) are bound to the hash they judged, a task-level Accept closes the review, and rework goes back to the original annotator, all in the dashboard editor.
  • Model-assisted prelabeling. On Team and Enterprise, SAM 2.1 (hiera large) runs Auto-label stages on Nitsor’s managed GPU run plane, counted in model-assisted volumes. Nitsor runs no hosted compute for Community. Runs show their recorded GPU seconds on the Executions page, and a Job links to its Run. API duration fields, including billableDuration, remain cost and resource measures; customer billing at paid launch is per completed scan/model result under the identity rules, with all objects included. Nitsor will publish the supported models and scan-size scope before paid launch. You agree a fixed quote before an exceptionally expensive workload runs. The editor marks every proposal uncalibrated, because the model reports its own score and nothing calibrates it.
  • Medical-image (DICOM) series registration. Uncompressed DICOM Part 10 CT and MRI series and uncompressed single-frame DICOM ultrasound images register by reference and render in the viewer and editor. CT and MRI series carry geometry, slice order and duplicate-instance checks with named issue codes. Ultrasound calibration and limits are described under Formats.
  • Volumetric viewer and editor. A Cornerstone3D-based editor has cursor, brush, contour, threshold, 2D box, point, measure and 3D box tools, with orthogonal reference views. The project source viewer is read-only.
  • Service accounts and tokens. On Team and Enterprise, an owner or admin creates service accounts on Team settings, then Service accounts. A service account has a name, a description, an owner, account permissions it holds, project access a project admin gives it, and up to 10 live tokens that expire after 90 days by default and 365 at most. It can be disabled and enabled, or retired for good, and nothing is deleted. A token can read its own identity, permissions, projects and expiry through GET /api/v1/session, and a refused token is told why: expired, revoked, or its service account disabled or retired. See Service accounts and tokens.
  • Public HTTP API. API v1 with one OpenAPI 3.1 document generated from the contract, hashed agent-credential authentication, per-route minimum versions, idempotent writes and async Requests. See Public HTTP API.
  • Python SDK. nitsor is an API client with sync and async forms, and it includes the nitsor.data training reader. It is not on PyPI. Use the HTTP API.
  • Datasets and Dataset Versions. Datasets are selections over a branch with up to seven clause kinds; versions are immutable, chunk-digested, leased for reading and pinned by consumers. Deletion needs project admin, which public API credentials never hold. A project admin can allow one service account to delete Dataset Versions in one project for up to 90 days at a time, and the API then accepts the delete from that account’s tokens.
  • Async Requests. Operation kinds import, export, model-run, report, prediction-import and dataset-version; get, list, cancel and per-item reports; one waiter in the Python SDK.
  • Storage connections and source registration. Existing scans register by reference where they live. Uploads can use connected customer storage, a Nitsor-managed bucket, or storage managed entirely by Nitsor. Hosted uploads default to Nitsor storage; the owner can turn it off. Owners and admins connect customer storage and submit keys through the dashboard or their personal authority. Keys are encrypted and never returned in responses, events, logs or errors. Agent credentials cannot add or change keys or enable writing. New customer connections are read-only; masks, stored viewer representations, uploads, model outputs and mask-bearing Dataset Version files need write access. Uploads additionally require an owner or admin to enable Accept uploads after the upload checks pass; see storage connection setup. See Data boundary for storage boundaries.
  • Self-hosting. Community is available at launch. The self-host package ships at launch. Until then, start on Team. Community is a single-node deployment on your infrastructure. Billing and telemetry are off. The stack runs the Convex backend, its operator dashboard and the Nitsor functions, and it requires your own OIDC identity provider’s issuer, client ID and client secret. The self-host stack does not include the Nitsor application, so a Community deployment has no Nitsor dashboard or sign-in today. See Self-host Community. Enterprise assisted private deployment is agreed with sales.
  • Hosted operation. Nitsor stores hosted control-plane data in US East (N. Virginia), pins dashboard functions to Washington, D.C., and stores artifacts under the R2 US jurisdiction. Staging has the same shape. Enterprise support and recovery terms are agreed with sales.
  • Industrial (non-DICOM) file formats. VGStudio .vgi/.vol is viewable; MRD and TIFF projection stacks are raw; NSI legacy, NSI HRVOL, REK, FLT, CB and SBM register as unsupported by name. Other formats are not recognized.
  • Analytics and progress reporting. A portfolio dashboard rates project health and current work. Executions filters Runs, Jobs and Tasks. The execution contract does not provide aggregate metrics, provider usage or invoices. The Stripe billing portal is part of the paid-launch design; this policy is not active.
  • Billing. Team paid-launch billing is not active. At paid launch, subscriptions are paid upfront and extra usage settles after each monthly period, with monthly allowance resets even for yearly Team. Billing remains deferred, with no paid-launch date set. Owners and the billing role hold billing permissions; admins can view billing. Enterprise keeps negotiated commitments, rollover and overages. Billing is off on Community.
  • Documentation and agent-readable exports. This site publishes documentation, per-page Markdown, llms.txt and llms-full.txt exports.
  • Enterprise single sign-on. Enterprise uses SAML or OIDC through WorkOS, set up with Nitsor during onboarding. See Single sign-on.

​
Limits

  • Nitsor has no consensus or adjudication stage. The pipeline designer offers Annotate, Review and, where a model Agent can run it, Auto-label stages. It does not offer consensus-read or adjudicate, and it refuses to apply a pipeline that still carries either one, asking you to change the stage to Review or remove it. Work that reaches either stage cannot finish: a disagreement creates no Task for anyone to settle, and the editor cannot close a consensus or adjudication Task. Neither the editor nor the public API records a consensus vote or an adjudication decision. See Review and rework.
  • A Dataset Version has no approval mark or signature.
  • Model proposals have no calibration certificate or calibrated uncertainty guarantee.
  • Registration does not upload bytes. Sources register by reference.
  • Hosted model jobs use one managed GPU run plane. A hosted workspace cannot bring its own GPUs, and Nitsor runs no hosted compute for Community.
  • Hosted model runs accept DICOM series. Other formats are refused before the run starts.
  • Customer storage connections use supported S3-compatible endpoints. Google Cloud Storage is read-only until its write checks pass. Azure and AWS role-based connections are not supported. A custom hostname needs approval by Nitsor.
  • Dataset Version downloads from a self-serve customer connection need a signer that Nitsor sets up with you. A version using separate read and write connections needs both configured. Viewing, masks, viewer representations and uploads do not use this download signer.
  • A Dataset Version pins the branch head at creation.
  • Nitsor does not issue personal tokens. The service-account routes in the API and the Python SDK’s service-account methods need one, so service accounts are managed in the dashboard.
  • Product webhooks have no subscription route or delivery. The contract declares one event type. There is no product MCP server; the documentation site has a documentation-only MCP server at /mcp.
  • Nitsor does not run model inference in the browser.
  • The editor supports laptop and desktop screens 1280 px wide and up, and does not support tablet or phone screens.

​
Formats

Uncompressed DICOM Part 10 CT and MRI series, uncompressed single-frame DICOM ultrasound images, and VGStudio .vgi/.vol are viewable. Ultrasound is handled as a 2D image. Compressed DICOM transfer syntaxes are not supported. Ultrasound uses PixelSpacing or suitable Ultrasound Regions for calibration; an uncalibrated image has no physical scale. Register geometry-free images separately. Multi-frame ultrasound, including cine and native 3D/4D ultrasound, is not supported; NumberOfFrames must be 1. NIfTI and NRRD are not supported. Registration and viewing do not imply that every hosted model accepts the scan. A complete ultrasound workflow from import through labeling, review and Dataset Version export has not been verified. MRD and TIFF projection stacks register as raw acquisition data. NSI legacy, NSI HRVOL, REK, FLT, CB and SBM register as unsupported by name. Other formats are not recognized. See Data boundary for format checks and storage boundaries.
PlansAll plans
Last verified2026-10-21