[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-changelog\u002F2026-07-06":3,"docs-tabs-changelog\u002F2026-07-06":6},{"content":4,"lastmod":5},"# API changes: July 6, 2026\n\n[← Changelog](\u002Fdocs\u002Fchangelog) · [July 2026](\u002Fdocs\u002Fchangelog\u002F2026-07)\n\n### NEW-0706-1: pricing.perCall and pricing.perMinute fields in the model catalog\n\n[GET \u002Fv1\u002Fmodels](\u002Fdocs\u002Fai\u002Fmodels\u002Flist) and [GET \u002Fv1\u002Fmodels\u002F{model}](\u002Fdocs\u002Fai\u002Fmodels\u002Fget) responses gain optional fields in the `pricing` object: `perCall` — the cost of a single request in Vibe credits, `perMinute` — the cost of one minute of audio in Vibe credits (for speech-to-text models). The fields appear only for models whose corresponding base price is above zero; for all other models the `pricing` object is unchanged — existing requests keep working as before.\n\n### NEW-0706-2: New 402 error code ai_quota_exhausted on AI endpoints\n\nWhen the account monthly AI quota control is active, [POST \u002Fv1\u002Fchat\u002Fcompletions](\u002Fdocs\u002Fai\u002Fchat\u002Fcompletions), [POST \u002Fv1\u002Fembeddings](\u002Fdocs\u002Fai\u002Fembeddings) and [POST \u002Fv1\u002Faudio\u002Ftranscriptions](\u002Fdocs\u002Fai\u002Faudio\u002Ftranscriptions) may return 402 with `{ success: false, error: { code: \"ai_quota_exhausted\", type: \"insufficient_quota\", reason, resetAt? } }`. The `reason` field distinguishes three cases: `breaker` — the hourly over-quota spending limiter fired, `wallet_empty` — the quota is exhausted and the account balance has no funds, `wallet_off` — over-quota usage is not available for this account. `resetAt` is when requests will pass again (may be absent for a permanently disabled account). While the account quota is not exhausted, endpoint behavior is unchanged.\n\n### FIX-0706-3: Over-quota AI usage is charged at the model's base catalog price\n\n**Before**\n\nWith the account monthly AI quota control active, over-quota requests to [POST \u002Fv1\u002Fchat\u002Fcompletions](\u002Fdocs\u002Fai\u002Fchat\u002Fcompletions), [POST \u002Fv1\u002Fembeddings](\u002Fdocs\u002Fai\u002Fembeddings) and [POST \u002Fv1\u002Faudio\u002Ftranscriptions](\u002Fdocs\u002Fai\u002Faudio\u002Ftranscriptions) were charged to the account balance at internal quota-program rates — with off-peak discounts applied; the effective price was not visible in the model catalog.\n\n**After**\n\nOver-quota usage is charged at the model's base price from the public catalog — the same one returned in the `pricing` field of [GET \u002Fv1\u002Fmodels](\u002Fdocs\u002Fai\u002Fmodels\u002Flist), including the new `perCall` and `perMinute` for non-token models. Off-peak discounts apply only to quota consumption, not to the money balance. Usage within the quota is still not charged to the account balance.\n\n**Impact on integrators**\n\nNo changes required. The cost of over-quota usage can now be computed upfront from the model's catalog price.\n\n### NEW-0706-4: The bitrix\u002Fembeddings model is available in the API\n\nThe [POST \u002Fv1\u002Fembeddings](\u002Fdocs\u002Fai\u002Fembeddings) endpoint is now served by the `bitrix\u002Fembeddings` model — turning text into vector representations for semantic search, clustering, and retrieval (RAG). The model is free and billed on input tokens only. For the list of embedding-capable models see [GET \u002Fv1\u002Fmodels](\u002Fdocs\u002Fai\u002Fmodels\u002Flist).\n\n### FIX-0706-5: Deploy reports an honest error when the new build did not bind the port\n\nDeploy via [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fdeploy](\u002Fdocs\u002Finfra\u002Fdeploy) now verifies the port is held by the NEW service. If a previous process keeps listening and the new build crash-loops with EADDRINUSE, the deploy fails honestly instead of falsely succeeding; a port held by a leftover process of the same app is freed automatically where provable.\n\n**Before**\n\nThe old version kept answering `200`, the deploy reported success, and the new build never came up — with no error and no hint.\n\n**After**\n\nThe `healthcheck` step returns an error naming EADDRINUSE and the port, and the `stop_existing` step frees the port from a leftover process of the app (or warns and proceeds when it cannot).\n\n### NEW-0706-6: filter: $nin (NOT IN) operator to exclude a set of values\n\n**Before**\n\nThere was no way to select records whose field is NOT in a set of values: the `$in` (IN) operator existed, but its inverse did not. The Bitrix24-native field-name prefixes `@` (IN) and `!@` (NOT IN) (`{ \"!@categoryId\": [1, 3] }`) were not translated — such a deal filter returned `400 UNKNOWN_FILTER_FIELD`.\n\n**After**\n\nAdded the `$nin` operator: `{ \"filter\": { \"categoryId\": { \"$nin\": [1, 3] } } }` returns records of every value except those listed (NOT IN). Symmetric to `$in`. The Bitrix24-native `@` \u002F `!@` field-name prefixes are still unsupported, but now return a clear `400 INVALID_FILTER_FIELD` hinting to switch to `$in` \u002F `$nin`, instead of a confusing error or a silently-ignored (thus full-set) filter.\n\n### BC-0706-7: dedicated error code for an oversized exec command\n\n> Old format supported until: 06.01.2027\n\n**Before**\n\nA command longer than 10000 characters at [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fexec](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fexec) was rejected with the generic `VALIDATION_ERROR` code, with no cause and no way out.\n\n**After**\n\nSuch a request returns 400 with the dedicated `COMMAND_TOO_LONG` code and a structured `hint`: ship large payloads and scripts via [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fupload](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fupload), then run them with `bash \u002Fpath\u002Fscript.sh`. All other schema violations still return `VALIDATION_ERROR`.\n\n**What integrators should do**\n\nIf your client handles `VALIDATION_ERROR` of this endpoint as the catch-all validation case — add handling for the `COMMAND_TOO_LONG` code (or treat any 400 uniformly).\n\n### NEW-0706-8: hint in the exec timeout error\n\nThe `EXEC_TIMEOUT` error of [POST \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Fexec](\u002Fdocs\u002Finfra\u002Fdeploy\u002Fexec) now carries a structured `hint` field (`reason` \u002F `recovery` \u002F `recoveryAction`): why the process was stopped (at `timeout` the whole process group is terminated forcibly, with no grace period) and what to do — run long operations as a detached background job and monitor it via [GET \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Flogs](\u002Fdocs\u002Finfra\u002Fdeploy\u002Flogs), raise `timeout` up to 600 seconds, or use `?stream=true`. The field is additive: the previous `code` \u002F `message` shape is unchanged, and the hint arrives both in JSON mode and in the SSE `error` event.\n",null,{},1794739469708]