Changelog

Keep a named project, its saved files and compute configuration together. Workspaces is a preview. The console checks the environments, configuration and connections currently available to your account before starting compute.

Create and find your project

Create a saved project with an environment, GPU requirements, project capacity and maximum session duration. Optionally connect a permitted public or private GitHub repository. Review the current configuration quote before starting. Where account-funded sessions are enabled, sessions use account funding without requiring a separate session spending cap. Account spending controls still apply.

Workspace cards show compute state, GPU configuration, repository and saved-file size, with running sessions first. Search or filter by name, GPU or repository. Open a project for compute controls, connection readiness, files and usage.

Connect and develop

Use the available browser editor, desktop VS Code over SSH or SSH command for the same running project. Existing notebook configurations retain JupyterLab access. Add your own public SSH key in Settings, or use Set up SSH for this computer, then connect when the tool is ready. Teammates use their own keys.

A command started in the workspace terminal runs on its session. Finishing that command, closing the editor or disconnecting SSH does not stop compute. Submit a separate workload when you want a managed job with its own lifecycle.

Schedule, save and control costs

Schedule a session for a requested ready time, optionally set its stop time, or cancel its schedule. Preparation begins ahead of the requested time, but availability is checked at launch and a schedule does not reserve capacity.

Stop compute explicitly and observe file-save and release progress. Saved files remain with the project between sessions. When compute and transfers are stopped, export or explicitly delete saved project files, and edit supported settings for the next session. Inspect session history, usage and receipts, with storage accounted for separately from compute.

Supported shapes and connection flags determine what can start and connect. A saved project is not a running process, and restoring its files does not restore arbitrary application memory.

Explore workspaces

Explore tasks in Environments, or start directly from your own RL command in New run. Research discovery, custom execution and managed recipes have different availability requirements.

Discover and prepare

Search and filter environments by task, project, category and goal. The research catalog covers Reasoning Gym, SWE-smith, TextArena, MiniWoB++, OfficeQA and AppWorld, with examples, access requirements and integration status. OfficeQA is evaluation-only. These entries are research references that need integration, not a collection of ready-to-launch managed environments.

Save environments and drafts in the current account and team's browser, set the model label, task target and planned spending limit, then review the setup. Open custom workload carries those choices into the command form. You can also export a planning draft. Planning does not allocate compute.

Run your code or an available recipe

Custom RL runs accept your code, runtime, model, datasets, trainer, rewards and checkpoints. Your program controls the algorithm and must save and reload its own state. Selecting RLHF, PPO or GRPO as a workload description does not install that algorithm.

For a managed recipe that the console currently marks available, review its fixed model, task, runtime and outputs. Evaluate the base model measures the baseline. Train and compare measures a baseline, trains and evaluates on held-out tasks, with configuration for task count, training steps, seed, traces and spending. Managed recipes are individually qualified. A recipe's availability applies only to that recipe.

Follow outcomes and keep evidence

Emit task-start and task-completion events to see attempts, pass rate, mean reward, outcomes and optional task traces. Baseline, training and evaluation remain separate. Export evidence, inspect logs and costs, stop the run, or retrieve its declared outputs.

Available managed recipes return task results, manifests and provenance, with an adapter only for training. The console checks saved evidence before showing a managed comparison. Missing evidence stays unavailable, and an improvement in model quality is never assumed from completion or a reward curve.

Explore RL environments · RL run guide

For teams with managed agents enabled, deploy a project and Python entrypoint, then send it tasks over time. This requires a qualified managed environment and account admission. Use Sandboxes > New > Run an agent, or the SDK and CLI. Availability does not imply an unlimited runtime or a guaranteed completion time.

Deploy and operate

• Deploy a local project, saved source asset or connected GitHub revision, with dependency setup, network permissions and an explicit spending limit.
• Submit plain-text tasks or structured JSON. Inspect runs, returned results and immutable revisions. A run keeps the code revision it accepted.
• Set worker limits. The default scales from zero to four workers, with a shared deployment budget. Requested warm workers can incur idle charges.
• Use session identifiers for ordered work, optional deadlines, pause/resume, cancellation and explicit retry within the existing authorization.

Wait and continue

Durable agents can wait for named events, receive signals, sleep until a timer and continue into a new segment with recorded input. These waits can release worker compute. Completed journaled steps replay their recorded results when execution resumes. Store larger run-scoped data as verified blobs up to 32 MiB.

Save application progress

With the accepted checkpoint-v1 recovery policy, step completion, durable waits, continuations and run completion commit verified application files alongside recorded progress. Your code must write its state into NODUS_CHECKPOINT_DIR and load those files when restarting. Dependencies belong outside that state. This restores saved application files and replays steps, not arbitrary memory.

The console exposes useful saved state separately from pending or failed saves. Unknown external effects remain blocked for explicit reconciliation against independent evidence. The step contract distinguishes repeatable work from external actions that cannot safely be repeated after a lost response.

