# API changes: August 16, 2026

[← Changelog](/docs/changelog) · [August 2026](/docs/changelog/2026-08)

### NEW-0816-1: the app icon accepts raster files, and a Bitrix24 account can push one itself

The icon upload [POST /v1/infra/servers/:id/icon](/docs/infra/app-icon) now accepts raster formats — PNG, JPG, GIF, WEBP, up to 5 MB and up to 4 megapixels (2000×2000, for example) — in addition to SVG. The format is detected from the file contents, not from its name or its `Content-Type` header. Whatever you upload, the serve URL still returns a 256×256 PNG: the platform scales the image into a square, keeping its proportions and padding the rest with transparency. Existing SVG uploads keep working unchanged: the SVG limits — 256 KB and the same 4096×4096 ceiling as before — are untouched.

New refusal codes: `ICON_UNSUPPORTED_FORMAT` for a format that is unrecognized or unsupported, `ICON_TOO_LARGE` for a file above the size limit, `ICON_TOO_MANY_PIXELS` for an image with more pixels than the platform will unpack, `ICON_RASTERIZE_FAILED` for a file that cannot be read.

In your Vibecode account the icon picker narrowed the other way: the server card and the application card take PNG, JPG, GIF and WEBP, and now refuse SVG — that format stays in the API alone.

The other half of the change is on the Bitrix24 side: an app owner can now replace the icon straight from the Bitrix24 catalog card, and Bitrix24 pushes it to the Vibecode platform together with the title and the description. That icon lands on the same catalog card as one uploaded through the API.

### NEW-0816-2: two fields describing a temporary limit increase in the Cowork/Code state

The [GET /v1/cowork/state](/docs/cowork/state) response now carries two fields describing a temporary limit increase: `boostPct` — the increase in percent (100 means limits are doubled), and `boostExpiresAt` — when it ends. With no increase active they read `0` and `null`.

The `pctUsed` shares of all three windows already account for the increase, so there is nothing to apply on the client side — the fields exist so you can show the size and the deadline to the user.

### NEW-0816-3: new 402 company_budget_exhausted rejection on calls that spend credits

**Before**

The only money-related rejection on `/v1/search/*` and on AI calls was insufficient funds on the account — `INSUFFICIENT_BALANCE`. An administrator had no way to cap the spend of an individual
employee or of the whole account.

**After**

An account administrator can set a monthly budget for metered spend — for the whole account and for
an individual employee. Once the budget is exhausted, web search and research calls, as well as AI calls — [POST /v1/chat/completions](/docs/ai/chat/completions), [POST /v1/embeddings](/docs/ai/embeddings) and [POST /v1/audio/transcriptions](/docs/ai/audio/transcriptions) — that spend credits receive a `402` with
the code `company_budget_exhausted`.

The rejection body carries two extra fields. `scope` tells whose budget is exhausted: `USER` is the
caller's own budget, `PORTAL` is the budget of the whole account. `canRequest` tells whether an
increase can be requested from the product: `true` for a personal budget, `false` for the account
budget, which only an administrator raises.

The rejection is returned only on calls that actually spend credits: a search made with the
customer's own key costs nothing and keeps working when the budget is exhausted, and so do AI calls made with the customer's own key, calls served inside the plan quota, and calls covered by a subscription. A call already in flight is completed: the limit applies from the next request.

Budgets are enabled separately and are off by default, so accounts without them see no change.

### FIX-0816-4: the Cowork deploy-key handout no longer loses servers

**Before**

[POST /v1/cowork/deploy-key](/docs/cowork/deploy-key) revoked the previous key but left everything that referenced it behind: server ownership, the application card and live access tokens. Versioned infrastructure reads are scoped to the calling key, so after every re-issue the earlier servers dropped out of `GET /v1/infra/servers`, answered `404` on a direct read and `403 WRONG_KEY` on deploy. The only way back was the dashboard.

**After**

The handout moves those links onto the fresh key, exactly as key rotation does. The server list and deploy work under the new key straight away, containers on a shared galaxy host included.

The read scope of started operations moves with them, so [GET /v1/infra/operations/{operationId}](/docs/infra/deploy/operation-status) keeps returning the outcome of a run begun under the previous key. A client whose transport dropped — and which therefore asked for a new key — used to get `404` on its own operation, indistinguishable from "no such operation".

**Impact on integrators**

Nothing to change: from this fix onward a re-issue no longer loses the links.

**Important:** the fix works forward and **does not recover what is already lost**. The move starts from the key that is active at handout time, while orphaned links sit on keys revoked earlier, so they are outside its reach. If your servers disappeared before this rollout, restore them by hand: in the Vibecode dashboard, open the server card and bind it to the key you use now.

The key lives for seven days and is not re-issued on a schedule. If it goes untouched for longer, the servers stay with the expired key and become visible again after the next handout, which moves the links off it.