Dimensions
Register a rate
Full request and response schema: Publish compute prices for compute, and Publish disk prices for storage. Creating, changing or deleting a rate needs an API key with thepricing:write scope, or an admin signed in. Reading rates needs pricing:read or pricing:write, or a member signed in. Only admins can create keys with pricing:write.
id for each entry. That UUID is what you tag with.
Assign a price to a virtual machine
Choose a price in the agent install step, or open the virtual machine’s page and set its Price field. The machine is costed at that price from the next hour. Unassigning it returns the machine to automatic pricing. Assigning a price needs an admin, or an API key with thepricing:write scope.
Listing prices needs a member, or an API key with the pricing:read scope.
Through the API, list your compute prices, then set or remove the tag:
{"remove":["costgraph.ai/pricing-id.compute"]} to unassign. Only your
organization’s own prices and public catalog prices can be assigned; any other
id is rejected.
Each disk takes its own storage price, whether it is attached to a virtual
machine or backs a Kubernetes volume. On the machine’s page, expand the disk and
pick a price; on a volume’s page, pick it in the volume details. Through the
API, list your disk prices, then assign one to a disk, or send null to return
it to automatic pricing:
costgraph.ai/pricing-id.storage in the cluster keeps the
label’s price: change or remove the label to change it. A volume no workload
mounts yet cannot be priced this way until one does.
Tag the resource
On Kubernetes, use labels:Key spellings
Some platforms reject the canonical key, and a label set on a cloud instance can reach the node in a rewritten form. CostGraph matches keys case-insensitively after replacing/, . and - with _, so every spelling below resolves to
the same pin.
Set whichever your tooling accepts.
Inheritance
Every object is priced in its own right. An object with no pin of its own takes the rate from the nearest scope above it, so tagging one node can price the volumes on it without tagging each one. The nearest pin wins, and each kind of object looks outward along its own path: A volume and its claim are separate objects and can carry different rates. A volume with no consumer has no node above it, so with no pin of its own it falls straight to attribute matching.A node is not in any namespace, so tagging a namespace never changes a node’s
own rate. It reaches the claims in that namespace.
What a pin changes
A pin decides the rate CostGraph uses to cost that resource, replacing attribute matching for that dimension. Nothing else about the resource changes: CPU and memory still come from the node’s capacity and size from the volume, because those are the billed quantities. A pin is how a resource gets a cost at all when CostGraph has nothing to match on, such as a bare-metal node with no cloud provider behind it.Change a rate
PATCH the rate by its ID with the newcost_per_hour. The ID is unchanged and
every tagged resource picks up the new rate from the next hour. Already-billed
hours keep the rate they were billed at.
- Send only
cost_per_hourand it is split into per-vCPU and per-GB rates, after taking off the GPU cost. - Send only
cpu_cores_cost_per_hourandram_gb_cost_per_hour(andgpu_cost_per_hour) and the hourly price is their total for the machine’s size. - Send both and they must add up, or the request fails with
422naming both numbers.
cost_per_hour, which keeps the
same ID. If you copied the entry from a GET, remove cpu_cores_cost_per_hour and
ram_gb_cost_per_hour first: they still hold the old rates, no longer match the
new price, and the request fails with 422.
Delete a rate
A compute or disk rate that is assigned to a resource cannot be deleted. The request fails with409 and code price_in_use, and the response lists the resources that use it
under affected. Unassign the price from each of them, then delete it again.