@leaflow/sdk 0.159.0 → 0.161.0

package/dist/canopy/v1/generated/validators/tokenPrice.zod.js

@@ -1,52 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Canopy API
- * Canopy model inference, API keys, model catalogue, service enablement and recorded usage.
- *
- * Project inference is served on this host in each provider's own protocol:
- *
- * - OpenAI: `/v1/chat/completions`, `/v1/responses` and `/v1/embeddings`; use
- *   `https://canopy.leaflow.cloud/v1` as the OpenAI SDK base URL.
- * - Anthropic: `/v1/messages`; use `https://canopy.leaflow.cloud` as the Anthropic SDK base URL.
- * - Gemini: `/v1beta/models/{model}:generateContent` and `:streamGenerateContent`.
- *
- * Canopy does not convert between protocols. A request is accepted only for a model whose
- * `supported_endpoints` lists the endpoint it was sent to, and it is forwarded unchanged except for
- * the model name and the credentials. Reasoning settings such as `reasoning_effort` are passed
- * through as written; a model's `capabilities` lists the values its upstream accepts.
- *
- * Management operations use `/api/v1`. The management model catalogue includes pricing;
- * `/v1/models` returns the OpenAI model format with Canopy capabilities and parameter limits.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `bearerAuth` security scheme.
- *
- * Management and project inference accept the same verified IAM scoped token. The token is the
- * sole billing project authority; `OpenAI-Project` and historical identity headers cannot
- * override it. These endpoints do not accept a Canopy API key. The separate API-key gateway
- * accepts Canopy API keys and serves the same endpoints.
- *
- * ## Conventions
- *
- * - **The plaintext of an API key is returned once.** The `secret` appears in the response that issues it and is returned by no other endpoint. A key that has been lost has to be revoked and reissued.
- * - **Disabling and revoking are distinct.** A disabled key may be enabled again at any time, while a revocation is irreversible and is intended for a key that has been exposed. Neither removes the record, and the usage the key accrued remains readable.
- * - **A usage query must carry a time range**, spanning no more than 31 days, or 400 days for the usage timeline. `from` and `to` carry a timezone offset, which the server does not infer.
- * - **The request and response bodies do not appear in the ledger.** They are not recorded. Quote the `upstream_request_id` from the response when reporting a problem.
- * - **Usage may be estimated.** The upstream provider does not report usage on every request. Where it does not, `usage_source` is `estimated` and the figures are derived from the character classes of the payload, to within roughly fifteen per cent.
- * - **The service is enabled before use.** A project enables the model platform once, through `create-service`; the forwarding endpoints refuse its requests until the service is `active`. Requests are then billed under the service's subscription by the tokens they use, at the rates stated in each model's `pricing`.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-import { Money } from "./money.zod.js";
-export const TokenPrice = zod.strictObject({
-    token_kind: zod.enum(["input", "output", "cache_read", "cache_write", "reasoning"]),
-    unit_amount: zod
-        .union([Money, zod.null()])
-        .describe("The charge for `unit_quantity` tokens of this kind. Null when the kind has no rate in the currency, in which case the model cannot be billed for it."),
-    unit_quantity: zod
-        .string()
-        .nullable()
-        .describe("How many tokens `unit_amount` is for, such as `1000000`. Null when `unit_amount` is null."),
-});

package/dist/compute/v1/generated/validators/allocateFloatingIPQuoteRequestBody.zod.d.ts

@@ -1,51 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export declare const allocateFloatingIPQuoteRequestBodyAddressMax = 64;
-export declare const allocateFloatingIPQuoteRequestBodyBandwidthMbpsMax = 1000;
-export declare const AllocateFloatingIPQuoteRequestBody: zod.ZodObject<{
-    address: zod.ZodOptional<zod.ZodString>;
-    bandwidth_mbps: zod.ZodInt;
-    private_network_id: zod.ZodUUID;
-    ipv4_pool_id: zod.ZodUUID;
-    billing: zod.ZodObject<{
-        usage_type: zod.ZodEnum<{
-            licensed: "licensed";
-            metered: "metered";
-        }>;
-        period: zod.ZodOptional<zod.ZodObject<{
-            unit: zod.ZodEnum<{
-                month: "month";
-                year: "year";
-            }>;
-            count: zod.ZodInt;
-        }, zod.z.core.$strict>>;
-        termination_policy: zod.ZodOptional<zod.ZodEnum<{
-            immediate: "immediate";
-            period_end: "period_end";
-        }>>;
-    }, zod.z.core.$strict>;
-}, zod.z.core.$strict>;
-export type AllocateFloatingIPQuoteRequestBody = zod.input<typeof AllocateFloatingIPQuoteRequestBody>;
-export type AllocateFloatingIPQuoteRequestBodyOutput = zod.output<typeof AllocateFloatingIPQuoteRequestBody>;

