Using the Nodus console

Nodus runs your command on compute matched to its requirements. Start with a GPU workload, observe its progress, and download the results your command creates. The assistant can explain these steps, edit your saved run settings, prepare a run from your supplied setup, and open the relevant control.

Choose Ask or Auto

Open Ask Nodus, then open the mode menu inside the message box. Choose Ask or Auto. Ask is the default. It gives you buttons for suggested console locations. Auto can open one suggested location for you after answering. It keeps multiple destinations as choices. Changing views or closing the panel stops a pending automatic move.

Describe requirements and budgets in your message, for example "run this with a $5 limit". There is no separate budget setting to fill out. Supply your actual command and container image, and identify existing code and data assets when needed. The agent shows the exact proposed setup. Launch run submits it through normal workload checks. Change setup lets you describe an adjustment in chat. The card includes the GPU model, count and memory. An explicit model requirement is preserved. Automatic means no specific GPU model was requested. Missing code or datasets can be added through New run. Garden discovery is not connected yet.

In Auto, an explicit current request to launch one run within a clear dollar maximum can start its reviewed setup. A budget mentioned in a question or saved preference does not authorize spending. The limit is not a price quote or promise of completion. Repeating a launch after an uncertain response checks the same submission. Closing the panel before automatic submission starts prevents that submission, but does not cancel work already accepted.

A new conversation, reload, sign-out or team change clears chat and returns to Ask. Project preferences lets you save, edit and forget a note about your projects and working preferences for the current team. This note is separate from chat history and never grants spending permission.

Run answers can include status, measured cost, reported progress and result download buttons. Watch run adds a run to Following. Up to eight followed runs persist across visits. Updates appear while the console is open and are checked again when you return. Stop following removes one. These updates do not send email or browser push notifications.

Edit a saved run draft

New run saves supported field edits for your account and current team. The saved fields are run name, command, container image, GPU model and count, memory per GPU, spending limit, recovery checkpoint paths and result paths. These settings return after a page reload, independently of chat history.

Ask the agent for a specific change, such as "set my spending limit to $5". In either Ask or Auto, an applied change updates the saved draft and highlights the affected controls when New run is open. You can also prepare these settings from another console page, then open New run to review them. Changing a draft does not submit a workload. Start run remains a separate action.

If another edit arrives while you are changing the form, your local edits remain visible. Keep my edits saves your changed fields against the latest draft. Load saved draft replaces the displayed settings with the saved version. When saving is unavailable, Retry draft sync reconnects before agent edits resume.

Code and dataset selections, uploaded files, access tokens and checkpoint optimization are outside this draft. Choose those separately after reloading. A reused run setup retains its own code and settings and is edited manually.

Start a run from your code

Open New run. Choose Code source: Container command, GitHub repository, or Upload code. Upload code accepts a Python or shell script, ZIP or TAR archive. Include training files and exclude credentials and local virtual environments. For GitHub, use Connected repositories or Public repository. Choose a Branch, or expand Use a specific commit or another branch and use Verify revision. If a connected repository is missing, update repository access in Settings, then Refresh repositories.

Once training code and a dataset are selected, Nodus prepares the files and automatically fills Command. Choose None or included in my code when no separate dataset is needed. Changes to code, the verified GitHub revision, or the dataset regenerate the command. Prepared files are reused when you start the run. If you edit the command yourself, an updated suggestion appears with Use generated command instead of replacing your edit. Responses for an earlier selection are discarded.

Generation reads relevant code and configuration with AI and uses dataset filenames to locate the input. It does not execute the code or send dataset rows to the model. Keep credentials out of uploaded code. If an entrypoint or required argument is unclear, add the requested details under Command instructions (optional). Those details trigger generation again. Retry command generation retries an unavailable request. You can always enter the command yourself. Container commands and reused run setups remain manually editable.

Review the command and select the appropriate Environment. Managed PyTorch (recommended) provides Python and PyTorch with GPU support when the server supports it. Its versions may vary. Choose a versioned preset or Custom image when your code needs specific software versions. Container image details > Container image is optional for the managed environment. A custom image must contain the runtime your command needs. If the managed environment is unavailable, choose a preset or custom image. An example command is python train.py --epochs 3 only if your project actually has that script and accepts those arguments. A generated command is a draft, not proof that the application will run successfully. Review Spending limit (USD) and select Start run to submit. Submission means accepted, not already running or guaranteed to finish.

Attach a dataset

In New run, expand Data and choose Data source. Options include Saved dataset, Upload a file, Hugging Face dataset, Download link, and None or included in my code. Hugging Face takes Dataset, Revision (default main), optional Files, and an Access token for private or gated data. Enter credentials in the token field, never in assistant chat. Download URL needs a direct HTTPS download, not a file-sharing preview page. The form prepares the input once training code and data are defined. A generated command can refer to its directory through NODUS_INPUT_data. Ensure a manually edited command reads the selected input. A successful data import does not mean your training command has run.

