Skip to content
OpenPond
ChangelogSupport
Overview/Changelog

Changelog

Published releases for the SDK, Evals, Harness, Desktop, API, and Sandbox.

The latest ten stable releases for each product, newest first. SDK, Evals, Harness, and Desktop notes come from OpenPond's public GitHub releases and refresh hourly. API and Sandbox notes publish after successful production activation and use a five-minute server cache.

Dates are in UTC. Browse earlier releases and Desktop nightlies on GitHub.

SDK

SDK 0.12.9 — 2026-10-24

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.63-nightly.20261024.358...sdk-v0.12.9

SDK 0.12.8 — 2026-10-24

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.63-nightly.20261023.357...sdk-v0.12.8

SDK 0.12.7 — 2026-10-23

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/evals-v0.12.2...sdk-v0.12.7

SDK 0.12.5 — 2026-10-15

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.60...sdk-v0.12.5

SDK 0.12.4 — 2026-10-15

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/evals-v0.12.1...sdk-v0.12.4

SDK 0.12.3 — 2026-10-13

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/sdk-v0.12.2...sdk-v0.12.3

SDK 0.12.2 — 2026-10-12

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/sdk-v0.12.1...sdk-v0.12.2

SDK 0.12.1 — 2026-10-11

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/harness-v0.4.8...sdk-v0.12.1

SDK 0.12.0 — 2026-10-11

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/evals-v0.12.0...sdk-v0.12.0

SDK 0.11.6 — 2026-10-11

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/evals-v0.11.21...sdk-v0.11.6

Evals

Evals 0.12.3 — 2026-10-23

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/evals-v0.12.2...evals-v0.12.3

Evals 0.12.2 — 2026-10-23

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/cli-v0.2.63...evals-v0.12.2

Evals 0.12.1 — 2026-10-15

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.59...evals-v0.12.1

Evals 0.12.0 — 2026-10-11

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/sdk-v0.11.6...evals-v0.12.0

Evals 0.11.21 — 2026-10-11

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/harness-v0.4.7...evals-v0.11.21

Evals 0.11.20 — 2026-10-06

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.46...evals-v0.11.20

Evals 0.11.19 — 2026-10-02

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/harness-v0.4.5...evals-v0.11.19

Evals 0.11.17 — 2026-10-01

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/sdk-v0.10.0...evals-v0.11.17

Evals 0.11.16 — 2026-10-01

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/evals-v0.11.15...evals-v0.11.16

Evals 0.11.15 — 2026-10-01

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/sdk-v0.9.9...evals-v0.11.15

Harness

Harness 0.4.10 — 2026-10-23

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/cli-v0.2.63...harness-v0.4.10

Harness 0.4.9 — 2026-10-15

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.58...harness-v0.4.9

Harness 0.4.8 — 2026-10-11

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/sdk-v0.12.0...harness-v0.4.8

Harness 0.4.7 — 2026-10-11

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.56...harness-v0.4.7

Harness 0.4.6 — 2026-10-06

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/packages-preview-66da475fd1bc6e8435295ecb760e33737c109f41...harness-v0.4.6

Harness 0.4.5 — 2026-10-02

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.45-nightly.20261002.286...harness-v0.4.5

Harness 0.4.4 — 2026-09-25

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.30...harness-v0.4.4

Harness 0.4.3 — 2026-09-24

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.22...harness-v0.4.3

Harness 0.4.2 — 2026-09-23

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.21...harness-v0.4.2

Harness 0.4.1 — 2026-09-23

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/evals-v0.11.4...harness-v0.4.1

Desktop

Desktop 0.2.63 — 2026-10-21

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.62...v0.2.63

Desktop 0.2.62 — 2026-10-16

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.61...v0.2.62

Desktop 0.2.61 — 2026-10-15

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.60...v0.2.61

Desktop 0.2.60 — 2026-10-15

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.59...v0.2.60