package/dist/compute/v1/generated/validators/allocateFloatingIPQuoteRequestBody.zod.js

@@ -1,44 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-import { BillingChoice } from "./billingChoice.zod.js";
-export const allocateFloatingIPQuoteRequestBodyAddressMax = 64;
-export const allocateFloatingIPQuoteRequestBodyBandwidthMbpsMax = 1000;
-export const AllocateFloatingIPQuoteRequestBody = zod
-    .strictObject({
-    address: zod
-        .string()
-        .max(allocateFloatingIPQuoteRequestBodyAddressMax)
-        .optional()
-        .describe("The address to allocate. Allocated by the platform when omitted"),
-    bandwidth_mbps: zod
-        .int()
-        .min(1)
-        .max(allocateFloatingIPQuoteRequestBodyBandwidthMbpsMax)
-        .describe("The bandwidth ceiling of this address, in Mbit/s, applied to both directions.\n\nRequired, and there is no \"unlimited\": an address with no ceiling runs at line rate and is\ncharged nothing for the traffic, while the address itself bills normally — so the invoice\nlooks correct and nothing anywhere reports it.\n\nIt is part of this floating IP purchase and is billed as the pool's `bandwidth_pricing` shows,\nwith the purchase's billing choice. Changing it later updates the\nsame floating IP through its bandwidth endpoint, not an independent bandwidth resource."),
-    private_network_id: zod.uuid(),
-    ipv4_pool_id: zod.uuid(),
-    billing: BillingChoice,
-})
-    .describe("The request of `allocate-floating-ip`, without `checkout`.");

package/dist/compute/v1/generated/validators/createBackupCapacityPackQuoteRequestBody.zod.d.ts

@@ -1,46 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export declare const CreateBackupCapacityPackQuoteRequestBody: zod.ZodObject<{
-    capacity_gib: zod.ZodInt;
-    billing: zod.ZodObject<{
-        usage_type: zod.ZodEnum<{
-            licensed: "licensed";
-            metered: "metered";
-        }>;
-        period: zod.ZodOptional<zod.ZodObject<{
-            unit: zod.ZodEnum<{
-                month: "month";
-                year: "year";
-            }>;
-            count: zod.ZodInt;
-        }, zod.z.core.$strict>>;
-        termination_policy: zod.ZodOptional<zod.ZodEnum<{
-            immediate: "immediate";
-            period_end: "period_end";
-        }>>;
-    }, zod.z.core.$strict>;
-}, zod.z.core.$strict>;
-export type CreateBackupCapacityPackQuoteRequestBody = zod.input<typeof CreateBackupCapacityPackQuoteRequestBody>;
-export type CreateBackupCapacityPackQuoteRequestBodyOutput = zod.output<typeof CreateBackupCapacityPackQuoteRequestBody>;

package/dist/compute/v1/generated/validators/createImageQuoteRequestBody.zod.d.ts

@@ -1,46 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export declare const CreateImageQuoteRequestBody: zod.ZodObject<{
-    instance_id: zod.ZodUUID;
-    billing: zod.ZodObject<{
-        usage_type: zod.ZodEnum<{
-            licensed: "licensed";
-            metered: "metered";
-        }>;
-        period: zod.ZodOptional<zod.ZodObject<{
-            unit: zod.ZodEnum<{
-                month: "month";
-                year: "year";
-            }>;
-            count: zod.ZodInt;
-        }, zod.z.core.$strict>>;
-        termination_policy: zod.ZodOptional<zod.ZodEnum<{
-            immediate: "immediate";
-            period_end: "period_end";
-        }>>;
-    }, zod.z.core.$strict>;
-}, zod.z.core.$strict>;
-export type CreateImageQuoteRequestBody = zod.input<typeof CreateImageQuoteRequestBody>;
-export type CreateImageQuoteRequestBodyOutput = zod.output<typeof CreateImageQuoteRequestBody>;

