# W&B 0.31 SDK: CoreWeave Forge Domains and Migration Checks

W&B SDK 0.31 changes the default API and app domains to CoreWeave Forge. Check credential compatibility, custom hosts, network rules and offline workflows before upgrading.

By Paras Madan | 2026-10-18


Weights & Biases SDK 0.31.0 changes the default server used by the Python package to CoreWeave Forge. For teams upgrading training environments or CI images, the immediate questions are which domain receives requests, whether saved credentials still work and whether their scripts expect the old run-link format.

The [SDK release arrived on October 16](https://github.com/wandb/wandb/releases/tag/v0.31.0). CoreWeave's broader Forge rollout happened earlier: its [customer FAQ dates the SaaS sign-in transition to September 30](https://www.coreweave.com/companies/weights-and-biases). The new SDK now incorporates Forge addresses into its defaults and generated links, alongside improvements to offline runs and local inspection.

## Which W&B addresses change?

The default API address is now `https://api.forge.coreweave.com`. Run, project, sweep and login links use the application at `https://forge.coreweave.com/wandb`. Those generated links also point to Forge when the configured API base remains `https://api.wandb.ai`.

The distinction between an API address and a browser address matters when editing configuration. The [URL handling in the 0.31.0 tag](https://github.com/wandb/wandb/blob/v0.31.0/wandb/sdk/lib/urls.py) normalizes the Forge proxy address, `https://forge.coreweave.com/api/wandb`, to the direct API host. A bare Forge website address or its `/wandb` application path is rejected as an API base.

Copy the API address from the release documentation when configuring a public-cloud client. Pasting the page open in your browser into a server setting can produce an invalid configuration even though both addresses belong to the same service.

## How existing saved keys are handled

The [tagged credential reader](https://github.com/wandb/wandb/blob/v0.31.0/wandb/sdk/lib/wbauth/wbnetrc.py) first looks for credentials matching the requested host in the local netrc file. If the Forge host has no matching entry, it checks the corresponding older W&B API host. That provides the compatibility path for an existing key saved against `api.wandb.ai`.

This fallback is why the release says existing users do not need to log in again solely because the default address changed. It does not repair an expired key, supply credentials to a fresh CI worker or give an account access to a different project.

For a self-hosted or dedicated deployment, keep the organization's configured server address. CoreWeave's FAQ says those accounts retain their existing sign-in arrangements. A change to the public-cloud default is a reason to inspect explicit configuration before updating a shared environment.

## What to check before rolling out the upgrade

Start with a small test job using the same container, credentials source and network path as normal training. Confirm that it creates a run in the intended project, logs a metric and opens the expected run page. If your workflow uses artifacts, include an upload and download in that test.

Teams with outbound domain restrictions should review whether the new API and application hosts are allowed. That is a practical consequence of changing destinations, not a report that this release has broken corporate networks. Ask the owner of those rules to approve any required change rather than broadening access unnecessarily.

Also review code that parses run URLs or compares their prefixes. A script can successfully log data and still mishandle a generated Forge link if it assumes every result begins with the old domain. Check notifications and dashboards that consume those links as part of the same rollout.

Pin the SDK version during validation so a rebuild does not quietly test a different dependency set. Keep the test small enough that you can inspect its results before applying the upgrade across longer-running jobs.

## Offline runs and local inspection gain useful controls

Version 0.31 adds offline support for `wandb.init(resume="must")`; synchronization fails when there is no run to resume. For an offline training workflow, test that failure path as well as a successful continuation, especially if scripts previously assumed sync would create a new run.

The release also adds a local sweep scheduler using Optuna or Ax. Teams using those optimizers can evaluate the new scheduler against their existing sweep configuration without changing every experiment at once.

For monitoring, [LEET's summary command](https://github.com/wandb/wandb/pull/12951) condenses a local `.wandb` file into run state, recent values, configuration and console output. The release adds JSON output and a follow mode, making recorded run information easier for scripts and coding agents to consume. Treat that output as evidence to inspect before deciding whether a job needs intervention.

The upgrade is worth a controlled trial for teams maintaining W&B integrations. Validate the destination and credentials first, then test the offline or inspection features your workflow actually uses. That gives the SDK change a manageable scope while preserving confidence in where experiment data is being logged.

I'm Paras.

I help AI teams turn technical launches into clear product stories and get them in front of the right readers.

[Book a 30-minute call](https://cal.com/paras-madan/30min).