release: 0.70.0

[stainless-app]

Automated Release PR

0.70.0 (2026-06-22)

Full Changelog: v0.69.0...v0.70.0

Features

• Align browser-pool timeout/viewport/fill-rate contract with implementation; reject save_changes on update (5fdc97b)

---

This pull request is managed by Stainless's GitHub App.

The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.

For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.

🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions

---

Note

Low Risk
Mostly docstrings and version bumps from OpenAPI regen; behavior change is clearer API validation on the server (e.g. save_changes on update), not client logic changes.

Overview
Release 0.70.0 bumps package metadata (pyproject.toml, _version.py, release manifest) and points .stats.yml at a new OpenAPI spec hash.

The substantive SDK change is regenerated browser-pool and viewport docs/types from that spec. Browser pool timeout_seconds docs now state 10–259200 (default 600). fill_rate_per_minute docs clarify the usual 25% cap vs per-org overrides and that the SDK only documents the lower bound. Viewport field docs now say width, height, and refresh_rate accept any positive integer, with presets still listed as recommendations.

Browser pool API tests use timeout_seconds=10 instead of 60 so examples sit on the documented minimum. The changelog also notes the API will reject save_changes on pool update (contract alignment; not a separate Python type change in this diff).

^{Reviewed by Cursor Bugbot for commit 77d5b56. Bugbot is set up for automated code reviews on this repo. Configure here.}

[stainless-app]

🧪 Testing

To try out this version of the SDK:

pip install 'https://pkg.stainless.com/s/kernel-python/5fdc97b27bdd92cb6f91f1162c1a5827e4a6a172/kernel-0.69.0-py3-none-any.whl'

Expires at: Wed, 22 Jul 2026 17:42:18 GMT
Updated at: Mon, 22 Jun 2026 17:42:18 GMT

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 77d5b56. Configure here.}

[cursor]

Update still allows save_changes

Medium Severity

Release 0.70.0 documents that save_changes is rejected on browser pool update, but BrowserPoolUpdateParams still types profile as BrowserProfile with save_changes, and browser_pools.update forwards that field unchanged. Callers following the SDK can send a field the API rejects.

Additional Locations (2)

• src/kernel/resources/browser_pools.py#L258-L261
• tests/api_resources/test_browser_pools.py#L157-L161

 

^{Reviewed by Cursor Bugbot for commit 77d5b56. Configure here.}

[firetiger-agent]

Created a monitoring plan for this PR.

What this PR does: Updates the Python SDK to v0.70.0, clarifying documented constraints for browser-pool parameters (timeout_seconds, fill_rate_per_minute, and viewport dimensions) to match what the server already enforces.

Intended effect:

• Browser-pool create/update error rate: baseline 0 errors on /browser_pools and /browser_pools/{id_or_name} (confirmed over 24h pre-deploy); confirmed if it stays at 0 after adoption.
• Browser-pool acquire/release error rate: baseline ~0% (3,000–7,300 acquire spans/hr, effectively 0 errors); confirmed if no sustained elevation post-SDK adoption.

Risks:

• New 400s from stricter client code — if SDK consumers treat the newly documented timeout_seconds minimum (10) or maximum (259200) as newly enforced and change their call sites to wrong values, check /browser_pools and /browser_pools/{id_or_name} 5xx spans in traces; alert if errors > 0 for 2+ consecutive hours (baseline is 0).
• Misread fill_rate cap — if consumers interpret the fill_rate_per_minute cap of 25 as newly enforced and submit values >25 expecting them to be rejected, watch for new 400 spikes on pool create/update; alert if 4xx rate rises above pre-deploy 0%.

Status updates will be posted automatically on this PR as monitoring progresses.

View monitor