package/dist/compute/v1/generated/validators/funds.zod.js

@@ -1,35 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-import { Money } from "./money.zod.js";
-export const Funds = zod
-    .strictObject({
-    available_balance_amount: Money.describe("Spendable balance after pending returns."),
-    usable_credit_amount: Money.describe("Currently effective credits eligible for the quoted purchases or metered usage. Each grant is counted once."),
-    restricted_credit_amount: Money.describe("Currently effective credits that cannot fund any quoted purchase or metered target. Unused eligible credits are not restricted."),
-    required_balance_amount: Money.describe("Minimum spendable balance needed after eligible credits, covering immediate charges and every new metered purchase's admission requirement."),
-    balance_shortfall_amount: Money.describe("Additional balance needed now. Zero means account funds satisfy this quote. No funds are reserved."),
-    required_top_up_amount: Money.describe("Minimum recharge that covers the shortfall, respecting the currency minimum recharge and currency precision. Zero when no additional balance is needed."),
-})
-    .describe("Account funding for this purchase, calculated by Billing. Amounts use the enclosing response currency.\nCredit eligibility and all purchase requirements are already evaluated. Nothing is charged or reserved.\nA licensed purchase may instead be paid with an online payment method.\n");

package/dist/compute/v1/generated/validators/launchInstanceQuoteRequestBody.zod.d.ts

@@ -1,113 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export declare const launchInstanceQuoteRequestBodyCountDefault = 1;
-export declare const launchInstanceQuoteRequestBodyCountMax = 20;
-export declare const launchInstanceQuoteRequestBodyNameMax = 128;
-export declare const launchInstanceQuoteRequestBodyPasswordMax = 128;
-export declare const LaunchInstanceQuoteRequestBody: zod.ZodObject<{
-    floating_ip_id: zod.ZodOptional<zod.ZodUUID>;
-    count: zod.ZodDefault<zod.ZodInt>;
-    generate_password: zod.ZodOptional<zod.ZodBoolean>;
-    compute: zod.ZodObject<{
-        instance_type_id: zod.ZodUUID;
-        billing: zod.ZodObject<{
-            usage_type: zod.ZodEnum<{
-                licensed: "licensed";
-                metered: "metered";
-            }>;
-            period: zod.ZodOptional<zod.ZodObject<{
-                unit: zod.ZodEnum<{
-                    month: "month";
-                    year: "year";
-                }>;
-                count: zod.ZodInt;
-            }, zod.z.core.$strict>>;
-            termination_policy: zod.ZodOptional<zod.ZodEnum<{
-                immediate: "immediate";
-                period_end: "period_end";
-            }>>;
-        }, zod.z.core.$strict>;
-    }, zod.z.core.$strict>;
-    name: zod.ZodString;
-    password: zod.ZodOptional<zod.ZodString>;
-    port_id: zod.ZodOptional<zod.ZodUUID>;
-    security_group_ids: zod.ZodOptional<zod.ZodNullable<zod.ZodArray<zod.ZodUUID>>>;
-    subnet_id: zod.ZodOptional<zod.ZodUUID>;
-    boot_disk: zod.ZodDiscriminatedUnion<[zod.ZodObject<{
-        type: zod.ZodEnum<{
-            image: "image";
-        }>;
-        image_id: zod.ZodUUID;
-        disk_type_id: zod.ZodUUID;
-        size_gb: zod.ZodInt;
-        delete_with_instance: zod.ZodDefault<zod.ZodBoolean>;
-        billing: zod.ZodObject<{
-            usage_type: zod.ZodEnum<{
-                licensed: "licensed";
-                metered: "metered";
-            }>;
-            period: zod.ZodOptional<zod.ZodObject<{
-                unit: zod.ZodEnum<{
-                    month: "month";
-                    year: "year";
-                }>;
-                count: zod.ZodInt;
-            }, zod.z.core.$strict>>;
-            termination_policy: zod.ZodOptional<zod.ZodEnum<{
-                immediate: "immediate";
-                period_end: "period_end";
-            }>>;
-        }, zod.z.core.$strict>;
-    }, zod.z.core.$strict>, zod.ZodObject<{
-        type: zod.ZodEnum<{
-            disk: "disk";
-        }>;
-        disk_id: zod.ZodUUID;
-        login_username: zod.ZodString;
-    }, zod.z.core.$strict>], "type">;
-    floating_ip: zod.ZodOptional<zod.ZodObject<{
-        bandwidth_mbps: zod.ZodInt;
-        ipv4_pool_id: zod.ZodUUID;
-        billing: zod.ZodObject<{
-            usage_type: zod.ZodEnum<{
-                licensed: "licensed";
-                metered: "metered";
-            }>;
-            period: zod.ZodOptional<zod.ZodObject<{
-                unit: zod.ZodEnum<{
-                    month: "month";
-                    year: "year";
-                }>;
-                count: zod.ZodInt;
-            }, zod.z.core.$strict>>;
-            termination_policy: zod.ZodOptional<zod.ZodEnum<{
-                immediate: "immediate";
-                period_end: "period_end";
-            }>>;
-        }, zod.z.core.$strict>;
-    }, zod.z.core.$strict>>;
-}, zod.z.core.$strict>;
-export type LaunchInstanceQuoteRequestBody = zod.input<typeof LaunchInstanceQuoteRequestBody>;
-export type LaunchInstanceQuoteRequestBodyOutput = zod.output<typeof LaunchInstanceQuoteRequestBody>;

