Limits
What a Pro account includes, where the platform draws lines, and how billing works. Numbers here are the current defaults; the pricing page shows the live starting price per GPU.
Plans and billing
- Neural Studio requires a Pro subscription. Pro is $29 a month, and every account needs it to use the platform. There is no free tier.
- 1,000 compute credits each cycle. They land when the month's payment goes through and expire at the end of that billing cycle.
- Credits are money. $1 = 100 credits. Compute is billed per minute at the live rate card, from the moment a runtime is running until you stop it. Provisioning time is never charged and a stopped runtime costs nothing.
- A 250 GB storage pool is included with Pro, shared by every workspace you own, and up to 10 workspaces per account.
- Environment builds cost 1 credit per minute of build time, failed builds included. Transfers between a storage connection and a workspace are free, and storage is part of the pool, so nothing else burns credits.
- Cancel any time in Settings → Billing. Pro stays active until the end of the period you already paid for, and you are not charged again.
- When a subscription ends, any runtime the account started is stopped within about a minute, whatever credits it still holds, and the account can still sign in, subscribe again, update its payment method, delete itself and sign out, and nothing else. Your workspaces and files are kept, and your storage pool does not shrink; top-up credits stay on the account for when you subscribe again.
Launch gate
- Your email must be verified before you can sign in at all.
- A launch is admitted only if your balance covers at least two minutes of the chosen machine at its current rate; when the balance runs out, the runtime is stopped.
- Runtime launches are rate-limited per user (30 per minute).
- At most 5 runtimes running at once per account, and 2 while the account is under 14 days old. The runtime bar says so when a launch would cross the cap.
Buying credits and spend controls
- Top-up packs: $5, $10, $25 and $100 (500, 1,000, 2,500 and 10,000 credits) on top of your subscription's monthly credits, paid through Stripe Checkout and valid for 12 months. Purchases are final; there are no refunds.
- Monthly spend cap. Settings → Billing lets you set a hard cap on the credits a calendar month may consume. Once month-to-date spend plus the two-minute launch runway would exceed it, launches are refused, and a running runtime is stopped as soon as its next charge would cross the cap.
- Low-balance alert. A threshold you set in the same place. It never blocks anything; a banner appears on every page once your balance drops below it.
Session and runtime limits
- One dedicated machine per runtime. Every runtime is its own single-tenant VM, provisioned fresh for that session and terminated at the end of it; nothing is shared with another user.
- One running runtime per workspace. Opening a second notebook attaches to the runtime that is already running. Across your workspaces the account-wide cap above applies.
- No hard time limit unless you set one. The API default is no deadline; the runtime bar's Duration chip preselects 30 minutes and offers ∞. The minimum for a hard limit is 5 minutes.
- Idle stop defaults to 2 hours. The allowed values are 15, 30, 60, 120 and 240 minutes, or Never, settable at launch and changed on a live session from the runtime bar. A runtime is idle only when there is no user interaction and no cell executing; a long-running cell keeps it alive.
- Kernel WebSocket bounds: a connection idle for 30 minutes (1,800 s) is closed, a single message may be at most 64 KB (65,536 bytes), a connection may send at most 100 messages per second, and one user may hold at most 5 concurrent connections. Offending connections are closed with codes 4408, 4413, 4429 and 4403 respectively; the notebook reconnects and the outputs of a still-running cell replay.
- Outputs while disconnected. A closed tab keeps its cell running. The runtime side of the connection is held for 30 minutes, and up to 8 MiB of output (1 MiB per message) is buffered for replay for up to an hour.
- Rate limits: 200 API requests per minute per identity in general; runtime launches 30 per minute; kernel restart and interrupt 20 per minute.
Workspace and storage
- One storage pool per account. Pro includes 250 GB, shared by all the
workspaces you own; the Files page shows the pool and how much of it each
workspace holds, and Settings → Billing lists every workspace's share.
Uploads, notebook saves and imports that would not fit are refused before
any byte is written, and a full pool refuses new writes in every workspace
that shares it until you delete something. Everything under a workspace
counts, including the platform-managed
.ns-cachedirectory that holds persisted packages. Model downloads and other large intermediates belong on the runtime's local scratch disk, which does not count; see Large datasets and models. - Up to 10 workspaces per account. Deleting a workspace frees its slot and returns its files' space to the pool.
- Reserved names. The top-level
.ns-uploads(upload staging) and.ns-cache(package cache and user site) directories are managed by the platform: hidden from the Files page and not addressable through the file, notebook or share APIs. Nested directories of the same name are ordinary.
Run media
Images, tables and histograms logged with run.log are stored with their
run, apart from workspace storage, within these caps:
- Per batch: 256 items and 32 MiB. The SDK sizes its batches to fit.
- Images: PNG, JPEG or WebP, at most 4 MiB, 4,096 px a side and 16.8 megapixels. The SDK scales a larger numpy array down before sending it; image bytes or files over these limits are refused. EXIF and other metadata are stripped on arrival.
- Tables: at most 10,000 rows, 200 columns and 8 MiB. Cells are text, numbers, booleans or empty.
- Histograms: 1 to 512 bins.
- Per run: 10 GiB, 50,000 items and 1,000 keys. A key keeps one kind of media (images, a table or a histogram) for the life of the run.
- Per workspace: 100 GiB of media across all its runs. A deleted run's media counts until it is purged, about an hour after the delete.
- Rate: 120 media batches a minute per identity.
Run artifacts and logs
- Artifacts (
run.log_artifact, attention maps): at most 64 MiB each, 5 GiB and 2,000 files per run, and 100 GiB across a workspace's runs. - Logs: 500,000 captured lines per run; past that the SDK stops capturing console output for the run.
Environments
- An Environment spec may list at most 500 pip packages, 200 system (apt) packages, 50 post-install commands and 200 environment variables, with at most 50 CIDR entries in an egress allowlist.
- Package entries are validated: a name must be a plain PEP 508 name and a version a PEP 440 specifier, so a package line can never smuggle a pip flag, an index URL or a direct reference into the build.
- The environment-variable keys
LD_PRELOAD,LD_LIBRARY_PATH,PYTHONPATH,DYLD_INSERT_LIBRARIESandDYLD_LIBRARY_PATHare refused. - Per Environment, at most 50 runtime secret names and 50 build secret names may be referenced.
- A build may run for 60 minutes before it is failed, and costs 1 credit per minute while it runs.
Secrets
- A workspace holds at most 100 secrets. Names match
^[A-Z][A-Z0-9_]{0,63}$, are unique per workspace, and may not use theNS_orNEURAL_STUDIO_prefixes or the loader-hijack names above. - Values are 1 to 8,192 characters, write-only: a value is never returned by any API, and replacing one never reveals the old value.
- Content over 2 MiB is not scanned by the credential scanner (you get an advisory notice instead of a scan result).
Keys, sharing and transfers
- SSH keys: up to 10 active per user. API keys: up to 10 active per user; a key may make 200 requests a minute.
- Copying a shared file or notebook into your own workspace is capped at 10 GiB per copy. Public links answer at most 30 views a minute per IP address.
- Transfers: one running and five queued per workspace, and a single transfer may run for at most 24 hours.
Providers and regions
Four clouds are available: AWS, Nebius, DigitalOcean and Lambda Cloud. Every GPU class on offer is listed on the pricing page with its starting price (the lowest per-GPU rate across these clouds); the launch picker shows which clouds sell each class and the exact rate of every machine size. There is no region picker: each cloud launches in one region fixed for its GPU class, chosen for latency to the control plane.
| Provider | Launches in | Spot |
|---|---|---|
| AWS | us-east-1 | On-demand and spot |
| Nebius | us-central1 | On-demand and spot (preemptible) |
| DigitalOcean | nyc2 for H100 and H200; tor1 for RTX 4000 Ada, RTX 6000 Ada and L40S; mkc1 for B300 | On-demand; B300 is sold on spot only |
| Lambda Cloud | us-east-1 | On-demand only |
Lambda's us-south sites are deliberately excluded: Lambda does not enforce
account firewall rules there, and the platform fails closed rather than run
a runtime without them.
Spot runtimes can be reclaimed by the cloud at any time. Where the cloud gives notice (AWS: about two minutes; Nebius: about a minute; DigitalOcean gives none inside the machine), the notebook saves itself and shows a countdown before the machine goes; a reclaimed session ends as "spot capacity was reclaimed" with a one-click relaunch on-demand or on spot again, never a silent switch. Variables and running cells are lost, files in your workspace are not, so keep checkpoints there.
Where to look
- Pricing: /pricing, the live starting price per GPU and the billing rules.
- Your balance, ledger and spend controls: Settings → Billing; the flows are on Your account and billing.
- Secrets, SSH keys, API keys: the matching Settings tabs; see Isolation and secrets, SSH and API keys.