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

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

View file

@ -24,6 +24,10 @@ export function GET(): Response {
- [OpenMCP](${SITE_URL}/openmcp): An open catalog of MCP relays: a relay serves /.well-known/openmcp.json, a catalog probes it and lists only what it found, and clients reach every relay through the catalog's REST, its own MCP endpoint, or signed webhooks. - [OpenMCP](${SITE_URL}/openmcp): An open catalog of MCP relays: a relay serves /.well-known/openmcp.json, a catalog probes it and lists only what it found, and clients reach every relay through the catalog's REST, its own MCP endpoint, or signed webhooks.
- [OpenAccess](${SITE_URL}/openaccess): OAuth 2.1 with a grant you can carry: one hub account per person or agent, apps keep their own users and link them once, grants delegate narrower to agents, and a subscription bought in one app is honoured by every app that honours the product. Reference hub at openaccess.logicsrc.com. - [OpenAccess](${SITE_URL}/openaccess): OAuth 2.1 with a grant you can carry: one hub account per person or agent, apps keep their own users and link them once, grants delegate narrower to agents, and a subscription bought in one app is honoured by every app that honours the product. Reference hub at openaccess.logicsrc.com.
- [OpenServer](${SITE_URL}/openserver): One file a hosting provider serves about what it sells, at /.well-known/openserver.json: every offer with kind (cloud, vps, dedicated, bare-metal, colocation, on-prem, shared, managed, paas, serverless, storage, gpu, edge, p2p, hybrid), the premises, management, tenancy and model axes, specs, one price, location and stock. Directories read the provider instead of scraping; first reader is nichedb.dev/c/hosting. - [OpenServer](${SITE_URL}/openserver): One file a hosting provider serves about what it sells, at /.well-known/openserver.json: every offer with kind (cloud, vps, dedicated, bare-metal, colocation, on-prem, shared, managed, paas, serverless, storage, gpu, edge, p2p, hybrid), the premises, management, tenancy and model axes, specs, one price, location and stock. Directories read the provider instead of scraping; first reader is nichedb.dev/c/hosting.
- [OpenCPU](${SITE_URL}/opencpu): The compute block of an OpenServer offer: threads against cores, the processor by its vendor name, dedicated, shared or burstable allocation, and a range that says what a buyer can add at checkout and for how much.
- [OpenMemory](${SITE_URL}/openmemory): The memory block of an OpenServer offer: RAM in mebibytes, DDR generation, ECC as three states, reserved or balloonable allocation, and a range priced per step.
- [OpenGPU](${SITE_URL}/opengpu): The gpu block of an OpenServer offer: the card by its vendor name, count and VRAM per device, interconnect, passthrough, MIG, vGPU or shared access, and a range over count.
- [OpenBandwidth](${SITE_URL}/openbandwidth): The network block of an OpenServer offer: port speed, transfer, unmetered, 95th percentile or flat metering, overage, IPv4 and IPv6 addresses as a priced resource, DDoS scrubbing, and a range.
- [AgentSwarm](${SITE_URL}/agent-swarm): Provider-neutral agent orchestration, model routing, and cost controls. - [AgentSwarm](${SITE_URL}/agent-swarm): Provider-neutral agent orchestration, model routing, and cost controls.
- [AgentByte](${SITE_URL}/agentbyte): Agent screening sessions, policy events, and APIs. - [AgentByte](${SITE_URL}/agentbyte): Agent screening sessions, policy events, and APIs.
- [Credential Sharing](${SITE_URL}/credential-sharing): End-to-end-encrypted team vaults, plus source/target credential diffs, approval, sync, rollback, and audit. - [Credential Sharing](${SITE_URL}/credential-sharing): End-to-end-encrypted team vaults, plus source/target credential diffs, approval, sync, rollback, and audit.

View file

@ -0,0 +1,63 @@
import type { ReactNode } from "react";
import type { Metadata } from "next";
import { ResourceSpecPage, type ResourceSpec } from "@/components/resource-spec-page";
export const metadata: Metadata = {
title: "OpenBandwidth · LogicSRC",
description:
"OpenBandwidth is the network block of an OpenServer offer: port speed, how traffic is metered (transfer, unmetered, 95th percentile, flat), what overage costs, IPv4 and IPv6 addresses as a priced resource, DDoS scrubbing, and a range that says what a buyer can add at checkout and for how much.",
alternates: { canonical: "/openbandwidth" }
};
const SPEC: ResourceSpec = {
name: "OpenBandwidth",
slug: "openbandwidth",
block: "network",
tagline:
"The network line of a server purchase, with the words fixed: the port, the meter, the overage, the addresses, and what more of any of them costs.",
problem:
"Unmetered 1 Gbps, 1 Gbps with 20 TB, and 1 Gbps at the 95th percentile with 100 Mbps committed are three products that every comparison site shows as 1 Gbps. The surprise on the invoice is always the network line: overage at a cent a gigabyte here and nine there, ingress free or billed, a second IPv4 address at two a month or unavailable at any price. IPv4 is now a market of its own, leased by the /24, and no catalog format has a place for it.",
sample: `{
"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",
"range": {
"key": "bandwidth_mbps", "min": 1000, "max": 10000, "step": 1000,
"price": { "amount": 15, "currency": "USD", "interval": "month", "per": 1000 }
}
}
}`,
smallest: `{ "network": { "bandwidth_mbps": 1000 } }`,
fields: [
["bandwidth_mbps", "integer, required", "The port speed sold. A shaped link states the shaped rate."],
["metering", "transfer, unmetered, percentile, flat", "Gigabytes against transfer_gb, no cap, 95th percentile with commit_mbps, or a fixed price for the port."],
["transfer_gb, counts", "integer per interval; egress, ingress, both, max", "Included traffic and which direction counts. A reader never assumes egress."],
["overage, over_cap", "amount, currency, per_gb or per_mbps; bill, throttle, suspend", "What traffic past the cap costs, or what happens instead."],
["ipv4, ipv4_price, ipv4_max, ipv6", "integer; price per address; integer; boolean or prefix", "Addresses as a resource: included, the price of more, the ceiling, and the IPv6 assignment."],
["ddos, private_network, uplinks", "always-on, on-demand, none; boolean; integer", "That mitigation exists, a private LAN, physical links on a dedicated box."],
["range", "key bandwidth_mbps, transfer_gb or ipv4; min, max, step, price", "What the buyer can dial and what a step costs."]
],
directory: [
["Meter beside the port", "1 Gbps unmetered and 1 Gbps with 20 TB are two rows with two words."],
["Price a month of traffic", "Base plus overage at a stated volume, with the volume shown."],
["Addresses as a resource", "Included count, price of more, ceiling. Zero with no price is unstated, not free."],
["Never assume direction", "A cap with no counts is a cap with the direction unstated."]
],
absent: [
["No speed test", "bandwidth_mbps is the port sold. Achieved throughput is a measurement."],
["No carriers or peering", "Upstreams and exchanges are the provider's network page. An ASN goes under the provider's own key."],
["No SLA", "Uptime percentages and credits are the provider's terms, linked from the offer's url."]
]
};
export default function OpenBandwidthPage(): ReactNode {
return <ResourceSpecPage spec={SPEC} />;
}

View file

@ -0,0 +1,61 @@
import type { ReactNode } from "react";
import type { Metadata } from "next";
import { ResourceSpecPage, type ResourceSpec } from "@/components/resource-spec-page";
export const metadata: Metadata = {
title: "OpenCPU · LogicSRC",
description:
"OpenCPU is the compute block of an OpenServer offer: threads against cores, the processor by its vendor name, dedicated, shared or burstable allocation, and a range that says how many more a buyer can add at checkout and for how much.",
alternates: { canonical: "/opencpu" }
};
const SPEC: ResourceSpec = {
name: "OpenCPU",
slug: "opencpu",
block: "compute",
tagline:
"The processor line of a server purchase, with the words fixed: threads or cores, whose they are, and what one more costs.",
problem:
"Four vCPU on one pricing page is four hyperthreads of a shared socket, throttled at a fifth of sustained load. On the next it is four dedicated cores with the boost clock quoted. A comparison site sorts both on the number four, and the buyer who wanted the second pays for the first. A configurator that offers three processors at three prices keeps that choice in a form where no reader can see it.",
sample: `{
"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,
"allocation": "dedicated",
"range": {
"key": "vcpu", "min": 2, "max": 32, "step": 2,
"price": { "amount": 4, "currency": "USD", "interval": "month", "per": 1 }
}
}
}`,
smallest: `{ "compute": { "vcpu": 4 } }`,
fields: [
["vcpu / cores", "integer, one required", "Threads sold to the guest, or physical cores. threads_per_core relates them; a reader never derives one from the other without it."],
["arch", "x86_64, arm64, riscv64, or the provider's word", "Absent means unstated, not x86."],
["model, vendor", "the vendor's own name", "AMD EPYC 9354, Ampere Altra Max. Kept verbatim so a buyer can look it up."],
["base_ghz, boost_ghz, sockets", "decimal GHz, integer", "The vendor's figures, not a measurement."],
["allocation", "dedicated, shared, burstable", "Reserved for the buyer, oversubscribed, or shared with a credit balance (credits_per_hour, baseline_pct)."],
["range", "key, min, max, step, price", "What the buyer can dial at checkout and what each step costs on top of the base price."]
],
directory: [
["Two columns", "vcpu and cores are sorted separately; a row with neither is listed and marked unstated."],
["Allocation beside the count", "Four dedicated threads and four shared ones are different products at the same number."],
["Price the range", "Base price plus the per-step price, so 8 vCPU reads as base plus four steps."],
["Keep the model string", "Normalise for search, display the vendor's spelling."]
],
absent: [
["No benchmarks", "Clock figures are the vendor's. A measured score is another document's business."],
["No instruction-set flags", "AVX-512, SVE and the rest: look up model. A provider that wants them states them under its own key."],
["No scheduling guarantees", "Pinning, NUMA and latency are the provider's terms, linked from the offer's url."]
]
};
export default function OpenCpuPage(): ReactNode {
return <ResourceSpecPage spec={SPEC} />;
}

View file

@ -0,0 +1,61 @@
import type { ReactNode } from "react";
import type { Metadata } from "next";
import { ResourceSpecPage, type ResourceSpec } from "@/components/resource-spec-page";
export const metadata: Metadata = {
title: "OpenGPU · LogicSRC",
description:
"OpenGPU is the gpu block of an OpenServer offer: the card by its vendor name, count and VRAM per device, the interconnect between them, passthrough, MIG, vGPU or shared access, and a range that says how many more a buyer can add at checkout and for how much.",
alternates: { canonical: "/opengpu" }
};
const SPEC: ResourceSpec = {
name: "OpenGPU",
slug: "opengpu",
block: "gpu",
tagline:
"The accelerator line of a server purchase, with the words fixed: which card, how many, how much memory, how they are joined, whole or a slice, and what one more costs.",
problem:
"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 one A100 has said almost nothing: 40 or 80 GB, PCIe or SXM, NVLinked or not. The 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 reads six catalogs six ways.",
sample: `{
"gpu": {
"model": "NVIDIA H100 SXM",
"vendor": "NVIDIA",
"count": 8,
"vram_mb": 81920,
"arch": "Hopper",
"interconnect": "nvlink",
"access": "passthrough",
"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 }
}
}
}`,
smallest: `{ "gpu": { "model": "NVIDIA RTX 4090" } }`,
fields: [
["model, vendor, arch", "the vendor's own name, required", "Including the form factor when the vendor distinguishes one: H100 SXM and H100 PCIe are two models."],
["count, vram_mb", "integer; mebibytes per device", "80 GB is 81920. A reader multiplies for the total and never assumes the provider did."],
["interconnect", "nvlink, nvswitch, infinity-fabric, pcie, none", "How the devices in one offer are joined. A single card states nothing."],
["access", "passthrough, mig, vgpu, shared", "The whole device, a hardware partition (profile or fraction), a virtualised share, or time-sliced with neighbours."],
["driver, runtime", "version strings", "What the provider installs by default; absent means the buyer installs their own."],
["range", "key count, min, max, step, price", "One offer per model; the range is over how many."]
],
directory: [
["Keep the model, match beside it", "NVIDIA H100 SXM and H100-SXM5-80GB are one card for search and two spellings on the page."],
["Access beside VRAM", "A MIG slice and a whole card share a model and differ in everything else."],
["Per-device price", "Computed from price and count so a row of eight and a row of one sort together, and labelled as computed."],
["Stock with its timestamp", "GPU stock goes stale first; every row says when it was read."]
],
absent: [
["No TFLOPS", "Vendor throughput depends on precision, sparsity and clock, and no two vendors quote it alike."],
["No reservation calendar", "Whether a card is free next Tuesday is the provider's scheduler. stock says now."],
["No spot flag", "A card at a spot price is a second offer; price.commitment and the url carry the terms."]
]
};
export default function OpenGpuPage(): ReactNode {
return <ResourceSpecPage spec={SPEC} />;
}

View file

@ -0,0 +1,59 @@
import type { ReactNode } from "react";
import type { Metadata } from "next";
import { ResourceSpecPage, type ResourceSpec } from "@/components/resource-spec-page";
export const metadata: Metadata = {
title: "OpenMemory · LogicSRC",
description:
"OpenMemory is the memory block of an OpenServer offer: RAM in mebibytes, DDR generation and speed, ECC as three states, reserved or balloonable allocation, and a range that says how much more a buyer can add at checkout and for how much.",
alternates: { canonical: "/openmemory" }
};
const SPEC: ResourceSpec = {
name: "OpenMemory",
slug: "openmemory",
block: "memory",
tagline:
"The memory line of a server purchase, with the words fixed: how much, what kind, whether it is corrected, whether it is yours, and what a step more costs.",
problem:
"Memory is the resource most often bought in increments and least often described. A configurator offers 64, 128 or 256 GB at three prices and a scraper records the default. Eight gigabytes on a VPS may be reserved or may be reclaimed by the host under pressure. Whether the DIMMs are error-corrected decides whether a database belongs on the machine, and almost no listing says.",
sample: `{
"memory": {
"ram_mb": 65536,
"type": "DDR5",
"ecc": true,
"speed_mts": 4800,
"channels": 8,
"allocation": "reserved",
"hugepages": true,
"range": {
"key": "ram_mb", "min": 32768, "max": 1048576, "step": 32768,
"price": { "amount": 12, "currency": "USD", "interval": "month", "per": 32768 }
}
}
}`,
smallest: `{ "memory": { "ram_mb": 8192 } }`,
fields: [
["ram_mb", "integer mebibytes, required", "What the guest sees. 8 GiB is 8192, the same unit OpenServer uses. Wins over compute.ram_mb when both are present."],
["type, speed_mts, channels", "DDR4, DDR5, LPDDR5, HBM3; MT/s; integer", "The vendor's rating, stated not measured."],
["ecc", "true, false, absent", "Three states. A directory never shows absent as false."],
["allocation", "reserved, balloonable, shared", "Backed and never reclaimed, reclaimable under host pressure, or oversubscribed."],
["swap_mb, hugepages", "integer, boolean", "Swap the provider configures by default; whether huge pages are allowed."],
["range", "key, min, max, step, price", "Memory sold in steps: the example is 32 GiB steps at 12 USD a month each."]
],
directory: [
["Mebibytes as the provider's unit", "Store ram_mb; display GiB or GB as the provider's page does, and say which."],
["ECC as three states", "Yes, no and unstated are three filters."],
["Price the range", "A configurator's three sizes are one offer with a range, shown as base plus step."],
["memory before compute.ram_mb", "Read the block first and never sum the two."]
],
absent: [
["No bandwidth or latency", "speed_mts is the DIMM rating. Measured memory bandwidth is a benchmark."],
["No persistent-memory tier", "Persistent and CXL-attached memory sit under the provider's own key until there is a second provider to agree with."],
["No per-process limits", "cgroup limits on a container platform are the platform's terms, linked from the offer's url."]
]
};
export default function OpenMemoryPage(): ReactNode {
return <ResourceSpecPage spec={SPEC} />;
}

View file

@ -26,6 +26,10 @@ const STATIC_ROUTES: Array<{
{ path: "/openmcp", changeFrequency: "weekly", priority: 0.9 }, { path: "/openmcp", changeFrequency: "weekly", priority: 0.9 },
{ path: "/openaccess", changeFrequency: "weekly", priority: 0.9 }, { path: "/openaccess", changeFrequency: "weekly", priority: 0.9 },
{ path: "/openserver", changeFrequency: "weekly", priority: 0.9 }, { path: "/openserver", changeFrequency: "weekly", priority: 0.9 },
{ path: "/opencpu", changeFrequency: "weekly", priority: 0.9 },
{ path: "/openmemory", changeFrequency: "weekly", priority: 0.9 },
{ path: "/opengpu", changeFrequency: "weekly", priority: 0.9 },
{ path: "/openbandwidth", changeFrequency: "weekly", priority: 0.9 },
{ path: "/openontology/explore", changeFrequency: "daily", priority: 0.7 }, { path: "/openontology/explore", changeFrequency: "daily", priority: 0.7 },
{ path: "/openspec", changeFrequency: "weekly", priority: 0.8 }, { path: "/openspec", changeFrequency: "weekly", priority: 0.8 },
{ path: "/agent-swarm", changeFrequency: "weekly", priority: 0.8 }, { path: "/agent-swarm", changeFrequency: "weekly", priority: 0.8 },

View file

@ -0,0 +1,167 @@
import Link from "next/link";
import type { ReactNode } from "react";
import { SiteShell } from "@/components/site-shell";
import { mono, pre, table, td, th } from "../app/openontology/ui";
/**
* One landing page shape for the five OpenServer resource specifications
* (OpenCPU, OpenMemory, OpenDisk, OpenGPU, OpenBandwidth). Each page is
* the same five bands with different words, so the words live in the page
* and the bands live here.
*/
export type ResourceSpec = {
/** Display name, e.g. "OpenCPU". */
name: string;
/** URL slug under /docs and /, e.g. "opencpu". */
slug: string;
/** The block key on an OpenServer offer, e.g. "compute". */
block: string;
/** One line under the title. */
tagline: string;
/** Two or three sentences on why the resource needs its own words. */
problem: ReactNode;
/** The example block, pretty-printed JSON. */
sample: string;
/** The smallest valid block, one line of JSON. */
smallest: string;
/** Field name, values, meaning. */
fields: Array<[string, string, string]>;
/** What a directory does with the block. */
directory: Array<[string, string]>;
/** What is deliberately absent, and why. */
absent: Array<[string, string]>;
};
const SIBLINGS: Array<[string, string]> = [
["OpenCPU", "opencpu"],
["OpenMemory", "openmemory"],
["OpenDisk", "opendisk"],
["OpenGPU", "opengpu"],
["OpenBandwidth", "openbandwidth"]
];
export function ResourceSpecPage({ spec }: { spec: ResourceSpec }): ReactNode {
const wellKnown = `/.well-known/${spec.slug}.json`;
return (
<SiteShell active={spec.name}>
<div className="band">
<div className="section-head">
<p className="eyebrow">LogicSRC standards surface · OpenServer resource</p>
<h2>{spec.name}</h2>
<p>{spec.tagline}</p>
</div>
<p style={{ color: "#41505d" }}>{spec.problem}</p>
<p style={{ color: "#5b6b7a" }}>
Status: 0.1. The <code style={mono}>{spec.block}</code> block of an{" "}
<Link href="/docs/openserver">OpenServer</Link> offer, written down on its own. A provider
that sells only this resource lists it as an offer and may serve the same document at{" "}
<code style={mono}>{wellKnown}</code>. Every rule degrades: the smallest valid block is{" "}
<code style={mono}>{spec.smallest}</code>.
</p>
</div>
<div className="band">
<div className="section-head">
<h2>The {spec.block} block</h2>
<p>
Every key is the provider&apos;s claim, in fixed units. <code style={mono}>range</code>{" "}
is the part a buyer can dial at checkout: the field, its bounds, the step and what a
step costs.
</p>
</div>
<pre style={pre}>{spec.sample}</pre>
</div>
<div className="band">
<div className="section-head">
<h2>Fields</h2>
<p>Absent means unstated, never a default. A reader says so beside the number.</p>
</div>
<table style={table}>
<thead>
<tr>
<th style={th}>Key</th>
<th style={th}>Values</th>
<th style={th}>Meaning</th>
</tr>
</thead>
<tbody>
{spec.fields.map(([key, values, meaning]) => (
<tr key={key}>
<td style={td}>
<code style={mono}>{key}</code>
</td>
<td style={td}>{values}</td>
<td style={td}>{meaning}</td>
</tr>
))}
</tbody>
</table>
</div>
<div className="band">
<div className="section-head">
<h2>What a directory does with it</h2>
</div>
<table style={table}>
<tbody>
{spec.directory.map(([what, how]) => (
<tr key={what}>
<td style={td}>
<strong>{what}</strong>
</td>
<td style={td}>{how}</td>
</tr>
))}
</tbody>
</table>
</div>
<div className="band">
<div className="section-head">
<h2>What is deliberately absent</h2>
</div>
<table style={table}>
<tbody>
{spec.absent.map(([what, why]) => (
<tr key={what}>
<td style={td}>
<strong>{what}</strong>
</td>
<td style={td}>{why}</td>
</tr>
))}
</tbody>
</table>
</div>
<div className="band">
<div className="section-head">
<h2>Where everything lives</h2>
</div>
<ul style={{ color: "#41505d", lineHeight: 1.9, paddingLeft: "1.1rem" }}>
<li>
<Link href={`/docs/${spec.slug}`}>Specification</Link>: the block, every rule and how
it degrades, the resource as its own offer, what a directory owes a provider
</li>
<li>
<Link href="/docs/openserver">OpenServer</Link>: the descriptor at{" "}
<code style={mono}>/.well-known/openserver.json</code> that this block sits in, and the
directory that reads it
</li>
<li>
The five resources of a purchase:{" "}
{SIBLINGS.map(([name, slug], i) => (
<span key={slug}>
{i > 0 ? ", " : ""}
{slug === spec.slug ? <strong>{name}</strong> : <Link href={`/${slug}`}>{name}</Link>}
</span>
))}
, each with the same <code style={mono}>range</code> shape
</li>
</ul>
</div>
</SiteShell>
);
}

View file

@ -18,6 +18,10 @@ const NAV: Array<{ href: string; label: string; external?: boolean }> = [
{ href: "/openmcp", label: "OpenMCP" }, { href: "/openmcp", label: "OpenMCP" },
{ href: "/openaccess", label: "OpenAccess" }, { href: "/openaccess", label: "OpenAccess" },
{ href: "/openserver", label: "OpenServer" }, { href: "/openserver", label: "OpenServer" },
{ href: "/opencpu", label: "OpenCPU" },
{ href: "/openmemory", label: "OpenMemory" },
{ href: "/opengpu", label: "OpenGPU" },
{ href: "/openbandwidth", label: "OpenBandwidth" },
{ href: "/#cli", label: "CLI" }, { href: "/#cli", label: "CLI" },
{ href: "/docs", label: "Docs" }, { href: "/docs", label: "Docs" },
{ href: "/blog", label: "Blog" }, { href: "/blog", label: "Blog" },

View file

@ -22,6 +22,10 @@ export const DOC_SLUGS = [
"openaccess", "openaccess",
"openserver", "openserver",
"openstream", "openstream",
"opencpu",
"openmemory",
"opengpu",
"openbandwidth",
"openspec-comparison", "openspec-comparison",
"data-model", "data-model",
"cli", "cli",

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.