package/dist/compute/v1/generated/validators/launchInstanceQuoteRequestBody.zod.js

@@ -1,71 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-import { BootDisk } from "./bootDisk.zod.js";
-import { NewCompute } from "./newCompute.zod.js";
-import { NewFloatingIP } from "./newFloatingIP.zod.js";
-export const launchInstanceQuoteRequestBodyCountDefault = 1;
-export const launchInstanceQuoteRequestBodyCountMax = 20;
-export const launchInstanceQuoteRequestBodyNameMax = 128;
-export const launchInstanceQuoteRequestBodyPasswordMax = 128;
-export const LaunchInstanceQuoteRequestBody = zod
-    .strictObject({
-    floating_ip_id: zod
-        .uuid()
-        .optional()
-        .describe("Bind a floating IP you already hold, instead of allocating a new one. It must be idle and in\nthe same region.\n\nMutually exclusive with `bandwidth_mbps`: an address you already hold has its own bandwidth\nceiling, set when it was allocated, and changing it is a separate operation.\n\nLike `bandwidth_mbps`, this happens **inside the creation**: if binding fails, no instance is\ncreated. Binding afterwards is still possible from the instance page, but then it is two\noperations and a failure in between leaves an instance you cannot reach.\n\nOnly one instance can be created when it is used — one address binds to one interface."),
-    count: zod
-        .int()
-        .min(1)
-        .max(launchInstanceQuoteRequestBodyCountMax)
-        .default(launchInstanceQuoteRequestBodyCountDefault)
-        .describe("Number of instances to create; 1 when omitted. Names are numbered automatically for several"),
-    generate_password: zod
-        .boolean()
-        .optional()
-        .describe("Have the platform generate a random password, returned only in this response"),
-    compute: NewCompute,
-    name: zod.string().min(1).max(launchInstanceQuoteRequestBodyNameMax),
-    password: zod
-        .string()
-        .max(launchInstanceQuoteRequestBodyPasswordMax)
-        .optional()
-        .describe("The password to set, on the login account and on root. Only the SSH public keys of the project are used when omitted"),
-    port_id: zod
-        .uuid()
-        .optional()
-        .describe("Use an existing network interface, which may already have a floating IP bound. Exactly one of this and `subnet_id`; only one instance can be created when it is used"),
-    security_group_ids: zod
-        .array(zod.uuid())
-        .min(1)
-        .nullish()
-        .describe("Required when a primary network interface is created, at least one; the default security group is not applied automatically. Ignored together with `port_id`, as the security groups of that interface were fixed when it was created"),
-    subnet_id: zod
-        .uuid()
-        .optional()
-        .describe("Create the primary network interface in this subnet. Exactly one of this and `port_id`"),
-    boot_disk: BootDisk,
-    floating_ip: NewFloatingIP.optional(),
-})
-    .describe("The request of `launch-instance`, without `checkout`.");

