Per the branding rule: prose self-references say WaveSpeed; the
WaveSpeedAI form remains for package author metadata and the GitHub
org handle.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

Send X-Client-Name, X-Client-Version, and X-Client-OS on every API
request, following the wavespeed-desktop convention, so the backend can
attribute traffic to its originating client channel.

- Default name is "wavespeed-python"; a client_name constructor
  parameter allows integrations to brand themselves, and the
  WAVESPEED_CLIENT_NAME environment variable takes highest priority so
  wrapper channels can rebrand without code changes.
- Version comes from the package's setuptools_scm version; OS uses the
  desktop vocabulary (darwin/linux/win32) via platform.system().

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

…OS vocab

Cross-SDK audit fixes so all four WaveSpeed SDKs behave identically:

- Port run_no_throw from the JavaScript SDK: returns a structured
  {status, outputs, task_id, error} result instead of raising, and
  extracts the task_id from sync-timeout responses (code 5004) so the
  still-processing task can be queried later, mirroring runNoThrow.
  Exposed on Client and as module-level wavespeed.run_no_throw.
- Treat "cancelled" and "timeout" statuses as terminal failures in the
  wait loop (previously polled forever), surfacing the API's error text.
- Send "windows" instead of "win32" in X-Client-OS so all SDKs share
  the darwin/linux/windows vocabulary.
- Fix upload docstring in api/__init__.py: upload returns the URL str,
  not a dict.
- Document WAVESPEED_CLIENT_NAME in the README env-var table.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

llama-index-tools-wavespeed had to reach for the private _get_result to
recover a prediction by id after a local wait timed out. That is a real
use case — the task keeps running server-side — so expose it as
Client.get_result plus a module-level wavespeed.get_result.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

WaveSpeed no longer offers serverless as an external product. Shipping a
serverless worker implementation in the public Python SDK advertised a
capability customers cannot actually buy, which is misleading — so the
implementation is removed rather than left in place to rot.

Removed:
- src/wavespeed/serverless/ — the whole package: serverless.start(), the
  job scaler, handler-type dispatch, worker HTTP layer, FastAPI local dev
  server, local test mode, job/worker state, heartbeat, progress reporting,
  the boto3 S3 helpers, and utils.validate.
- tests/test_serverless/ — its test suite.
- images/ — the test_worker Docker image and build/push scripts, which
  existed solely to build and exercise the worker.
- wavespeed.config.serverless plus the import-time environment detection.
  RUNPOD_* and WAVERLESS_* variables are no longer read by this package.
- .dockerignore, which only ever scoped the worker image build.

The API client is deliberately untouched: run, run_no_throw, get_result,
upload, Client, wavespeed.config.api, and the channel-attribution headers
all behave exactly as they did in 1.0.x. config.py kept its `api` class and
the install_config_module() call, so wavespeed.config.patch() still works;
only the serverless namespace and its loaders were excised.

Dependencies drop to what the client actually uses: aiohttp,
aiohttp[speedups], aiohttp-retry and boto3 were serverless-only and are
gone. typing_extensions is now declared explicitly — _config_module has
always imported it, it was just never listed.

This removes public API, so the next release is 2.0.0. Worker users should
pin wavespeed<2 and plan to migrate.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

The package uses PEP 604 syntax at module level without a __future__ import,
so it never actually imported on 3.8 or 3.9 despite advertising support. CI
only tests 3.10. Declaring what we verify instead of what we wish.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

api/__init__.py had a module-level PEP 604 annotation (Client | None) with no
__future__ import, so the package could not import on 3.8 or 3.9 despite
declaring requires-python >=3.8. Adding the __future__ import fixes it.

config.py deliberately does NOT get that import: install_config_module walks
every module-level name, and the 'annotations' feature object it introduces
trips the unknown-config assertion. Its annotations already use Optional[str],
which is 3.8-legal as written.

New tests.yml runs the suite on 3.8-3.12 so the claim stays honest.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

All three project URLs pointed at GitHub, so the PyPI page for the most
downloaded package we publish offered no route to the product or the docs.

- Homepage: the GitHub repo -> https://wavespeed.ai
- Add Documentation -> https://wavespeed.ai/docs/
- Add Changelog -> CHANGELOG.md on main

Repository and Issues are unchanged. These five labels are the ones PyPI
renders with icons; it sorts them alphabetically, not by declaration order.

Packaging metadata only — no code changes. The links reach PyPI with the
next release, since the project page reflects the latest version.


Claude-Session: https://claude.ai/code/session_01LJJXU9zyoDSBjApcUpteDt

Co-authored-by: Claude Opus 5 <[email protected]>

* docs: link to the hosted playgrounds from the README

* docs: lead with the platform category, not the infrastructure