sequenced.ai
Articles/Models & infrastructure/Blueprint//8 min read

Novita AI brings model APIs and agent runtimes into one cloud

Novita AI combines hosted models, dedicated inference, GPU infrastructure and agent sandboxes. Each layer has a different lifecycle, billing unit and operational responsibility.

By Sequenced deskAI-assisted, source-led · how we work
Visit Novita AI website ↗
Model APIsHosted inferenceManaged access to language, image, audio and video models.
DeploymentsDedicated inferenceDevelopers can serve custom models on dedicated GPU resources.
SandboxesAgent executionIsolated runtimes provide code, files and browser capabilities.
Scale to zeroCapacity lifecycleDedicated deployments can sleep when configured for idle periods.
Novita AI mark
Novita AInovita.ai · independent research

Represent this company? Verify your work email to access its workspace, or send the desk a factual correction.

Novita AI is a developer cloud that combines model APIs, GPU infrastructure and execution environments for AI agents. A model API produces an answer; an agent sandbox runs the code or tools that act on that answer. Dedicated model deployments and GPU instances offer additional control over inference and computing. Understanding these boundaries prevents a convenient shared account from becoming a confused architecture.

In brief
  1. 01The offer Managed access to language, image, audio and video models.
  2. 02The reader Developers building products that combine model calls with code or file execution.
  3. 03The boundary Model tokens, sandbox runtime and dedicated GPU capacity have separate lifecycles and charges.

01 / ProductModel execution and agent execution are separate services

The current product overview distinguishes serverless model APIs, dedicated endpoints, GPU instances, serverless GPU jobs and agent sandboxes. These are different resources rather than one interchangeable product. An application can use only the hosted model route, or combine it with a sandbox when it needs to inspect files, execute a script or interact with a browser.

The GPU overview provides the infrastructure entry point. GPU rental is relevant when the team wants to run its own software environment. A dedicated inference endpoint instead packages serving around a supported model. Both require hardware decisions, but they leave different amounts of system administration with the customer.

The breadth is useful for a team building an agent-backed product, provided each service has a clear purpose. It is less useful to buy every layer in advance. Begin with the application action that matters, then decide whether it needs generated text, isolated code execution, custom model weights or an independently managed GPU machine.

02 / AudienceBuilders who need both a model and somewhere for tools to run

A good candidate is a product team developing document analysis, coding assistance or media processing with engineering ownership. These jobs may combine model inference with deterministic file transformations. Novita offers building blocks for that combination; the customer still owns the user interface, permissions, job state and rules governing which actions an agent may take.

A business seeking a ready-made office assistant may find this stack too low-level. A model call does not provide a reliable workflow by itself, and a sandbox does not decide which external actions should be authorized. The team needs an owner for failures, data cleanup and dependencies even when the runtime is managed.

The Modal blueprint offers another perspective on programmable cloud execution for AI workloads. The Runpod blueprint is relevant when comparing GPU instances and serverless workers. Use those distinctions to choose the level of control required; an apparently similar GPU name says little about the included runtime, storage or orchestration.

03 / WorkflowA proposed product for analyzing supplier spreadsheets

Imagine an application that accepts a supplier spreadsheet and produces a draft discrepancy report. This is a proposed workflow, not a product test. The user wants to know which rows contain inconsistent units, missing identifiers or impossible totals. The model can explain those findings, but deterministic code should calculate sums and compare identifiers wherever possible.

Create an isolated sandbox from a versioned template containing the spreadsheet parser and validation code. The sandbox overview describes separate running, paused and killed states. Pausing preserves state; killing the sandbox removes the resumable environment. Persist the report and required audit evidence in the application’s own storage before ending the runtime.

Send the model only the relevant normalized rows and validation findings, rather than an entire workbook by default. Use structured outputs with a supported model to return a list of issues with row identifiers and explanations. Validate that each identifier exists in the input. A response that follows a schema can still attach a plausible explanation to the wrong row.

Keep the first version read-only. Let the user inspect discrepancies and download a proposed correction file, rather than silently overwriting the supplier’s original workbook. A changed quantity can affect procurement, so the system should distinguish a mathematical correction from a model’s uncertain interpretation of a description. Store those two types of finding separately.

If custom model weights later become necessary, the Deployments guide describes dedicated GPUs, model sources and replica settings. It warns that scale-to-zero introduces a cold start, typically around five minutes. An interactive report screen should therefore use an asynchronous job state or keep ready capacity; it should not promise instant responses from a sleeping deployment.

For historical workbooks that can wait, the Batch Inference guide describes a fixed 24-hour completion window and request identifiers for matching results. Its uploaded batch files are retained for 15 days. Treat that as a separate data route with its own retention implications, rather than assuming it behaves exactly like an ordinary API call.