Open managed agents · Managed agent guide · Durable steps

Bring your evaluation harness, task set, model calls and scoring logic. Execute it in an available agent sandbox for interactive tool use, or as a GPU workload for batch evaluation. Nodus runs your code and returns the evidence it produces. You supply the evaluation tasks and scorer.

Make evaluations repeatable

Pin your source revision and runtime, supply the dataset, and set spending and resource limits. Stream logs and inspect command outcomes. Write scores, per-task traces and reports to declared result files. Without explicit result paths, nonempty outputs/ and results/ folders are collected as archives.

Use async SDK submissions for independent experiments, each with its own request key and budget. Limit concurrency in your client and account. An experiment's total spending can include every submitted run. Explicit multi-stage workloads can hand named files between serial preparation, execution and scoring stages.

Compare execution measurements

The benchmark API, SDK and CLI accept your command, an explicit total budget and a matrix of GPU families, batch sizes, allowed regions and repetitions, up to 64 cells. The console displays each cell and links to its workload. Reported cost, wall time, throughput, latency and cost per unit depend on the recorded charges and unit observations. Missing measurements remain unavailable.

Inspect task evidence

For an evaluation associated with an RL environment or a custom RL task, emit task events to show passed, failed and error attempts, reported rewards and optional traces. Export the recorded evidence and download your output files. Scores come from the verifier or scorer you provide. A completed command or a research-catalog listing does not independently validate that scorer.

Run your evaluation · Concurrent experiments · Logs and outputs

Give an agent a remote environment for multi-step work. Sandboxes > New > Run code uses the managed tools environment when it is enabled for your team. Sandbox preview and managed templates require account admission and an available, qualified environment.

Start with your project

Use an empty project, a local folder through the SDK or CLI, a saved source asset, or a connected GitHub repository. The managed environment includes Python, Node, shell and git. Add a dependency setup command and the network permissions it needs. Custom images retain their separate configuration and admission rules. The managed tools environment is CPU-based. Submit a GPU workload for GPU code.

Execute and work with files

• Run shell commands or exact argument lists with a working directory, environment variables and command timeout.
• Stream recorded stdout and stderr, send stdin, and inspect completion and exit status. Console command examples fill the terminal before you run them.
• Browse, read, edit, upload and download files. Downloads verify contents, and replacing a file uses its current version to avoid overwriting newer work.
• Reconnect using the sandbox ID or name from the console, SDK or CLI.

Control access, usage and lifecycle

Set an explicit spending limit, resource requirements and applicable idle and lifetime controls. Grant network access to the services your tools need and use stored secret references. Live file operations can wake paid compute.

Read CPU, memory and disk measurements, the available history, costs and lifecycle events. Network observations include denied destinations and measured traffic. No-output and budget alerts help identify runs that need attention.

Sleep requests a project save and compute release. Wake requests compute again, while reconnecting attaches to the existing identity. Observe completion of those transitions. Saved files do not restore process memory. Closing a client connection alone leaves remote work running, while terminating explicitly stops future execution and starts cleanup.

Open sandboxes · Sandbox guide

Use your coding agent or Ask Nodus to work with remote execution, while keeping the same account, team and spending controls as the console.

Connect your tools

Connect Claude Code, Codex, Cursor or another MCP-compatible client through the setup page. Hosted MCP uses browser consent. Local MCP uses your SDK login and can prepare local project files. Hosted connections use verified uploaded assets or connected GitHub repositories.

Review the requested permissions when connecting. Workloads, sandboxes and managed agents have separate read and write access. You can inspect connected agents and disconnect them from the console. Disconnecting a client does not cancel work it already submitted.

Prepare, execute and retrieve

Agents can validate workload requests before paid execution, submit a reviewed command with an explicit budget, inspect status and logs, cancel work and retrieve output metadata or verified downloads. Stable request keys let uncertain submissions be checked without creating a second run. Sandbox and managed-agent tools also honor their account availability and granted permissions.

Use the Python SDK, async client or CLI for scripted workflows. Authenticate with nodus login, or use a securely stored API key for unattended clients. Code, data, requested resources, spending limits and result paths remain explicit.

Ask Nodus in the console

The assistant follows your current view and selected workload. It can explain status and measured costs, help prepare a run, edit supported saved draft fields, and guide you to results or the relevant account controls. Ask presents navigation choices. Auto can navigate and act on an explicitly authorized request within its reviewed limits.

Save project preferences for your team, revisit saved chats, or follow up to eight runs for updates while the console is open. Secrets, payment details and OAuth approval stay in their secure browser controls. Preferences and a budget mentioned in a question do not authorize a paid launch.

Connect your agent · Agent workflow guide

