From 6f395ccd0810a12a97a59b2c9d0031aafc633173 Mon Sep 17 00:00:00 2001 From: Yucheng Date: Thu, 20 Aug 2026 12:57:17 -0700 Subject: [PATCH 1/2] docs(proxy): drop the status code from the PTU rejection note Some invalid PTU configurations answer 422 rather than 400, so naming a single code on the page is misleading. The behaviour that matters is that the rejection names the offending field. --- docs/proxy/ptu_flat_cost.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/proxy/ptu_flat_cost.md b/docs/proxy/ptu_flat_cost.md index 387387cb5..100cbb989 100644 --- a/docs/proxy/ptu_flat_cost.md +++ b/docs/proxy/ptu_flat_cost.md @@ -109,7 +109,7 @@ The Usage page in the Admin UI shows the same figures under Team Usage, charting ## Rates you must not set -LiteLLM refuses a per-token, per-second, or cache rate on a PTU deployment, and answers `400` naming the field. Sending `0`, an all-zero table, or no value at all is accepted: +LiteLLM refuses a per-token, per-second, or cache rate on a PTU deployment, and names the field it rejected. Sending `0`, an all-zero table, or no value at all is accepted: ``` A PTU deployment bills by reserved capacity, so input_cost_per_token cannot be charged on top From 6d76fd9abca3bd96368402d0860ad5ae60972736 Mon Sep 17 00:00:00 2001 From: Yucheng Date: Fri, 21 Aug 2026 11:56:36 -0700 Subject: [PATCH 2/2] docs(proxy): model_info.id is now required for a config.yaml reservation BerriAI/litellm#37794 refuses a config-declared PTU deployment that does not carry an id, so the page can no longer present pinning one as advice. Adds the upgrade note, since setting a fresh name rather than the id the deployment already uses strands the charges already written --- docs/proxy/ptu_flat_cost.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/proxy/ptu_flat_cost.md b/docs/proxy/ptu_flat_cost.md index 100cbb989..cd3a8fd03 100644 --- a/docs/proxy/ptu_flat_cost.md +++ b/docs/proxy/ptu_flat_cost.md @@ -61,12 +61,15 @@ model_list: ptu_effective_from: "2026-01-01T00:00:00Z" ``` -Pin `model_info.id` on a deployment declared this way. Left unset, the id is derived from the model name and the resolved `litellm_params`, so rotating the credential mints a new identity and the reservation is charged a second time under it. Any stable string works, and it only has to be unique across your deployments +`model_info.id` is required on a deployment declared this way, and the proxy refuses to load one without it, naming the deployment in the startup log. Left to itself the id is derived from the model name and the resolved `litellm_params`, so rotating the credential mints a new identity and the reservation is charged a second time under it, which nothing later retracts. Any stable string works, and it has to be unique across your deployments + +Upgrading an existing reservation that has already accrued cost, set `id` to the id it uses today rather than a fresh name, or the charges already written stay under the old identity and the new one starts beside them. The startup refusal quotes that current id so you can copy it `team_id` is what the capacity is billed to, so a declaration without one accrues nothing | Field | Required | Meaning | | --- | --- | --- | +| `id` | in `config.yaml` | The deployment's stable identity. Not needed through the API or the UI, where one is stored for you | | `team_id` | yes | The team the capacity belongs to. One deployment maps to one team | | `ptu_count` | yes | Provisioned throughput units reserved | | `cost_per_ptu_per_hour` | yes | Your contracted hourly rate per unit |