Desktop 0.2.59 — 2026-10-15

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.58...v0.2.59

Desktop 0.2.58 — 2026-10-14

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.57...v0.2.58

Desktop 0.2.57 — 2026-10-13

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.56...v0.2.57

Desktop 0.2.56 — 2026-10-10

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.55...v0.2.56

Desktop 0.2.55 — 2026-10-10

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.54...v0.2.55

Desktop 0.2.54 — 2026-10-10

GitHub release

What's Changed

Full Changelog: https://github.com/openpond/openpond/compare/v0.2.53...v0.2.54

API

API 7a1a90c7dc0b — 2026-10-28

Consistent missing sandbox secret responses

Sandbox secret metadata requests return HTTP 404 when the secret does not exist or has been deleted, instead of reporting an internal server error. The existing error code remains unchanged.

Preserve complete process output through runner transport

Sandbox exec, process, and PTY responses retain output and cursor data through runner delivery and storage, preventing long output from being silently shortened. Responses that exceed the transport's supported size are rejected explicitly.

Clearer worker-control errors when provider state changes

Worker controls return a conflict when the bound provider resource has disappeared, and a temporary-unavailability error when provider status cannot be verified. Refresh the worker before retrying a lifecycle action.

Enable hosted GPU training

Eligible workspaces can run funded training with Daytona CPU sandboxes and Runpod GPU workers. Runs retain checkpoints and final evaluations, with usage settled through workspace funding.

Reconcile newly created CPU capacity

Automatic CPU provisioning retains newly created hosts for a fresh identity check before qualification, so incomplete creation metadata does not permanently quarantine capacity. Cleanup of a host that never qualified can complete while unrelated baseline work continues. Funding and provider identity checks remain in force.

Recognize CPU-only capacity plans

Automatic CPU capacity planning accepts CPU-only plans when the provider returns empty GPU metadata. Funding, placement, capacity and cost checks continue to apply.

Wait for occupied sandbox CPU quota

Managed training now waits within its existing execution deadline when other sandboxes occupy the organization's CPU quota, instead of immediately failing the run. Organization quotas and approved spending limits remain enforced.

Include running disk costs in GPU usage

Runpod training usage and funded GPU retention include the attached running disk costs already included in the admission quote. Approved spending caps and historical sealed receipts remain unchanged.

Keep controller routing available after client cancellation

Canceling a request no longer marks its controller backend unhealthy. Backend transport failures continue to affect routing availability.

Safer automatic CPU provisioning

Operators can explicitly identify unrelated servers in a shared provider project without making them available for training or cleanup. Automatic CPU purchases still refuse unknown or conflicting inventory and now recheck project inventory immediately before creating a server, including for retained unsent requests.

Keep failed training CPU lanes out of reuse during cleanup

Training waits for a failed CPU lane to finish cleanup before reusing its capacity. This prevents a lane reset failure from racing another rollout while its sandbox is being deleted.

Recover safe sandbox requests from temporary provider errors

Training sandbox reads and identical file uploads can retry temporary provider failures within the existing request timeout. Sandbox creation and command execution are not repeated. Provider outages are recorded as infrastructure failures with sanitized request diagnostics.

Read Daytona training results consistently

Training accepts Daytona's absolute workspace file paths when collecting Work results. Result size, byte ranges and content hashes remain verified.

Validate GPU count for managed policy training

Managed GRPO policy submissions can request one or two GPUs. A two-GPU request requires the data-parallel capability, an exclusive Runpod allocation, and an independently qualified worker image. Unsupported requests are rejected before allocation; two-GPU availability stays disabled until the exact image passes numerical, cancellation and cleanup qualification.

Scoped worker hardware observations

Read paged hardware snapshots for workers owned by your workspace, including sample freshness and explicit unavailable metrics. Observation collection and uploads operate independently from worker heartbeat and training execution.

Preserve structured Model Project errors

