Modal Release Notes

• The new metrics observability surface provides a flexible query interface for fetching detailed time-resolved data about performance and resource consumption:

  • Use the new modal function metrics / modal server metrics CLIs to export metrics to JSON or CSV.
  • Use methods in the new Function.metrics / Server.metrics namespaces to operate on metrics in code.

• It’s now possible to programmatically manage Service Users:

  • Use the new modal workspace service-users CLI to create, inspect, delete, and update the roles of Service Users.
  • Use methods in the new Workspace.service_users namespace to perform the same operations in code.

• We’ve increased the feature set around autoscaling configuration:

  • The new Function.autoscaler.settings() / Server.autoscaler.settings() methods report the current configuration with provenance for any overrides that are in effect.
  • The new Function.autoscaler.update() / Server.autoscaler.update() methods replace the existing .update_autoscaler() methods, which are now deprecated.
  • Use commands in the new modal function autoscaler / modal server autoscaler groups to query or update the autoscaler configuration from the command line.

• The modal function calls and modal server requests CLI commands now support --since and --until filters for fetching historical data.

• The Modal SDK now supports Python 3.15. Of note, the new lazy import syntax makes it easier to use third-party libraries that are not available locally or in all remote Images.

• The Sandbox.from_name() method will now return the most recently-terminated Sandbox that used the name (if it has not been claimed since) with include_terminated=True.

• The modal run CLI can now read a script from stdin when passed as -, e.g. modal run - <<'EOF' followed by an inlined script. The App must have a single local entrypoint or, otherwise, a single Function.

• Writes through the Sandbox.filesystem methods are now even more performant.

• We’ve added CLI commands for observability over Modal Endpoints:

• modal endpoint info displays basic metadata.

• modal endpoint stats reports aggregate performance metrics.

• modal endpoint logs fetches or streams logs.

• The modal function stats and modal server stats commands (along with the Function.stats() and Server.stats() methods) now include a container_total_count value, reporting the number of containers that were live at any point in the interval.

• The Server.sessions.start() method will now wait up to 25 minutes if no container is available to place the session. Add timeouts in user code where queuing is not desired.

Sandboxes now use our next-generation backend, affording substantially higher creation rates and concurrency limits for CPU Sandboxes

No code changes are required, but there are some semantic differences to be aware of:

• The modal.Sandbox.create() method now blocks until the Sandbox is scheduled instead of returning immediately.
• If a Sandbox is unable to be scheduled (e.g. due to unsatisfiable resource or placement requests), creation will time out and raise a ResourceExhaustedError.

Functions and Servers can now run on ephemeral multi-node clusters for large-scale training or inference workloads

• Add the @modal.clustered() decorator to your function or class.
• Use the new modal.Cluster object within each process to determine the rank and private IPs of containers in the cluster.

Servers now support sticky sessions with strong affinity guarantees, which is useful for workloads that require WebSockets to connect or reconnect to the same container

• Add the @modal.sessioned() decorator to the class defining the Server.
• Use the new Server.sessions.start() method to retrieve a token that you can pass in a Modal-Authorization header.
• Use the new Server.sessions.terminate() method to terminate a session, or else it will remain active until its idle timeout.

The CLI and SDK have a number of new features to support programmatic observability, oriented towards both coding agents and scalable scripted workflows

• We’ve added modal function and modal server CLI surfaces for inspecting specific Function or Server entities. Commands include info, stats, logs, and calls/requests.
• We’ve added corresponding methods to the modal.Function and modal.Server objects in the SDK.
• Apps can also be inspected using the new modal app info CLI and modal.App.info() method.
• The “variants” of a Function (i.e. specific parameterizations or dynamic configurations) can be listed via the modal function variants CLI.

Sandboxes can now use a full virtual machine as the runtime, providing better support for workflows like running Docker

• Set runtime="vm" in modal.Sandbox.create() to enable.
• To force continued use of the gVisor runtime, set runtime="gvisor". This is the current default behavior, but the default may change in the future.
• The modal shell command also now supports a --runtime option.

This release includes numerous other enhancements