Use preference data, reward labels or a frozen teacher to adapt a language model. New run exposes the managed objectives supported by the deployment, alongside Custom code for your own post-training implementation.

Preference and reward methods

• DPO and ORPO use a prompt with preferred and rejected answers.
• KTO uses a prompt, completion and a desirable/undesirable label. Managed validation requires both feedback classes and a batch size of at least two.
• Reward modeling trains a scalar scoring model from preferred/rejected pairs and exports the trained score head with the model or adapter.
• Offline knowledge distillation trains a student using supplied examples, target answers and a frozen teacher. Pin the teacher revision and adjust its temperature and loss weight. Teacher and student must have compatible tokenizers, vocabulary and chat templates, with memory for both models.

Review, tune and compare

Choose compatible LoRA or full-weight settings, precision, quantization and hyperparameters. Preference methods expose beta. Dataset imports, column mapping, sample formats and pre-launch validation use the same training composer as fine-tuning. Prompt grouping keeps the same prompt out of both training and held-out evaluation.

Set the run's spending limit, inspect its workload specification, then launch. Results include the exported model or adapter, loading instructions, exact configuration, split identities and baseline/final held-out measurements. Recovery uses the managed trainer's saved state for these supported recipes.

The distillation recipe uses a frozen local teacher on the supplied dataset. For on-policy generation, remote teachers, custom rewards, PPO or other RLHF programs, supply your own implementation. Available managed GRPO workflows are covered in RL below.

Configure post-training · Bring your training program

Build on existing language-model weights or start from random initialization. New run offers Continued pretraining and Pretraining from scratch, with a managed recipe when supported and a custom-code path for your own trainer.

Corpus and training controls

• Use text passages from uploaded, saved, Hugging Face or HTTPS datasets, with configurable text columns and file selection.
• Continued pretraining uses a pinned model revision. Training from scratch selects random initialization, full model weights and no quantization.
• Set precision, sequence length, batch size, gradient accumulation, learning rate, epochs or step count, seed and held-out fraction. Review data and the exact configuration before launch.
• Choose minimum GPU memory, an optional GPU model, vCPUs, disk, allowed regions, saved secret references and a container image. Preset resource estimates adjust with the model and method while keeping your explicit edits.

Bring your own training stack

Submit a container command, a verified GitHub revision, or an uploaded script or project. Public repositories and team-connected private repositories are supported. Prepared code and dataset selections can produce an editable command suggestion. Review it or enter your own command, then save the setup for reuse.

Custom code supports your own framework, streaming data and distributed launcher. Request the exact GPU count offered by the deployment on one machine. Your program must implement distributed execution. The managed recipe remains a single-GPU workflow. Vision, diffusion, audio, multimodal, embedding, classification and forecasting selections also use customer-supplied code.

Observe and resume

Follow execution events, logs and the measurements your trainer reports. For custom training, write complete recovery files to NODUS_CHECKPOINT_DIR, which defaults to state, and load them when restarting. Whole-folder saving is an explicit opt-in. Native managed-recipe recovery includes trainer state. Download final weights and other declared results separately from recovery files.

Set up pre-training · Code and workload setup

Adapt a model to your examples, review the setup, follow the run and download its outputs. Start in New run > Supervised fine-tuning (SFT). Managed recipes are offered when supported by the deployment. Custom code lets you bring your own training program.

Models and methods

• Choose a LoRA adapter or full model weights, with BF16, FP16 or FP32 precision. Compatible LoRA configurations also offer 4-bit QLoRA.
• Start with pinned Qwen3 0.6B, 1.7B or 4B presets, or supply a Hugging Face model and exact commit. Managed models must work with Transformers without remote code.
• Set epochs or maximum steps, learning rate, batch size, gradient accumulation, sequence length, LoRA rank and alpha, evaluation fraction and random seed. Truncating long examples is an explicit choice.

Data and launch review

Upload JSONL, JSON or CSV, including archives, or use a saved dataset, Hugging Face repository or direct HTTPS download. Map your own column names and select files. SFT accepts input/output pairs or conversations ending in an assistant answer. Private or gated dataset tokens are used for import only.

Validate configuration checks the selected examples before starting compute. The review includes dataset counts, a preview, the model, resources and spending limit. You can load or export configuration JSON and export the reviewed workload. Editing the setup requires another review. Managed inspection accepts up to 256 files, 256 MB and 200,000 examples, with at least five distinct prompts.

Progress, recovery and results

Follow logs and reported training measurements. The managed trainer saves its model or adapter, optimizer and progress state for supported recovery. Successful runs export model or adapter files, a loading script, the recipe, dataset split identities, held-out measurements and checksums. An adapter still needs its pinned base model. Evaluation reports the held-out result without promising a quality improvement.

Managed text recipes use one CUDA GPU. Use your own code for other frameworks, larger datasets or distributed training.

Configure fine-tuning · Training guide