Unexpected Model Project request failures return the documented v2 error envelope, so SDK callers receive a structured error with the HTTP status. Internal server details remain hidden.

Preserve task-specific instructions in Model configuration

Saving a Model configuration now retains the authored per-task instruction mode from its exact published Taskset package, so valid datasets with different instructions per task are no longer rejected as incompatible with their Reward.

Safer training admission and cleanup

Training waits when a static CPU controller credential cannot cover the declared work and cleanup period. Automatic CPU purchases recheck that coverage before creation. A cleanup failure for one terminal training job no longer blocks cleanup of other jobs; failed cleanup remains unresolved until its resource checks pass.

Keep CPU provisioning working when retired hardware is reused

Automatic training capacity can bind a new host when a provider reuses a retired server identifier. Active hosts retain exclusive ownership, and retired-host history stays intact.

Structured training edge failures

Unexpected failures at the training API edge use the training error format. Server failures return a stable error code without exposing internal query details.

Consistent authentication errors for training requests

Training and hardware-observation requests use the training error format when authentication or workspace access fails. Clients can read the HTTP status and structured error code consistently.

Fix Work command file ownership

Work commands now enforce their unprivileged execution identity in the process supervisor, allowing generated files to be read and saved through Work tools while preserving ownership checks and process cleanup.

Preserve training results when the runtime emits diagnostics

Training result collection now reads the harness's final receipt separately from preceding runtime diagnostics. It continues to verify the result file's identity, byte ranges and content hash.

Workspace usage follows normal billing for administrators

Usage by global administrators and managed-client operators now draws from the workspace's normal included usage, prepaid credits, and permitted overage. Administrator status no longer exempts workspace requests or training jobs from funding checks and charges.

Sandbox

Sandbox 7a1a90c7dc0b — 2026-10-28

Verify runtime cleanup after failed sandbox startup

Strict sandbox deletion now waits for cleanup by the assigned runtime agent even when startup failed before the sandbox became running. Runtime ownership is saved before boot dispatch, and missing or ambiguous cleanup ownership cannot count as confirmed cleanup. Guest firewall rules now include the IPv4 context required for conntrack address checks; setup failures identify the failed stage using bounded codes without exposing command output.

Retire image preparation child processes

Image preparation reaps its exited descendant processes before releasing runtime resources. Unconfirmed cleanup continues to block resource reuse.

Bind OCI imports to the current workload reservation

Dockerfile workload starts bind the observed Kubernetes workload Pod to their memory reservation before importing. A restart waits for that specific reservation to be published instead of selecting an earlier reservation for the same sandbox. Generation changes after admission still fail closed.

Reliable OCI network policy verification

OCI imports verify their network policies against the exact committed compiler acknowledgement, avoiding false failures from canonical output changes while retaining fail-closed isolation and cleanup.

Fix workload dispatch reservation context

Fixes workload starts and restarts failing before import when their private reservation context was lost during internal dispatch.

Preserve IPv4 connection-tracking restrictions

Sandbox firewall rules use typed IPv4 connection-tracking addresses and verify exact destination prefixes against the installed policy. Cleanup can finish after a previously owned network interface has already been removed, while retaining ownership checks.

Restart sandboxes created from uploaded source

Stopped sandboxes created from an uploaded Dockerfile source archive can reuse their verified source on restart. Restart refuses source that is unavailable or no longer matches the sandbox, instead of starting with missing input.

Wait for a stopping workload before restart

Restart preserves the bounded wait for a prior workload that is still terminating. It verifies ownership before accepting the replacement workload and never starts against a terminating Pod.

Top-level administration sections

Global administrators now have separate Admin, Product, Operations, Business, and Customer dropdowns alongside Account in the Console sidebar. Each section has a cyan heading and its own menu in the collapsed sidebar. The Reference / Internal Docs and AWS installations navigation entries have been removed. Sandbox control-plane reads are scheduled sequentially to avoid exhausting the web database connection pool while preserving its existing views and controls.