• It’s now possible to set a strict concurrency limit on a Server by setting max_concurrency= in the @app.server() decorator. Requests will be rejected with a 503 status when a Server is at its limit.
• A client’s connection to a Sandbox is now dropped automatically after a period of inactivity and reconnected if the Sandbox is used again. This makes Sandbox.detach() optional.
• You can now programmatically list Apps via the modal.Environment.apps.list() method.
• The modal token new CLI now supports --expires-in to set a TTL for the token.
• Proxy tokens can now be named via modal workspace proxy-tokens or modal.Workspace.proxy_tokens.
• The modal app list CLI now orders Apps by recency and supports a --limit option.
• The FunctionCall.get_call_graph() method now returns up to 5,000 nodes (previously 100).
• Large file downloads via the modal volume CLI are now more resilient to transient errors.

Finally, we’ve made a small number of breaking changes

• Classes decorated with @app.cls() can no longer define a custom __init__ constructor. Use modal.parameter() for parameters and @modal.enter() for initialization logic.
• We’ve removed legacy APIs for interacting with a Sandbox’s filesystem, including Sandbox.open(), Sandbox.ls(), Sandbox.mkdir(), Sandbox.rm(), Sandbox.watch(), the modal.file_io.FileIO type, and the modal.exception.FilesystemExecutionError exception. Use the Sandbox.filesystem APIs instead.
• We’ve removed the experimental modal bootstrap CLI; use modal endpoint create to quickly stand up production-ready endpoints.
• We’ve removed several undocumented properties and methods that had no intended user-facing functionality.
• We’ve made minor changes to JSON output in the CLI:
  • modal volume ls now shows created_modified as an ISO 8601 timestamp and size as an integer number of bytes.
  • modal queue list now shows partitions and total_size as integers and includes a boolean total_size_truncated field.

• We’ve added a modal.Sandbox.logs API, allowing you to fetch() logs from a specific date/time range or to tail() the most recent logs. Note that only logs from the entrypoint process of a Sandbox are currently stored, and streaming logs via this interface is not currently supported.

• It’s now possible to configure the default role when creating a new Restricted Environment via the CLI or SDK. See the RBAC Guide for more details on default environment roles.

• The modal CLI now accepts a global --profile option for simpler ad hoc profile selection.

• We are deprecating a number of undocumented APIs on object types in the Modal SDK. These APIs have no intended user-facing functionality and will be removed in version 1.6.0. To be safe, check for deprecation warnings on this version before upgrading.

With this release, it’s now possible to opt into a more performant Sandbox backend, which affords substantially higher creation rates and concurrency. Set MODAL_SANDBOX_V2=1 as an environment variable and your Sandboxes will use this new system without any code changes. This will become the default behavior in version 1.6.0 of the Python SDK. Note that the new backend does not support the deprecated FileIO-based Sandbox filesystem API; please migrate any code that is currently issuing deprecation warnings before enabling the feature flag.

• We’ve added logs APIs to the modal.App and modal.Image objects:
  • The App.logs API allows you to fetch(), tail(), or stream() all logs from an App.
  • The Image.logs API supports fetch() and tail() on Image build logs. Streaming build logs is not supported at this time.
• We’ve also added a modal image logs CLI command with equivalent functionality.
• We now support querying basic information about your Workspace’s current pricing structure via the Workspace.billing.rates() API and modal billing rates CLI.
• The Function.update_autoscaler() and Server.update_autoscaler() methods now return the complete state of the autoscaler configuration after applying the update.
• The target_concurrency parameter in @app.server() and Server.update_autoscaler() now supports fractional values for more fine-grained control over autoscaling behavior.

We’ve added new APIs for programmatically retrieving logs on several object types: Function, Server, and FunctionCall.

Each object exposes three different methods, allowing you to stream() logs as they are generated, fetch() logs from a specific date/time range, or tail() the most recent logs.

It’s now possible to retrieve a summary of billing information across billing cycles:

• Use the modal.Workspace.billing.summary() method or the modal billing summary CLI to see workspace-level spend (broken down by category), credit usage, and the impact of any compute reservations.
• Use the modal.Environment.billing.summary() method or the modal environment billing summary CLI to see environment-level spend.

We’ve made some changes to the interfaces for managing RBAC permissions:

• We now explicitly represent all workspace member and service user roles in each Environment instead of having separate concepts for Environment membership and role.
• We’ve accordingly introduced a modal.Environment.roles interface (and modal environment roles CLI), replacing the modal.Environment.members interface and modal environment members CLI, which are now deprecated.

It’s now possible to specify one or more --compute-region options in modal endpoint create to configure the region where Endpoint containers run.

We’ve improved performance for large writes by ≈2.5x in several Sandbox filesystem methods (copy_from_local(), write_bytes(), and write_text()).