package/dist/compute/v1/generated/validators/pricing.zod.d.ts

@@ -1,54 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export declare const Pricing: zod.ZodObject<{
-    currency: zod.ZodString;
-    options: zod.ZodArray<zod.ZodObject<{
-        usage_type: zod.ZodEnum<{
-            licensed: "licensed";
-            metered: "metered";
-        }>;
-        period: zod.ZodUnion<readonly [zod.ZodObject<{
-            unit: zod.ZodEnum<{
-                month: "month";
-                year: "year";
-            }>;
-            count: zod.ZodInt;
-        }, zod.z.core.$strict>, zod.ZodNull]>;
-        quantity_unit: zod.ZodEnum<{
-            item: "item";
-            gib: "gib";
-            mbps: "mbps";
-            snapshot: "snapshot";
-        }>;
-        amount: zod.ZodNullable<zod.ZodString>;
-        monthly_amount: zod.ZodNullable<zod.ZodString>;
-        saving_percent: zod.ZodNullable<zod.ZodString>;
-        unit_amount: zod.ZodNullable<zod.ZodString>;
-        unit: zod.ZodNullable<zod.ZodUnion<readonly [zod.ZodLiteral<"hour">, zod.ZodLiteral<null>]>>;
-        termination_policy: zod.ZodNullable<zod.ZodUnion<readonly [zod.ZodLiteral<"immediate">, zod.ZodLiteral<"period_end">, zod.ZodLiteral<null>]>>;
-    }, zod.z.core.$strict>>;
-}, zod.z.core.$strict>;
-export type Pricing = zod.input<typeof Pricing>;
-export type PricingOutput = zod.output<typeof Pricing>;

package/dist/compute/v1/generated/validators/pricingOption.zod.d.ts

@@ -1,51 +0,0 @@
-/**
- * Generated by orval 🍺
- * Do not edit manually.
- * Leaflow Compute API
- * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
- *
- * ## Authentication
- *
- * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
- *
- * ## Conventions
- *
- * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
- * - **Pricing.** Catalog items, such as instance types, disk types and public IP pools, carry `pricing`: the licensed and metered options Billing offers for them, in the currency of the project's current billing account, or null when the project has no billing account. They are list amounts before promotion codes, not a checkout guarantee. A purchase chooses one option with `billing`, which applies to all of its components. Every purchase and change has a quote operation beside it, at the same path followed by `/quote`, which returns what checkout would collect without ordering anything.
- * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
- * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
- * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
- * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
- * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
- * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
- * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
- * OpenAPI spec version: 1.0.0
- */
-import * as zod from "zod";
-export declare const PricingOption: zod.ZodObject<{
-    usage_type: zod.ZodEnum<{
-        licensed: "licensed";
-        metered: "metered";
-    }>;
-    period: zod.ZodUnion<readonly [zod.ZodObject<{
-        unit: zod.ZodEnum<{
-            month: "month";
-            year: "year";
-        }>;
-        count: zod.ZodInt;
-    }, zod.z.core.$strict>, zod.ZodNull]>;
-    quantity_unit: zod.ZodEnum<{
-        item: "item";
-        gib: "gib";
-        mbps: "mbps";
-        snapshot: "snapshot";
-    }>;
-    amount: zod.ZodNullable<zod.ZodString>;
-    monthly_amount: zod.ZodNullable<zod.ZodString>;
-    saving_percent: zod.ZodNullable<zod.ZodString>;
-    unit_amount: zod.ZodNullable<zod.ZodString>;
-    unit: zod.ZodNullable<zod.ZodUnion<readonly [zod.ZodLiteral<"hour">, zod.ZodLiteral<null>]>>;
-    termination_policy: zod.ZodNullable<zod.ZodUnion<readonly [zod.ZodLiteral<"immediate">, zod.ZodLiteral<"period_end">, zod.ZodLiteral<null>]>>;
-}, zod.z.core.$strict>;
-export type PricingOption = zod.input<typeof PricingOption>;
-export type PricingOptionOutput = zod.output<typeof PricingOption>;