API changes: October 4, 2026

← Changelog · October 2026

FIX-1004-1: Cloud tasks distinguish elapsed run times from credential expiry

Before

Creating a cloud task or changing its one-time schedule after the specified run time returned 403 CREDENTIAL_EXPIRING, even when the API key had no expiry.

After

An elapsed run time returns 409 SCHEDULE_EXPIRED. If the run time is still in the future but the API key expires before task execution is covered, the response remains 403 CREDENTIAL_EXPIRING. The schedule is not moved automatically.

Impact on integrators

For SCHEDULE_EXPIRED, provide a future run time. No API-key update is needed when its validity covers task execution.

Affected endpoints: POST /v1/cowork/cloud-tasks, PATCH /v1/cowork/cloud-tasks/{id}.

BC-1004-2: Finishing active Cowork work after the five-hour limit

Old format supported until: not provided

Before

After the five-hour quota was exhausted, POST /v1/chat/completions used the existing limit response, including continuations of tool calls already issued.

After

When enabled for the user, the exact continuation of an issued tool call may finish using the existing weekly remainder, subject to the monthly limit. The allowance is granted once per five-hour window; a new user request cannot use it. The full known cost of the last response is accounted even when it exceeds the remaining allowance. Unknown usage closes further continuation; a window reset restores ordinary serving. The capability is off by default. Existing serving behavior continues until the capability is enabled specifically for a verified client. After activation, the previous finishing mode is not supported in parallel.

A forced named tool selection becomes automatic while finishing: a final text answer without another tool call is valid. Sync/SSE response shapes remain unchanged; SSE completion waits for source end and usage settlement. A temporarily unavailable continuation check returns 503 cowork_completion_unavailable before calling the model.

What integrators should do

Submit the result of an already-issued tool even after reaching 100%, preserve the original history and tools, accept final text as the end of the turn and read SSE through [DONE]. A new user turn must not reuse the allowance. These scenarios require verification in the real client before activation.

FIX-1004-3: switching to OPEN while the mode is disabled returns the platform refusal

Before

While OPEN mode was disabled platform-wide, PATCH /v1/infra/servers/{id}/mode with mode: "OPEN" returned 403 DIRECT_NETWORK_CHANGE_REQUIRES_HUMAN with a cabinet link in error.details.settingsUrl. The cabinet has no switch in that state either, so the link pointed to a place where OPEN cannot be enabled.

After

While OPEN mode is disabled platform-wide, the request returns 403 OPEN_MODE_DISABLED with ready-made text for a person in error.userMessage, as described on the method page. Nobody can switch a server to OPEN in that state, including through the cabinet. When the mode is enabled platform-wide, the response is unchanged: 403 DIRECT_NETWORK_CHANGE_REQUIRES_HUMAN, and a person performs the switch in the cabinet.

Impact on integrators

No action is required. Treat 403 OPEN_MODE_DISABLED as a final refusal: use the Deploy API to work with the server.