• We’ve added new interfaces for programmatic management of workspace settings:

• Use the modal.Workspace.settings.list() method or modal workspace settings list CLI to see current workspace-level settings.

• Use the modal.Workspace.settings.set() method or modal workspace settings set CLI to configure new values.

• We’ve added a modal.types module for exposing dataclasses returned from public methods as public API. The types in this module are not typically constructed by user code, but it may be useful to reference them for, e.g., adding type annotations to code that wraps the relevant Modal API.

• The modal.Function.with_options() method now accepts a routing_region argument to dynamically configure regional routing at the time of invocation.

• The modal container stop CLI now accepts a --graceful flag. With it, the container stops fetching new inputs but finishes the inputs it is currently running before exiting, instead of having them cancelled and rescheduled. Graceful stops are only supported for containers running a Modal Function or Modal Server.

• The modal container logs CLI now includes logs from the startup phase of the container.

• The modal.Workspace.members.list() method now uses "member" instead of "user" for the lowest-privilege Workspace role, matching the UI and documentation.

• The modal.Sandbox.reload_volumes() method now blocks until the Volumes have been reloaded, bounded by a new timeout argument (55 seconds by default). If the reload does not complete within timeout, modal.exception.TimeoutError is raised.

This release includes several major new features, including the debut of a new serverless compute primitive for low-latency HTTP applications (@app.server()) and a new CLI for deploying production-ready LLM inference endpoints with minimal configuration (modal endpoint).

• We’re introducing a new @app.server() decorator (and modal.Server object), representing a serverless compute primitive that shares many features with Modal Functions while being optimized for serving HTTP-based applications with ultra-low latency. Read the guide for more information.
• We’re also introducing the modal endpoint CLI, providing programmatic access to our new Endpoints product. Endpoints let you deploy production-ready LLM inference servers with minimal configuration.
• We’ve added several new SDK features for workspace configuration and observability:
  • We’ve added new billing API methods on the modal.Workspace and modal.Environment objects (workspace.billing.report() and environment.billing.report(), respectively). The new APIs include a resource-level cost breakdown (CPU, memory, and specific GPU types). We’ve also added a modal environment billing CLI for generating environment-scoped billing reports. The new workspace-level API replaces the existing modal.billing.workspace_billing_report function.
  • We’ve added support for creating and managing proxy tokens via the modal.Workspace object (workspace.proxy_tokens.create(), workspace.proxy_tokens.list(), etc.) and a new modal workspace proxy-tokens CLI. Modal Servers and Endpoints are authenticated via proxy tokens by default.
  • We’ve added a new modal workspace members CLI for querying information about workspace membership.
• The new modal curl CLI command allows you to make requests to authenticated endpoints without explicitly passing proxy token headers. This is an experimental feature and may change in the future.
• The modal app rollback command now accepts a --strategy (rolling or recreate), like modal deploy and modal app rollover.
• Sandbox connect tokens can now be scoped to a custom port (modal.Sandbox.create_connect_token(port=...)).
• It is now possible to call image.publish() on an Image constructed using modal.Image.from_id() without first calling image.build().
• The Modal Python client now respects standard environment variables for HTTP CONNECT and SOCKS4/5 proxies (HTTPS_PROXY and ALL_PROXY). Proxy support requires installing extra dependencies, i.e. using uv pip install 'modal[api-proxy-support]'. To opt out of proxy support, set MODAL_DISABLE_API_PROXY=1 or put disable_api_proxy = true in your .modal.toml profile.

This is a major release that includes several new features (named Images, version-pinned Function lookups, Sandbox domain allowlists), a new modal skills CLI, and a small number of breaking changes.

Named Images

We’re introducing a “named Image” concept, akin to a Modal-native Image registry. This feature allows you to decouple Image builds from App deployment or Sandbox creation, and it simplifies the process of sharing a canonical Image across a large number of unrelated Apps.

• The new SDK method modal.Image.publish() assigns a name to an existing Image. Names can optionally include a “tag” suffix ("{name}:{tag}") to specify variants of an Image, e.g. to apply a versioning system.
• The new SDK method modal.Image.from_name() refers directly to that Image by its name. Unlike with Image methods that specify parts of a build recipe, the modal.Image.from_name() lookup will either succeed or fail with a modal.exception.NotFoundError error, but it will never trigger a build.
• The new modal image names CLI can be used to see the current name assignments.