04 / PricingBudget model tokens, GPU time and sandbox resources separately

ServicePublished basisScope
DeepSeek V3.2$0.269 input; $0.40 outputCached input $0.1345 per million tokens
Supported batch inferenceIntroductory 50% input/output discountSupported models only; asynchronous
Dedicated inferenceGPU-second billingConfirm hardware tariff and disputed startup state
Sandbox computeCPU and RAM timeSeparate from model API charges
Paused/persistent storage60 GB free allowance per accountExcess documented at $0.00009 per GB-hour

Commercial examples checked 23 September 2026 on Novita pricing and sandbox pricing. Model figures are USD per million tokens. Dedicated billing and lifecycle conditions are in the Deployments guide.

Novita’s model prices are specific to the named model and modality. The commercial examples in the table use the published tariff checked on the research date. A token charge does not include the CPU and memory used by an agent sandbox, nor does it predict the cost of keeping a dedicated GPU endpoint available.

The sandbox pricing documentation bills running CPU and RAM by time. Pausing stops those compute charges, while retained storage can remain billable above the account allowance. Templates and snapshots also create persistent storage. A workflow that saves many copies of workbooks therefore needs a cleanup policy even when its runtimes spend most of the day paused.

Dedicated deployment documentation contains a billing inconsistency: the lifecycle section says only running replicas are charged, while the billing section starts charges after GPU allocation when model downloading begins. Confirm the billable startup state before budgeting. This article does not treat model loading as free or turn the guide’s illustrative GPU price into a current tariff.

For the spreadsheet product, record cost per completed report across inference, runtime, retained files and retries. A low token rate can be overwhelmed by a sandbox left running or repeated parsing of a large workbook. Explicit job timeouts and a clear completion transition make the commercial model easier to control.

05 / DistinctionsThe runtime lifecycle matters as much as the model catalog

Novita’s sandbox distinction between pause and kill is consequential for stateful agents. A paused environment can preserve an investigation in progress, while a fresh environment from a template can make repeated jobs more reproducible. Choose based on the task: continuation is useful for a long analysis, but isolated fresh jobs can simplify reasoning about cross-customer data.

The current sandbox overview identifies a newer default region with additional features such as secrets and snapshots, alongside a legacy region. That means an example written for an older SDK or domain may not describe the full current capability. Record the runtime region and SDK version in deployment configuration instead of relying on a copied quickstart alone.

Dedicated inference also has configuration boundaries. The production guide states that GPU type cannot be changed on an existing deployment; switching hardware requires recreating it. Plan a replacement endpoint and application cutover when resizing. That is different from simply increasing replicas of an unchanged configuration, and should have its own acceptance and rollback steps.

06 / QuestionsWhat happens to files, secrets and unfinished jobs?

A useful sandbox integration needs explicit ownership of retained data. Decide which files belong in the temporary execution environment, which report artifacts must survive, and how long an interrupted job may remain resumable. The application should be able to tell the user whether a job failed, expired or finished, rather than treating every disconnected runtime as a completed task.

Confirm model support for the exact input and response format before deploying the spreadsheet workflow. The structured-output documentation directs developers to supported models; a broad model catalog is not a promise that every model accepts the same parameters. Keep a small set of deliberately awkward workbooks to validate the application’s behavior after changes.

Capacity and commercial terms also need service-specific answers. A sandbox promotion, an advertised batch discount and a dedicated GPU reservation are not interchangeable credits or commitments. Ask which account limits apply to the intended concurrency and whether the selected region and hardware are actually available for the start date. Public documentation cannot establish live account quota or inventory.

07 / DecisionChoose Novita when the combination reduces real integration work

Novita AI is worth evaluating when a developer product needs managed models and an execution layer, or a route from shared inference to dedicated capacity. Keep each resource tied to a clear application responsibility. That creates a system whose failure states and costs remain understandable as the workflow grows.

For supplier spreadsheets, the useful result is a traceable discrepancy report with deterministic calculations, clearly marked model interpretation and preserved originals. Start there. Add custom weights or dedicated GPUs only when a specific quality, capacity or control requirement justifies the additional operating surface.

01

Combine APIs with a sandbox

Use isolated execution for a defined file-processing workflow alongside model explanations.

Build a bounded feature
02

Serve custom weights

Choose a dedicated endpoint when supported custom models or capacity control are necessary.

Plan readiness
03

Keep the stack simpler

Use a model API alone when the feature does not need code execution or custom hardware.

Avoid unused resources
What should we explore next?

A business worth understanding.

Suggest your business or one you find interesting. Tell us what you want to understand about its product, positioning, design or workflows.

Suggestions are free. Selection and publication stay with the desk.

Sources

Continue reading

All in this category