Limits and free credits

What every account gets, where the platform draws lines, and how the free credits work. Numbers here are the current defaults; the pricing page shows the live per-hour rates.

Free credits

• New accounts start with 1,000 credits ($10 of compute). The grant lands the first time your account touches billing — opening Settings → Billing or launching your first runtime — so your first launch already sees it.
• One grant per account, ever. It is keyed to your account id, not your email; verifying a second address, renaming, or signing in through Google or GitHub on the same account never grants again.
• Valid for 30 days. Unspent welcome credits expire 30 days after they are granted and show as "Credits expired" in your ledger. Top-ups you buy are separate and stay valid for 12 months.
• No card required. You only add a payment method when you top up.
• It is money like any other credit. $1 = 100 credits; the welcome grant is spent at the same live rates as everything else, per minute, from the moment a runtime is running until you stop it. Provisioning time is never charged and a stopped runtime costs nothing.

Keeping it fair

The welcome grant is meant for people trying the platform, so it comes with guardrails you will mostly never notice:

• 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).
• Signup abuse (throttled or failing signups) raises an operator alarm.

Creating multiple accounts to collect the grant repeatedly is against the terms of service; accounts doing so are suspended and their credits removed.

Buying credits and spend controls

• Top-up packs: $5, $10, $25 and $100 (500, 1,000, 2,500 and 10,000 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.
• 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

• 10 GiB of workspace storage per workspace by default. Uploads that would exceed it are refused before any byte is written; everything under the workspace, including the platform-managed .ns-cache directory that holds persisted packages and caches, counts toward it.
• Reserved names. The top-level .ns-uploads (upload staging) and .ns-cache (durable caches 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.

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_LIBRARIES and DYLD_LIBRARY_PATH are refused.
• Per Environment, at most 50 runtime secret names and 50 build secret names may be referenced.

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 the NS_ or NEURAL_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).

Providers and regions

Runtimes launch in a fixed set of regions per cloud, chosen for latency to the control plane. Which clouds appear in the picker depends on what is enabled for the deployment; the GPU classes on offer differ per cloud and are listed on the pricing page.

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.

Where to look

• Pricing: /pricing, the live per-hour rate card and the billing rules.
• Your balance, ledger and spend controls: Settings → Billing.
• Secrets, SSH keys, API keys: the matching Settings tabs.