Version-pinned Function lookups

We’re introducing a “version-pinning” concept for Function lookups. By passing version= to modal.Function.from_name() or modal.Cls.from_name(), you can retrieve an instance that will send all inputs to the same version of the Function, even after a subsequent redeployment of its App. Additionally, any transitive invocations of other Functions in the same App will also be pinned on that version. This feature makes it easy to execute workflows that involve multiple Functions when those Functions might change in incompatible ways across deployments.

Sandbox domain allowlists

It’s now possible to restrict the domains that processes inside of a Sandbox can connect to. When you provide a list of domains to outbound_domain_allowlist=[...] in modal.Sandbox.create(), requests outside of the allowlist will be blocked by Modal infrastructure, and the denial will be recorded in the App logs.

modal skills CLI

We’ve added a new modal skills CLI for installing a foundational Modal agent skill (modal skills install) and keeping it up to date over time (modal skills update). Please help us improve it by sharing any feedback you have about its impact on agentic development with Modal.

Workspace object

We’ve added a new modal.Workspace object for programmatic interaction with your Workspace configuration. The initial release offers a workspace.members.list() method; expect more features soon.

CLI JSON output normalization

The modal CLI now normalizes the keys of its --json output by lowercasing and substituting underscores for non-alphanumeric characters.

Sandbox Filesystem watch

We’ve added a new sandbox.filesystem.watch() method to the Sandbox Filesystem API, and we’ve deprecated the alpha modal.Sandbox.watch() method. The new method has a different implementation and offers significantly improved latency and reliability.

Sandbox snapshots

We’ve made two small breaking changes around Sandbox snapshots:

• modal.Sandbox.snapshot_filesystem() and modal.Sandbox.snapshot_directory() now accept an explicit ttl= keyword argument that configures a retention interval (in seconds) for the resulting Image. Both methods default to 30 days (ttl=30 * 24 * 3600). Note: this alters the default behavior of these methods, because snapshot Images were previously persisted indefinitely. Pass an explicit ttl=None to retain the previous behavior.
• modal.Sandbox.snapshot_directory() now also accepts a timeout= keyword argument (defaulting to 55 seconds), which brings it to parity with modal.Sandbox.snapshot_filesystem(). If the snapshot does not return before the deadline, a modal.exception.TimeoutError will be raised. Note: this alters the default behavior, which previously waited indefinitely, but you can set an arbitrarily long timeout.

Removed deprecated static methods

We’ve removed several deprecated static methods (.delete() and .create_deployed()) on Modal storage objects (modal.Volume, etc.). Use the .objects.delete() and .objects.create() methods instead.

Public Beta

• This release introduces a new “regional routing” concept for Function inputs, which is now in Public Beta. By setting routing_region="..." in the @app.function() or @app.cls() decorators, you can configure the Function to route its inputs through servers in us-west, eu-west, or ap-south instead of us-east. This can reduce network latency and help you meet data residency obligations. While in Beta, this feature has a few constraints:
• A routing_region can be set only during the initial deployment of a Function and cannot be changed in a subsequent redeployment.
• Functions using regional routing can only be invoked with the .remote() and .map() methods.

• We’ve added a new modal.Environment object for programmatically managing Environments, and we’ve expanded the modal environment CLI to support RBAC configuration.

• It is now possible to dynamically configure modal.Function behavior using Function.with_options(), Function.with_concurrency(), and Function.with_batching().

• The new modal.Volume.with_mount_options() method allows you to configure a Volume mount as read-only (read_only=True) and / or limit the mount to a subdirectory of the Volume (sub_path="/some/path").

• It’s now possible to pass a custom App name for ephemeral Apps using the --name option in modal run / modal serve or by setting name= in App.run().

• We’ve added two new methods to the modal.Sandbox Filesystem API:
• sandbox.filesystem.list_files(path) lists entries (with metadata) in a given directory on the Sandbox filesystem. This replaces the alpha modal.Sandbox.ls method.
• sandbox.filesystem.stat(path) returns metadata for a specific file/symlink/directory on the Sandbox’s filesystem.

• It’s now possible to place restrictions on inbound Sandbox connections by setting inbound_cidr_allowlist=[...] in modal.Sandbox.create(). We are also adding a new outbound_cidr_allowlist=[...] parameter and deprecating the existing cidr_allowlist=[...] to avoid confusion.