Choose GPUs and memory

Expand Resources in New run. GPU model defaults to Automatic. Memory per GPU (GB) defaults to 24. This is memory required on each device, not pooled memory across devices. GPUs on one machine requests an exact count. Multi-GPU choices depend on the server's advertised support. Nodus does not rewrite a single-process script into distributed training. Supply your own supported distributed launcher and command. Multiple GPUs do not imply NVLink or NVSwitch. Request requirements, not a supplier SKU.

Set a run spending limit

New run > Spending limit (USD) is the workload's cap. Leaving it blank means no per-run cap. It does not remove team monthly limits or credit requirements. It is not a price quotation or a promise that the work can finish within it. Runtime estimates are not required to submit. Resources, availability and the command determine execution. Avoid picking an arbitrary cap without understanding the workload. The assistant cannot quote a live launch price from documentation.

Save and restore training progress

Open New run > Advanced > Recovery checkpoint folder. The default is state, exposed to your program as NODUS_CHECKPOINT_DIR. Write model weights, optimizer state, and step or epoch progress there, then make your program load those files on startup if they exist. Nodus owns checkpoint cadence and storage. It does not save arbitrary process memory or add guessed resume flags to your command. An empty selected folder is not saved training progress. An empty save does not replace an earlier useful recovery point.

Optimize workload for checkpointing is unchecked for a fresh run. Check it to allow checkpoint preparation to add a supported framework adapter to uploaded or imported source. It requires the default state recovery folder and an enabled deployment. Host selection and source preparation run in parallel. Training starts after both are ready. Leaving it unchecked keeps your code unchanged and uses your program's existing save and restore behavior. Infrastructure matching and cost-aware placement still run in either case.

The run detail distinguishes source preparation from a useful saved checkpoint. Prepared source alone does not establish runtime compatibility or successful application recovery. For application-managed saves, publish complete immutable checkpoint versions using the atomic publication guidance.

The API accepts relative continuity.checkpoint_paths, up to 64 literal paths. They are not globs. The default is ["state"]. ["."] explicitly opts into saving the whole code folder. Keep dependencies, environments and caches outside recovery state, for example under $TMPDIR/runtime. Older submitted workloads retain their submitted behavior. A recovered file tree helps only when your application knows how to resume from it. Automatic application save and resume needs a qualified framework integration.

Find downloadable results

Open the workload from Workloads, then inspect Results and use Refresh results. When no explicit result paths are set, nonempty outputs/ and results/ folders become downloadable outputs.tar and results.tar archives. Your command must create the files. Recovery files in state/ are separate and do not automatically become final results. Save final weights, configuration and tokenizer files into your chosen result folder as appropriate to your application.

New run > Advanced > Result file overrides accepts one relative file path per line. Explicit result paths replace automatic collection. Dependencies and caches are excluded from automatic archives. Empty folders produce no result archive. A completed run can legitimately have no downloadable results. Inspect actual result records before claiming a download exists. The SDK downloads archives without automatically extracting them.

Read progress and diagnose a slow start

Workloads has Mine and Team scopes. Open a workload to see its progress, Events, Logs, Results, and Stop control. Accepted, planning, reserving and provisioning happen before customer execution. Running means the command started. Recovering means a replacement is being prepared after an interruption. Completed, failed and cancelled are terminal states.

Read the latest Events before identifying the current phase. A recorded slow start means another machine is being tried. Waiting for an available machine is capacity waiting. Waiting for earlier machines to stop before trying again is cleanup waiting. Neither alone proves the command is broken or that a budget increase would help. Do not promise a start time without evidence. Preserve the workload ID and event times when escalating a prolonged delay.

Diagnose a failed command or missing logs

Open the workload and select Logs. Use Refresh in the Logs panel for the current view. A failed status alone does not identify the cause. Check the terminal event, command exit, and actual application error. The assistant reads safe lifecycle summaries and recognized diagnostic patterns from a bounded log scan. It reports the attempt and any scan limits. Raw log text and arbitrary failure messages are not sent to inference. A pattern is evidence to investigate, not proof of the current root cause. To discuss an unrecognized error, share only the relevant excerpt after removing credentials and private data.

For out-of-memory errors, first establish whether the application exhausted GPU memory or host RAM. Current cost below a cap does not rule out failure to authorize the next execution window or other spending constraints. For GPU memory, review batch size, precision, checkpointing support in your framework, and Memory per GPU (GB) for a new run. Do not claim more GPUs automatically pool memory. For a missing module, check the selected Environment, image and installation command. Do not claim either cause from status alone. Python output buffering can delay visible logs. An empty live log page does not mean execution has completed. A saved log may be absent even when the lifecycle is known.

