bbs.profullstack/logicsrc
1
0
Fork 0
mirror of https://github.com/profullstack/logicsrc.git synced 2026-10-01 20:33:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

docs: OpenCPU, OpenMemory, OpenGPU and OpenBandwidth, the resources of a server purchase (#163)

Browse source 
Four resource specifications under OpenServer, one per thing that is
negotiable when a server is bought. Each is the block of an OpenServer
offer (compute, memory, gpu, network) written down on its own, with the
units OpenServer 0.1 already uses (vcpu, cores, ram_mb, vram_mb,
bandwidth_mbps, transfer_gb, ipv4, ipv6) and one new shape shared by all
four: `range`, the field a buyer can dial at checkout, its bounds, the
step and what a step costs on top of the base price.

- OpenCPU: threads against cores, the processor by its vendor name,
  dedicated, shared or burstable allocation.
- OpenMemory: mebibytes, DDR generation, ECC as three states, reserved,
  balloonable or shared; wins over compute.ram_mb when both are present.
- OpenGPU: the card by its vendor name, count and VRAM per device,
  interconnect, passthrough, MIG, vGPU or shared access.
- OpenBandwidth: port, four meters (transfer, unmetered, percentile,
  flat), overage, IPv4 and IPv6 addresses as a priced resource.

A provider that sells only one resource lists it as an OpenServer offer
and may serve the same document at /.well-known/<slug>.json. Landing
pages share one component (resource-spec-page.tsx). Registered in
DOC_SLUGS, NAV, STATIC_ROUTES and llms.txt. OpenServer, OpenFile and
OpenDisk arrive in sibling PRs.


Claude-Session: https://claude.ai/code/session_014cmNRtR2vL1p89dbVQ7FZJ

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Anthony Ettinger 2026-09-12 18:59:05 -07:00 • committed by GitHub
parent 41c362ddd8
commit be2d67b8c3
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
13 changed files with 881 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

124
docs/openbandwidth.md Normal file
View file

@ -0,0 +1,124 @@
# OpenBandwidth
OpenBandwidth is the shape of one resource in a server purchase: the network. It says how fast the port is, how much traffic is included and how it is metered, what overage costs, how many addresses come with the box and what more of them cost, and whether traffic is scrubbed. It is the `network` block of an [OpenServer](/docs/openserver) offer, written down on its own so a VPS host with a transfer cap, a colocation facility billing at the 95th percentile, an IPv4 lessor and a directory that filters on any of them all mean the same thing by the same key. It is maintained by Profullstack, Inc. as part of the LogicSRC open-standards surface.
Status: **0.1**. One of five resource specifications under OpenServer: [OpenCPU](/docs/opencpu), [OpenMemory](/docs/openmemory), [OpenDisk](/docs/opendisk), [OpenGPU](/docs/opengpu) and OpenBandwidth. Each describes one thing that is negotiable when a server is bought.
Slug: `openbandwidth`
## The problem
"Unmetered 1 Gbps" and "1 Gbps, 20 TB" and "1 Gbps at 95th percentile, 100 Mbps committed" are three different products that every comparison site shows as 1 Gbps. The surprise on the invoice is always in the network line: overage at 0.01 a gigabyte on one host and 0.09 on another, ingress free here and billed there, a second IPv4 address at 2 a month or unavailable at any price. IPv4 addresses are now a market of their own, leased by the /24, and no catalog format has a place for them. A buyer's agent asked for "10 TB a month, egress under 0.02 a gigabyte over, with a /29" cannot answer from the number 1000.
This document fixes the words for the port, the meter, the overage and the addresses.
## Terms
- The **network block** is the `network` object on an OpenServer offer, or the same object served on its own.
- The **port** is the link speed the buyer is connected at. The **meter** is how traffic on it is counted for billing. **Overage** is the price of traffic past what is included.
- **Addresses** are the IPv4 and IPv6 assignments included, and the price of more.
- A **range** is what the buyer may change at checkout, with the price of changing it.
## The network block
```json
{
"network": {
"bandwidth_mbps": 1000,
"metering": "transfer",
"transfer_gb": 20000,
"counts": "egress",
"overage": { "amount": 0.01, "currency": "USD", "per_gb": 1 },
"ipv4": 1,
"ipv4_price": { "amount": 2, "currency": "USD", "interval": "month", "per": 1 },
"ipv4_max": 8,
"ipv6": "/64",
"ddos": "always-on",
"private_network": true,
"uplinks": 2,
"range": {
"key": "bandwidth_mbps",
"min": 1000,
"max": 10000,
"step": 1000,
"price": { "amount": 15, "currency": "USD", "interval": "month", "per": 1000 }
}
}
}
```
The smallest valid block states the port:
```json
{ "network": { "bandwidth_mbps": 1000 } }
```
The rules, and every one degrades:
1. **`bandwidth_mbps` is required.** It is the port speed in megabits per second, the same unit OpenServer uses. A shaped link states the shaped rate, not the physical port.
2. **`metering`** is one of `transfer`, `unmetered`, `percentile`, `flat`. `transfer` counts gigabytes per interval against `transfer_gb`. `unmetered` has no cap and `transfer_gb` is absent. `percentile` bills on the 95th percentile of utilisation, and `commit_mbps` is the committed rate included in the price. `flat` is a fixed price for the port, whatever passes. Absent with `transfer_gb` present means `transfer`; absent otherwise means unstated.
3. **`transfer_gb`** is included traffic per the offer's price interval, in gigabytes. **`counts`** says which direction is counted: `egress`, `ingress`, `both`, or `max` for the larger of the two. Absent means unstated, and a directory does not assume egress.
4. **`overage`** is the price of traffic past `transfer_gb`, as an `amount` in `currency` per `per_gb` gigabytes. Absent with a cap means the provider throttles or stops rather than bills, and `over_cap` may say which: `bill`, `throttle`, `suspend`.
5. **`ipv4`** is how many IPv4 addresses are included, an integer, as OpenServer states it. **`ipv4_price`** is the price of each additional address at the offer's interval, and **`ipv4_max`** the most the provider will assign. `0` included with a price means addresses are sold separately. **`ipv6`** is a boolean, as OpenServer states it, or the prefix length assigned as a string (`/64`, `/56`), which a reader treats as true.
6. **`ddos`** is `always-on`, `on-demand`, `none`, or absent for unstated. It states that mitigation exists, not what it withstands; the provider's terms say that. **`private_network`** is whether the offer has a private LAN to other servers of the same buyer. **`uplinks`** is the count of physical links on a dedicated box.
7. **`range`** is the negotiable part. `key` is `bandwidth_mbps`, `transfer_gb` or `ipv4`, `min`, `max` and `step` bound it, and `price` is the cost per `per` units at the offer's interval, on top of the base price. A block may carry more than one range as a list under `ranges` when two fields are negotiable; `range` alone is the common case.
8. **Unknown keys are kept.** A provider may say more; a reader passes it through under the provider's key.
## Network as its own offer
Bandwidth and addresses are sold without a server more often than any other resource: IP transit at the 95th percentile, a CDN's egress by the gigabyte, a leased IPv4 block, a cross-connect in a colocation facility. Each is an OpenServer offer with a `network` block and a `price`:
```json
{
"id": "transit-1g",
"name": "IP transit 1 Gbps",
"kind": "colocation",
"network": { "bandwidth_mbps": 1000, "metering": "percentile", "commit_mbps": 100, "overage": { "amount": 0.35, "currency": "USD", "per_mbps": 1 } },
"price": { "amount": 35, "currency": "USD", "interval": "month" }
}
```
```json
{
"id": "ipv4-24",
"name": "IPv4 /24 lease",
"kind": "colocation",
"network": { "bandwidth_mbps": 0, "ipv4": 256, "ipv4_prefix": "/24" },
"price": { "amount": 130, "currency": "USD", "interval": "month", "commitment": "12 months" }
}
```
A percentile overage is priced per megabit, so `overage` carries `per_mbps` in place of `per_gb`. An address lease states `bandwidth_mbps: 0`, because the rule wants a port and there is none, and `ipv4_prefix` says the block size. A provider whose file is only network offers may serve it at `/.well-known/openbandwidth.json`; the shape is OpenServer's and the name says what is in it. A reader that only wants network filters offers on the presence of a `network` block.
## What a directory does with it
1. **Shows the meter beside the port.** 1 Gbps unmetered and 1 Gbps with 20 TB are two rows with two words, not one number.
2. **Prices a month of traffic.** For a `transfer` offer a directory can show what a stated volume would cost, base plus overage, and says which volume it assumed.
3. **Lists addresses as a resource.** Included count, price of more, ceiling. A row with `ipv4: 0` and no price is marked unstated, not free.
4. **Never assumes direction.** A cap with no `counts` is shown as a cap, with the direction unstated.
## What is deliberately absent
**No speed test.** `bandwidth_mbps` is the port the provider sells. Achieved throughput to any destination is a measurement and another document's business.
**No carrier list or peering.** Which transit providers and exchanges sit behind the port is the provider's network page, linked from the offer's `url`. A provider that wants to state ASN or upstreams does so under its own key.
**No latency or geography beyond OpenServer's `location`.** Where the box is comes from the offer. Round-trip times to anywhere are a measurement.
**No SLA.** Uptime percentages and credits are the provider's terms.
## Related standards
- [OpenServer](/docs/openserver): the descriptor and the offer this block sits in.
- [OpenCPU](/docs/opencpu), [OpenMemory](/docs/openmemory), [OpenDisk](/docs/opendisk), [OpenGPU](/docs/opengpu): the other four resources of a purchase, each with the same `range` shape.
- [OpenStream](/docs/openstream): the relay envelope a byte stream crosses a network in; unrelated to how the network is sold.
## Version history
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-09-13 | First publication: the network block, four meters, overage, addresses as a priced resource, the range. |
## License
The specification text is CC BY 4.0. Serve it, copy it, extend it.

111
docs/opencpu.md Normal file
View file

@ -0,0 +1,111 @@
# OpenCPU
OpenCPU is the shape of one resource in a server purchase: the processor. It says how many cores or threads an offer has, what they are, whether they are yours alone or shared, and how many more a buyer may add at checkout and for how much. It is the `compute` block of an [OpenServer](/docs/openserver) offer, written down on its own so a provider that sells only compute, a configurator that sells it by the core and a directory that filters on it all mean the same thing by the same key. It is maintained by Profullstack, Inc. as part of the LogicSRC open-standards surface.
Status: **0.1**. One of five resource specifications under OpenServer: OpenCPU, [OpenMemory](/docs/openmemory), [OpenDisk](/docs/opendisk), [OpenGPU](/docs/opengpu) and [OpenBandwidth](/docs/openbandwidth). Each describes one thing that is negotiable when a server is bought.
Slug: `opencpu`
## The problem
"4 vCPU" on one pricing page is four hyperthreads of a shared socket that will be throttled at 20% sustained load. On the next page it is four dedicated cores with the boost clock quoted. A comparison site collapses both into a column called CPU and sorts on the number, and the buyer who wanted the second pays for the first. A dedicated-server configurator lets a buyer choose between three processors and the price changes, but that choice lives in a form and nowhere a reader can see it. A buyer's agent asked for "8 dedicated cores, x86, under 40 a month" cannot answer from the number 8.
The processor is one line of a spec sheet, but it is the line with the most ways to say the same thing, so this document fixes the words.
## Terms
- The **compute block** is the `compute` object on an OpenServer offer, or the same object served on its own.
- A **thread** is what a hypervisor hands a guest; a **core** is what the silicon has. Providers sell either, and this document keeps them apart.
- An **allocation** is whether the threads sold are reserved for the buyer, shared with neighbours, or shared with a credit balance that allows bursts.
- A **range** is what the buyer may change at checkout, with the price of changing it.
## The compute block
```json
{
"compute": {
"vcpu": 4,
"cores": 2,
"threads_per_core": 2,
"arch": "x86_64",
"model": "AMD EPYC 9354",
"vendor": "AMD",
"base_ghz": 3.25,
"boost_ghz": 3.75,
"sockets": 1,
"allocation": "dedicated",
"range": {
"key": "vcpu",
"min": 2,
"max": 32,
"step": 2,
"price": { "amount": 4, "currency": "USD", "interval": "month", "per": 1 }
}
}
}
```
The smallest valid block states one count:
```json
{ "compute": { "vcpu": 4 } }
```
The rules, and every one degrades:
1. **One of `vcpu` or `cores` is required.** `vcpu` is threads sold to the guest; `cores` is physical cores. A virtual offer states `vcpu`, a dedicated box states `cores`, and one may state both, with `threads_per_core` (1 or 2) saying how they relate. A reader never derives one from the other unless `threads_per_core` is stated.
2. **`arch`** is `x86_64`, `arm64`, `riscv64` or the provider's own word. Absent means unstated, not x86.
3. **`model`** is the processor as the vendor names it, unchanged, so a buyer can look it up. `vendor` is the maker (`AMD`, `Intel`, `Ampere`, `Apple`, `AWS` for Graviton). `base_ghz` and `boost_ghz` are the vendor's clock figures in gigahertz, not a measurement. `sockets` is how many packages a dedicated box has.
4. **`allocation`** is one of `dedicated`, `shared`, `burstable`. `dedicated` means the threads are reserved for this buyer. `shared` means they are oversubscribed with neighbours and sustained use may be limited. `burstable` means shared with a credit balance: `credits_per_hour` says how many CPU credits accrue and `baseline_pct` the sustained share the buyer is entitled to without spending them. Absent means unstated, and a directory that sorts by core count says so beside the number.
5. **`range`** is the negotiable part. `key` names the field the buyer changes (`vcpu` or `cores`), `min`, `max` and `step` bound it, and `price` is the cost per `per` units at the offer's interval, on top of the offer's base price. An offer with no `range` is sold as stated. A configurator with a choice of processors lists one offer per processor rather than a range over `model`, because a model is a name, not a number.
6. **`ram_mb` may sit here for compatibility** with OpenServer 0.1, and a reader accepts it. The memory block in [OpenMemory](/docs/openmemory) is where memory belongs; when both are present the memory block wins.
7. **Unknown keys are kept.** A provider may say more; a reader passes it through under the provider's key.
Units are fixed: counts are integers, clocks are gigahertz as decimals, percentages are integers 0 to 100.
## Compute as its own offer
A provider that sells compute without a server, a batch platform billing by the vCPU-hour, a peer on a marketplace renting its idle cores, a configurator selling core upgrades, lists it as an OpenServer offer whose `compute` block carries the goods and whose `price` says what a unit costs:
```json
{
"id": "batch-vcpu-hour",
"name": "Batch vCPU",
"kind": "serverless",
"compute": { "vcpu": 1, "arch": "x86_64", "allocation": "dedicated" },
"price": { "amount": 0.021, "currency": "USD", "interval": "hour" }
}
```
A provider that sells only compute may serve its OpenServer descriptor at `/.well-known/opencpu.json` as well as, or instead of, `/.well-known/openserver.json`. The document is the same shape; the name says what a reader will find in it. A reader that only wants compute filters offers on the presence of a `compute` block.
## What a directory does with it
1. **Sorts on what was stated.** `vcpu` and `cores` are two columns, not one. A row with neither is listed and marked unstated.
2. **Shows allocation beside the count.** Four dedicated threads and four shared ones are different products at the same number, and the directory shows the word.
3. **Prices the range.** An offer with a `range` is shown at its base price with the per-unit price alongside, so a buyer can see that 8 vCPU costs the base plus four steps.
4. **Keeps the model string.** Normalise for search; display the vendor's name.
## What is deliberately absent
**No benchmarks.** Clock figures are the vendor's; a measured score is another document's business, and a directory that publishes one labels it as its own.
**No instruction-set flags.** AVX-512, SVE, virtualisation extensions: a buyer who needs one looks up `model`. A provider that wants to state them does so under its own key.
**No scheduling guarantees.** `allocation` says reserved, shared or burstable. Latency, NUMA placement and pinning are the provider's terms, linked from the offer's `url`.
## Related standards
- [OpenServer](/docs/openserver): the descriptor and the offer this block sits in.
- [OpenMemory](/docs/openmemory), [OpenDisk](/docs/opendisk), [OpenGPU](/docs/opengpu), [OpenBandwidth](/docs/openbandwidth): the other four resources of a purchase, each with the same `range` shape.
- [OpenSwarm](/openswarm) and c0mpute: a peer renting its cores lists them with this block and settles under OpenSwarm.
## Version history
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-09-13 | First publication: the compute block, threads against cores, three allocations, the range. |
## License
The specification text is CC BY 4.0. Serve it, copy it, extend it.

113
docs/opengpu.md Normal file
View file

@ -0,0 +1,113 @@
# OpenGPU
OpenGPU is the shape of one resource in a server purchase: the accelerator. It says which GPU an offer has, how many, how much memory each carries, how they are joined, whether the buyer gets the whole card or a slice of it, and how many more a buyer may add at checkout and for how much. It is the `gpu` block of an [OpenServer](/docs/openserver) offer, written down on its own so a cloud selling H100 hours, a peer renting a gaming card and a directory that filters on VRAM all mean the same thing by the same key. It is maintained by Profullstack, Inc. as part of the LogicSRC open-standards surface.
Status: **0.1**. One of five resource specifications under OpenServer: [OpenCPU](/docs/opencpu), [OpenMemory](/docs/openmemory), [OpenDisk](/docs/opendisk), OpenGPU and [OpenBandwidth](/docs/openbandwidth). Each describes one thing that is negotiable when a server is bought.
Slug: `opengpu`
## The problem
GPU pricing is the most volatile and least comparable line in hosting. The same card is sold whole, as a MIG slice, as a time-shared vGPU and as a peer's idle desktop, at prices an order of magnitude apart, and a listing that says "1x A100" has said almost nothing: 40 GB or 80 GB, PCIe or SXM, NVLinked to its neighbours or not. The peer-to-peer markets move by the minute and publish their own schemas. A buyer's agent asked for "two 80 GB cards with NVLink, under 4 an hour, in stock" reads six catalogs six ways.
This document fixes the words, and it fixes them so a marketplace listing and a hyperscaler SKU can sit in one column.
## Terms
- The **gpu block** is the `gpu` object on an OpenServer offer, inside `compute` as OpenServer 0.1 places it, or beside it.
- **Access** is how the buyer reaches the silicon: the whole device, a hardware partition, a virtualised share, or a time-shared queue.
- An **interconnect** is how the cards in one offer talk to each other.
- A **range** is what the buyer may change at checkout, with the price of changing it.
## The gpu block
```json
{
"gpu": {
"model": "NVIDIA H100 SXM",
"vendor": "NVIDIA",
"count": 8,
"vram_mb": 81920,
"arch": "Hopper",
"interconnect": "nvlink",
"access": "passthrough",
"fraction": 1,
"driver": "550",
"runtime": "CUDA 12.4",
"range": {
"key": "count",
"min": 1,
"max": 8,
"step": 1,
"price": { "amount": 2.49, "currency": "USD", "interval": "hour", "per": 1 }
}
}
}
```
The smallest valid block states the model:
```json
{ "gpu": { "model": "NVIDIA RTX 4090" } }
```
The rules, and every one degrades:
1. **`model` is required.** It is the card as the vendor names it, unchanged, including the form factor when the vendor distinguishes one (`NVIDIA H100 SXM`, `NVIDIA H100 PCIe`, `AMD Instinct MI300X`). `vendor` is the maker. `arch` is the vendor's architecture name.
2. **`count`** is how many devices the offer includes; absent means 1. **`vram_mb`** is the memory of one device in mebibytes, the same unit OpenServer uses. 80 GB is 81920. A reader multiplies by `count` for the total and never assumes the provider did.
3. **`interconnect`** is how the devices in the offer are joined: `nvlink`, `nvswitch`, `infinity-fabric`, `pcie`, or `none` when they are independent cards. It describes the offer, so a single card states nothing here.
4. **`access`** is one of `passthrough`, `mig`, `vgpu`, `shared`. `passthrough` is the whole device. `mig` is a hardware partition and `fraction` or `profile` says which: `profile` is the vendor's name (`1g.10gb`), `fraction` the share as a decimal (`0.125`). `vgpu` is a virtualised share with `fraction`. `shared` is time-sliced with neighbours and no fixed share. Absent means unstated, and a directory that sorts by VRAM says so beside the number.
5. **`driver`** and **`runtime`** are what the provider installs by default, as version strings; absent means the buyer installs their own. A bare-metal offer usually states nothing here.
6. **`range`** is the negotiable part. `key` is `count`, `min`, `max` and `step` bound it, and `price` is the cost per `per` devices at the offer's interval, on top of the base price. A provider that offers several cards lists one offer per `model`, because a model is a name, not a number.
7. **Position.** OpenServer 0.1 places `gpu` inside `compute`. A provider may also place it at the top level of the offer; a reader looks in both places and a block at the top level wins.
8. **Unknown keys are kept.** A provider may say more; a reader passes it through under the provider's key.
## GPU as its own offer
GPU is already an OpenServer `kind`, because the accelerator is what is sold and the host beside it is incidental. An offer of `kind: gpu` states the block and a price, and the `compute` and `memory` around it describe the host:
```json
{
"id": "h100-1",
"name": "H100 80GB x1",
"kind": "gpu",
"compute": { "vcpu": 26, "arch": "x86_64" },
"memory": { "ram_mb": 229376 },
"gpu": { "model": "NVIDIA H100 SXM", "count": 1, "vram_mb": 81920, "access": "passthrough" },
"price": { "amount": 2.49, "currency": "USD", "interval": "hour" },
"stock": "in_stock"
}
```
A peer-to-peer market lists each ask the same way with `model: p2p` on the offer, and the market's `updated` on the offer says how fresh the price is. A provider whose file is only accelerator offers may serve it at `/.well-known/opengpu.json`; the shape is OpenServer's and the name says what is in it. A reader that only wants accelerators filters on the presence of a `gpu` block or `kind: gpu`.
## What a directory does with it
1. **Keeps the model string and normalises beside it.** `NVIDIA H100 SXM` and `H100-SXM5-80GB` are the same card; the directory matches them for search and shows the provider's spelling.
2. **Shows access beside VRAM.** A MIG slice of an H100 and a whole H100 share a model and differ in everything else.
3. **Computes the per-device price** from `price` and `count`, so a row for 8 cards and a row for 1 sort together, and says it did.
4. **Reads stock with its timestamp.** GPU stock is the field that goes stale first, and a directory shows when each row was read.
## What is deliberately absent
**No benchmarks or TFLOPS.** Vendor throughput figures depend on precision, sparsity and clock, and no two vendors quote them alike. A provider that wants to state them does so under its own key; a directory that measures publishes its own numbers under its own name.
**No reservation calendar.** Whether a card is free next Tuesday is the provider's scheduler. `stock` says now.
**No spot or preemptible flag.** OpenServer's `price.commitment` and the offer's `url` carry the terms; a provider selling the same card at a spot price lists a second offer.
## Related standards
- [OpenServer](/docs/openserver): the descriptor, the `gpu` kind and the offer this block sits in.
- [OpenCPU](/docs/opencpu), [OpenMemory](/docs/openmemory), [OpenDisk](/docs/opendisk), [OpenBandwidth](/docs/openbandwidth): the other four resources of a purchase, each with the same `range` shape.
- [OpenSwarm](/openswarm) and c0mpute: a peer renting its card lists it with this block and settles under OpenSwarm.
## Version history
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-09-13 | First publication: the gpu block, four access modes, interconnects, the range, position inside or beside `compute`. |
## License
The specification text is CC BY 4.0. Serve it, copy it, extend it.

106
docs/openmemory.md Normal file
View file

@ -0,0 +1,106 @@
# OpenMemory
OpenMemory is the shape of one resource in a server purchase: the memory. It says how much RAM an offer has, what kind, whether it is error-corrected, whether it is reserved for the buyer or balloonable, and how much more a buyer may add at checkout and for how much. It is the `memory` block of an [OpenServer](/docs/openserver) offer, written down on its own so a configurator that sells RAM by the gigabyte, a provider that sells memory-optimised instances and a directory that filters on it all mean the same thing by the same key. It is maintained by Profullstack, Inc. as part of the LogicSRC open-standards surface.
Status: **0.1**. One of five resource specifications under OpenServer: [OpenCPU](/docs/opencpu), OpenMemory, [OpenDisk](/docs/opendisk), [OpenGPU](/docs/opengpu) and [OpenBandwidth](/docs/openbandwidth). Each describes one thing that is negotiable when a server is bought.
Slug: `openmemory`
## The problem
Memory is the resource most often bought in increments and least often described. A dedicated-server configurator offers 64, 128 or 256 GB at three prices, and the difference between them is the whole reason to pick the box, but a scraper sees the default and a directory lists one number. "8 GB" on a VPS may be 8 GiB reserved, or 8 GB of which the host reclaims half under pressure. Whether the DIMMs are error-corrected decides whether a database belongs on the machine, and almost no listing says.
The memory line of a spec sheet is short. This document makes it say what it means.
## Terms
- The **memory block** is the `memory` object on an OpenServer offer, or the same object served on its own.
- **Reserved** memory is backed by physical memory the host will not reclaim. **Balloonable** memory may be reclaimed by the host under pressure. **Shared** memory is oversubscribed with neighbours.
- A **range** is what the buyer may change at checkout, with the price of changing it.
## The memory block
```json
{
"memory": {
"ram_mb": 65536,
"type": "DDR5",
"ecc": true,
"speed_mts": 4800,
"channels": 8,
"allocation": "reserved",
"swap_mb": 0,
"hugepages": true,
"range": {
"key": "ram_mb",
"min": 32768,
"max": 1048576,
"step": 32768,
"price": { "amount": 12, "currency": "USD", "interval": "month", "per": 32768 }
}
}
}
```
The smallest valid block states the size:
```json
{ "memory": { "ram_mb": 8192 } }
```
The rules, and every one degrades:
1. **`ram_mb` is required.** It is the memory the guest sees, in mebibytes, the same unit OpenServer uses in `compute.ram_mb`. 8 GiB is 8192. A provider that sells in decimal gigabytes converts once when it writes the file, so every reader adds the same numbers.
2. **`type`** is the memory technology as the vendor names it: `DDR4`, `DDR5`, `LPDDR5`, `HBM3`, or the provider's own word. `speed_mts` is the rated transfer rate in megatransfers per second. `channels` is the populated channel count on a dedicated box. All three are stated, not measured.
3. **`ecc`** is a boolean. Absent means unstated, and a directory that lets a buyer filter on ECC shows unstated rows as unstated, never as false.
4. **`allocation`** is one of `reserved`, `balloonable`, `shared`. Absent means unstated. A dedicated server is `reserved` by nature and may say so.
5. **`swap_mb`** is swap the provider configures by default, in mebibytes; `0` means none and absent means unstated. **`hugepages`** is whether the buyer may use huge pages, a boolean.
6. **`range`** is the negotiable part. `key` is `ram_mb`, `min`, `max` and `step` bound it in mebibytes, and `price` is the cost per `per` mebibytes at the offer's interval, on top of the base price. The example above says memory is sold in 32 GiB steps at 12 USD a month each. An offer with no `range` is sold as stated.
7. **This block wins over `compute.ram_mb`.** OpenServer 0.1 puts `ram_mb` inside `compute`. A provider may keep it there for readers that predate this document; when a `memory` block is present, its `ram_mb` is the one a reader uses.
8. **Unknown keys are kept.** A provider may say more; a reader passes it through under the provider's key.
## Memory as its own offer
Memory is rarely sold alone, but it is sold as an increment, and the increment is an offer: a RAM upgrade on a configurator, a memory-optimised tier that differs from the base tier only here, a reservation of memory on a platform that bills it separately from compute. Each is an OpenServer offer with a `memory` block and a `price`:
```json
{
"id": "ram-32",
"name": "32 GB RAM upgrade",
"kind": "dedicated",
"memory": { "ram_mb": 32768, "type": "DDR5", "ecc": true },
"price": { "amount": 12, "currency": "USD", "interval": "month" }
}
```
A provider whose file is only memory offers may serve it at `/.well-known/openmemory.json`; the shape is OpenServer's and the name says what is in it. A reader that only wants memory filters offers on the presence of a `memory` block.
## What a directory does with it
1. **Shows mebibytes as the provider's unit.** Store `ram_mb`; display 8 GiB or 8 GB as the provider's page does, and say which.
2. **Filters on ECC as three states**, yes, no and unstated.
3. **Prices the range.** A configurator's 64, 128 and 256 GB choices are one offer with a range, and a directory shows the base and the step price rather than three rows.
4. **Reads `memory` before `compute.ram_mb`** and never sums the two.
## What is deliberately absent
**No bandwidth or latency figures.** `speed_mts` is the DIMM rating. Measured memory bandwidth is a benchmark, and benchmarks are another document's business.
**No persistent memory tier.** Optane-style persistent memory and CXL-attached memory are storage or memory depending on the provider; a provider states them under its own key until there is a second one to agree with.
**No per-process limits.** cgroup memory limits on a container platform are the platform's terms, linked from the offer's `url`.
## Related standards
- [OpenServer](/docs/openserver): the descriptor and the offer this block sits in.
- [OpenCPU](/docs/opencpu), [OpenDisk](/docs/opendisk), [OpenGPU](/docs/opengpu), [OpenBandwidth](/docs/openbandwidth): the other four resources of a purchase, each with the same `range` shape.
## Version history
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-09-13 | First publication: the memory block, ECC as three states, three allocations, the range, precedence over `compute.ram_mb`. |
## License
The specification text is CC BY 4.0. Serve it, copy it, extend it.