• We’ve improved the reliability of the modal.Sandbox.snapshot_filesystem() operation, especially for large snapshots, and we now support setting a timeout= longer than 55s when necessary.

• Images returned by modal.Sandbox.snapshot_directory() can now be passed to modal.Sandbox.create() to use as a root filesystem for the new Sandbox.

• We’ve added a modal.Image.pipe() method to let you define reusable Image recipes that compose well with the fluent Image builder interface.

• It’s now possible to assign Sandbox tags at creation with modal.Sandbox.create(..., tags=tags).

• It’s now possible to use --chmod and --chown flags on COPY commands within modal.Image.from_dockerfile().

• We’ve improved the reliability and latency for modal shell and modal container exec CLI commands.

• We’ve added a new modal app rollover CLI command for triggering a redeployment of an App without making any code or configuration changes. A rollover replaces existing containers with fresh ones. As with modal deploy, there are two strategies for switching between deployments:

  • --strategy=rolling (the default) will smoothly migrate traffic from old containers to new containers
  • --strategy=recreate will terminate all running containers so that any subsequent inputs will go to new containers

• We’ve added a new modal bootstrap CLI command, which fetches deployable starter code for common AI applications (e.g., text generation, text-to-image, speech-to-text). This is an experiment: try it out and give us feedback!

• We’ve added two methods to the new Sandbox filesystem API:

  • sandbox.filesystem.make_directory() creates a new directory on the Sandbox filesystem
  • sandbox.filesystem.remove() deletes a file or directory from the Sandbox filesystem

• The new Sandbox filesystem methods replace the modal.Sandbox.mkdir and modal.Sandbox.rm methods, which are now deprecated.

• Sandboxes also now support sb.unmount_image(path) to remove a previously mounted Image from a path and reveal the underlying Sandbox filesystem there again.

• The modal app stop and modal container stop CLI commands now prompt for confirmation (pass --yes to skip).

• Several other modal app CLI commands will now map a name-based argument to a recently-stopped App that used that name. This is useful for, e.g., fetching logs from an App after it has been stopped.

• We’ve added a build_args parameter to modal.Image.dockerfile_commands().

• We’re introducing a concept of “readiness probes” for modal.Sandbox. This feature lets you configure a readiness check on a TCP port (modal.Probe.with_tcp()) or by executing a process (modal.Probe.with_exec()). Calling sb.wait_until_ready() will block until the Probe succeeds:

app = modal.App.lookup('sandbox-app', create_if_missing=True)
probe = modal.Probe.with_tcp(8080)
sb = modal.Sandbox.create("python3", "-m", "http.server", "8080", readiness_probe=probe, app=app)
sb.wait_until_ready()

• We fixed a longstanding bug that could cause WebSocket performance to degrade after handling hundreds of connections from the same container.
• We improved the performance of modal container logs when fetching logs for an old container.
• We fixed a bug introduced in 1.4.0 that made the modal CLI crash on typer<0.19.0.

We’ve made significant CLI enhancements so that Modal logs can be more accessible to coding agents:

• The modal app logs and modal container logs commands now have the ability to fetch historical logs using counting (e.g. --tail 1000 ) or time-based (e.g., --since 4h , --until 2026-03-15 , etc.) configuration. Note that historical log access is subject to plan-level retention limits.
• The modal container logs command also accepts --all to fetch the complete set of logs for that Container or Sandbox.
• Both CLI commands now accept a --search filter, and they can also filter by --source ( stdout / stderr / system ).
• The modal app logs command additionally accepts --function , --function-call , and --container filters.
• The modal app logs command can prefix each line with the ID of the Function, FunctionCall, or Container where it originated (e.g. --show-function-id ).
• Note that the default behavior of these commands has changed. Previously, they would follow (i.e., stream) logs by default, but you now must pass --follow to get this behavior. The new default will always show the most recent 100 log entries.

We’re releasing a new Sandbox filesystem API (currently in Beta) with significantly improved reliability and ergonomics:

• Use sb.filesystem.copy_from_local / sb.filesystem.copy_to_local to transfer file contents between your local filesystem and the Sandbox filesystem.
• Use sb.filesystem.write_text / sb.filesystem.read_text or sb.filesystem.write_bytes / sb.filesystem.read_bytes to transfer file contents between local memory and the Sandbox filesystem.
• These new APIs replace the modal.Sandbox.open method and the modal.file_io.FileIO type that it returns; the old APIs are now deprecated.

