• The actions/python-versions manifest lists version 3.15.0 with stable set to true, and lists 3.15.0-rc.3 and earlier release candidates and betas as not stable.
• Simon Willison's post says that adding "3.15" to a GitHub Actions testing matrix now runs tests against Python 3.15.0.
• His post quotes a prompt asking ChatGPT to clone the repository and git pull hourly until a stable 3.15 appeared, and it reports no result from that prompt.
• A scheduled job that reads the manifest's stable flag is deterministic and auditable. A chat assistant's polling is neither unless it is shown to notify reliably.
• A stable interpreter on the runner is a precondition for testing, not evidence that your dependencies work on 3.15.

The repository's own manifest, not a chat assistant, is the right thing to watch for a new Python release. The actions/python-versions manifest now lists Python 3.15.0 as stable, and Simon Willison's post, dated 10 October 2026 in its URL, says a "3.15" entry in a GitHub Actions matrix now tests against it. He also quotes a prompt asking ChatGPT to poll the repository hourly. His post reports no outcome for that prompt.

What the manifest shows

The versions-manifest.json file in actions/python-versions lists 3.15.0 first, with stable set to true. Below it sit 3.15.0-rc.3, rc.2, rc.1 and 3.15.0-beta.4, each marked not stable. That ordering matches the progression from beta to release candidate to final, and it is the signal a workflow resolves against. We read the manifest directly. We did not run a workflow, so the matrix behavior rests on Willison's description.

The ChatGPT prompt is untested

Willison's quoted instruction told ChatGPT to clone the repository and run git pull once an hour until a stable 3.15 was added, then report back. The post states no result. Nothing in the source shows whether a chat assistant can hold a schedule or would have raised the alert. The anecdote is not evidence that assistants work as release monitors, and it is not evidence that they fail.

Why the deterministic check wins

A job that fetches the manifest and tests for a stable 3.15.0 entry is simple to build and its result can be inspected. Its failure modes are visible: a fetch error, a changed file schema, a missed run. An assistant's polling hides its own failures, and its report is prose that needs separate verification. For a binary signal published in a machine-readable file, the plain check has the better audit trail.

What a stable interpreter does not settle

Stable status on the runner is a precondition for testing, not a result. Whether your packages install and pass on 3.15.0 depends on each dependency, especially compiled extensions that need builds for the new version. The practical step is to add "3.15" as an extra matrix entry beside your existing versions and attribute any failure to the specific package. We have not tested that configuration.

Verdict: add 3.15 to your matrix, and monitor the manifest with a scheduled check if you want a trigger. Do not rely on a chat assistant for that job until someone publishes a run showing it notifying reliably. The sources here support the release status. They do not support the polling idea.