Administration in the Console sidebar

Global administrators can access Dashboard, Product, Operations, Business, Customer, and Reference pages from Account → Admin in the Console sidebar. Existing admin URLs and global-admin permissions are preserved. Resources groups infrastructure controls, and Serving is directly available under Ponder.

BYOC, serving models, and resource logs

Resources now labels infrastructure as BYOC, with an AWS setup card and a disabled Requested button after an access request. Databases shows explicit loading and connection states. Logs has source tabs and resource pickers for sandbox runtime and services, builds, app releases, and request traces. Serving has its own model inventory with version and deployment management, and the test-endpoint playground has been removed. Global control-plane audit reads have dedicated time indexes for large histories.

Keep Serving filters when inspecting versions

Serving keeps the workspace's search and status selection when you inspect a model version and return to the inventory.

Serving navigation and visible version actions

The Serving entry page shows Models, Deployments, and API tabs. Version and serving actions stay with the model name so they remain easy to reach while scrolling the model inventory on narrower screens.

Preserve structured training results when masking secrets

Training harness settings and task identities are kept separate from credential values, preserving valid structured rollout results. Credentials and customer environment secrets continue to be masked.

Inference joins Ponder

Find hosted models, your model deployments, usage and API access under Ponder → Inference. Managed inference uses OpenPond Chat labels while preserving model names and user-connected providers. Existing Gateway and Serving links redirect to the corresponding Inference pages.

More precise training release tracking

Training release records track original and observed component versions, completed cleanup and cancellation outcomes. Controller readiness checks use a bounded database liveness query while release capacity measurements remain separate.

Daytona training API connectivity

Daytona training uses separate staging and production API relays and the provider’s default outbound network policy. Custom per-sandbox outbound restrictions are deferred in this configuration; grading still runs in a separate guest with unprivileged verifier processes.

Start training with prearmed GPU retention

A newly started GPU in a funded retention session can accept its first job after positive engine health checks, without requiring an earlier inference request. Existing checks for used, failed or quarantined workers remain.

Direct learning review links

Dataset learning links open the selected saved policy. Candidate review links open the matching training job, and Model task and candidate pages retain their selected Model when reached from a Project learning policy.

Model learning controls in Console

Model pages now include a Learning tab with saved Dataset learning policies, configuration editing and links to retained policy iterations. Policy and iteration pages verify the selected Model and workspace, and learning request failures use the existing toast and retry controls.

Reliable Work scratch files

Work scratch files and directories use the task process’s identity, allowing commands to modify files created through Work tools while preserving guarded ownership and atomic writes.

Install control-plane defaults explicitly

API requests no longer seed sandbox control-plane defaults. Operators install missing defaults through the explicit database seed command, which preserves existing configuration, drains, keys and route ownership.

Hardware visibility in training runs

Training runs link to hardware observations in diagnostics, with CPU, container memory and visible GPU metrics. The fleet inventory also shows snapshot freshness and device identity.

Preserve downloaded file chunks

Sandbox file downloads over the runner task transport preserve complete file chunks and their byte counts, preventing larger downloads and collected work results from being corrupted by diagnostic compaction.

Stronger secret and workload isolation

Sandbox environment variables and registry credentials require tenant-owned OpenPond secret references. Process output preserves secret redaction across partial reads and concurrent updates. Workload image preparation uses a confined environment with resource limits and stricter host and private-network access; existing image caches are rebuilt under these isolation rules.

Use reserved memory when preparing workload images

Workload image preparation accounts for the sandbox's existing memory reservation and concurrent imports. Preparation stops when ownership or available capacity cannot be verified.

Preserve approved DNS through host translation

Workload image preparation and guest networking retain access to the configured DNS resolver when host networking translates its address, while preserving restrictions on other private network destinations.

View as Markdown