We’re introducing the concept of “deployment strategies” to give you more flexibility over what happens when redeploying your App:

• By passing modal deploy --strategy recreate (or app.deploy(strategy="recreate") in the SDK), you can immediately terminate any containers that are running when the deployment completes. This is most useful for development workflows, as it guarantees that any subsequent input will be handled by containers running the new version of the App. This trades off some downtime for certainty about when the new version will be in use.
• The disruptive “recreate” strategy is also useful when your App runs at its max_containers limit, as otherwise we are unable to bring up replacement capacity.
• The modal serve command now uses a “recreate” strategy during code updates.
• The default “rolling” strategy is unchanged. This strategy prioritizes uptime, but means that old containers may still continue handling inputs for some time.

We’ve also included a number of smaller new features and improvements:

• Sandboxes now accept an include_oidc_identity_token parameter in modal.Sandbox.create. When set to True , a MODAL_IDENTITY_TOKEN environment variable will be injected into the Sandbox, enabling OIDC-based authentication (e.g., for AWS federation). See the OIDC integration guide for more details.
• The new modal.Image.from_scratch() constructor creates an empty Image, equivalent to FROM scratch in Docker. This is primarily useful as a lightweight filesystem to mount into a Sandbox via modal.Sandbox.mount_image.
• The modal container list command now accepts an --app-id filter to return containers for a specific App.
• We’ve addressed an issue where modal.Sandbox.exec could hang if the Sandbox had terminated immediately after creation.
• An exception is now raised if the same Volume or CloudBucketMount is mounted at multiple paths in a container.
• The client will now error faster (≈60s) if it cannot establish an initial connection the Modal servers.

Finally, we are introducing a small number of breaking changes and enforcing some deprecations of pre-1.0 APIs:

• Exceptions returned by modal.Function.map() are no longer wrapped in a UserCodeException type, and we’re deprecating the transitional wrap_returned_exceptions= parameter.
• The modal.enable_output() context manager no longer yields a value; this had briefly leaked an internal type.
• We’ve removed unused namespace parameters from a number of APIs.
• It’s now required to pass -m on the CLI when using a module path spelling of the Function reference (e.g. modal deploy -m project.app )
• We’ve removed backwards compatibility for the old autoscaler configuration ( keep_warm , concurrency_limit , etc.).
• It’s no longer possible to look up a specific method on a Cls using modal.Function.from_name ; use modal.Cls.from_name instead.

• We’ve added a modal changelog CLI for retrieving changelog entries with a flexible query interface (e.g. modal changelog --since=1.2 , modal changelog --since=2025-12-01 , modal changelog --newer ). We expect that this will be a useful way to surface information about new features to coding agents.

• We’ve added a new modal.Secret.update method, which allows you to programmatically modify the environment variables within a Secret. This method has the semantics of Python’s dict.update : Secret contents can be overwritten or extended when using it. Note that Secret updates will take effect only for containers that start up after the modification.

• The dataclass returned by modal.Function.get_current_stats() now includes a num_running_inputs field that reports the number of inputs the Function is currently handling.

• We’re introducing “Directory Snapshots”: a new beta feature for persisting specific directories past the lifetime of an individual Sandbox. Using the new methods modal.Sandbox.snapshot_directory() and modal.Sandbox.mount_image(), you can capture the state of a directory and then later include it in a different Sandbox:

sb = modal.Sandbox.create(app=app)
snapshot = sb.snapshot_directory("/project")
sb2 = modal.Sandbox.create(app=app)
sb2.mount_image("/project", snapshot)

This feature can be useful for separating the lifecycle of application code in the Sandbox’s main Image from project code that changes in each Sandbox session. Files in the mounted snapshot also benefit from several optimizations that allow them to be read faster. See the Sandbox Snapshot guide for more information.

• We’ve added a new modal.Sandbox.detach() method that we recommend calling after you are done interacting with a Sandbox. This method disconnects your local client from the Sandbox and cleans up resources associated with the connection. After calling detach, operations on the Sandbox object may raise and are otherwise not guaranteed to work.

• The modal.Sandbox.terminate() method now accepts a wait parameter. With wait=True, terminate will block until the Sandbox is finished and return the exit code. The default wait=False maintains the previous behavior.

• Throughput for writing to the stdin of a modal.Sandbox.exec process has been increased by 8x.

• We’ve added a new modal.Volume.from_id() method for referencing a Volume by its object id.