Understand credits, card setup and team limits

Open Billing to see current spending, available credits, monthly limits, payment setup and invoices. The current deployment and team state determine whether a payment method is required. Static setup guides can describe different policies. Check the live billing read instead of assuming a card is always required or that starter credit is always enough. Credits being present does not prove admission, capacity or completion.

Only admins can change billing and the team spending limit. Members can view spending. Monthly limit in dollars controls the team cap and is separate from the per-run spending limit. Add payment method opens the configured setup flow. If setup is unavailable, do not claim the assistant can enable it. The assistant never receives card numbers, card identifiers or billing addresses.

Current cost includes settled charges and measured accrual. A zero settled balance does not mean a running workload is free. Commitments reserve spending headroom. Stopping a run and settling charges take time. Lowering a cap does not refund existing charges. Compare values with the same timestamp and distinguish credit balance from budget headroom.

Stop, retry and save a setup

Open a workload and use Stop to request cancellation. Observe the terminal status before saying it has stopped. The assistant cannot cancel it for you. For another attempt, use the console's run-again flow or New run, review the command and resources, and submit a fresh run. This is distinct from Nodus recovery. Do not promise the new run automatically has the old run's recovery state.

In New run > Advanced > Save or load setup, Download setup saves command and environment settings. Load setup file restores a JSON setup. Code, datasets and access-token fields are not included. Reloading a setup therefore does not restore local uploaded files or missing credentials.

Connect the SDK and manage access

Install with pip install nodus-compute, then run nodus login. Approve only the matching terminal code in the browser. API keys manages keys for SDK or CLI access. Never paste a key into assistant chat. NODUS_API_KEY and NODUS_BASE_URL override saved CLI configuration independently. nodus logout removes local configuration, not server-side keys or environment variables. Revoke a key in API keys when you need to invalidate it.

Use Team for membership and invitations, Settings for account and GitHub access, and Activity for account changes. The assistant uses the currently signed-in team and role, not a team ID typed into chat.

Connected compute and integrations

BYOCompute connects AWS accounts, Google Cloud projects, or Azure subscriptions with read-only access. Choose your cloud and follow the connection form to view its resources, usage, costs, and forecasts. Team administrators manage connections. Cloud observation works independently of host pools.

New connections check the supplied credential before saving. Choose a single scope or discover accessible scopes and select several together. The overview shows the selected connection's resources, reported spend, VM CPU usage, projected spend, and source coverage. Missing data remains labeled. Each card opens the detailed resources, usage, or forecast view. Multiple connections show individual collection statuses. You can connect up to 200 accounts, projects, or subscriptions per team.

Where host pools are available, BYOCompute also shows connected hosts, utilization, forecasts and routing. Telemetry enrollment and execution authority are separate. A measured host is not automatically authorized to run workloads. Pool operations depend on the current deployment. Use the customer infrastructure pools reference for exact registration and policy APIs instead of inventing console controls.

Connect external data and experiment tracking

Open Connections > Add connection. Enter Connection name, choose Connection kind from PostgreSQL, Neon, Supabase or W&B, and select Scope. Region is optional. Neon supports an optional Neon branch. W&B requires W&B entity and W&B project. Enable live W&B logging requires a team administrator and a write-capable scope.

Under Credential source, select Store a new credential or Use an existing secret. Enter a PostgreSQL URL with TLS or W&B API key only in New credential, never in assistant chat. Create connection stores a new credential as a write-only secret before verifying the connection. If verification fails after storage, the form identifies the saved secret. Correct the connection and retry with that secret instead of storing another copy. External systems require their own setup and permissions.

Existing connections offer Reverify and Delete. Deleting a connection keeps its external data and stored credential. Closing the form does not undo a secret already stored. The assistant cannot create connections, read credentials or grant access through chat.

Waiting from the SDK

A timeout passed as workload.wait(timeout_seconds=60) stops local observation and does not cancel remote execution. Refresh the workload or continue waiting to learn its state. The synchronous SDK's interrupted wait and async cancellation request remote cancellation, but network failure can prevent confirmation. Read the workload status before assuming it stopped. Polling, waiting, cancelling, and re-submitting are different actions. Use client.get(workload_id) or workload.refresh() to retrieve current status. There is no client.workloads.get() method. timeout on nodus.Client is the HTTP request timeout, distinct from timeout_seconds on workload.wait().

Reusing an idempotency key protects retries of the same logical submission. It returns the original workload, even if that workload is terminal. A deliberate new training run uses a new submission key. Do not submit again merely because local observation timed out. For a known published output named adapter.tar, use workload.download_output("adapter.tar", "adapter.tar", stage="train") only when train is its actual stage. Use the exact published name, not a guessed shortened name. Obtain the workload with client.get(workload_id) inside a with nodus.Client() as client block before invoking these helpers.