The Function Space

Takeaways

How the neoclouds actually differ

Read the 515 functions and three API archetypes fall out:

• General clouds that happen to sell GPUs. Rumble Cloud (78 functions), CoreWeave (75), DigitalOcean (64), Sakura (53) and OVH (40) expose an AWS-shaped surface: VPCs, Kubernetes, object storage, instance lifecycle. CoreWeave leans hardest into networking and Kubernetes; DigitalOcean is the only one with databases, an app platform and serverless functions; Sakura is a full Japanese cloud, not a GPU rack.
• AI-first platforms. Nebius (48) and Cerebras (52) barely mention servers: Nebius's API is AI jobs and endpoints, Cerebras's is model management and deployment, full stop. E2E and Nscale sit here too, centered on GPU/AI deployment. Their customer manages models, not machines.
• Thin or telling surfaces. Lambda's public API is small (16 functions, mostly serverless); Crusoe exposes just 8 (VMs + Terraform); Galaxy 3, Hydra Host 2. GMO's developer docs are mostly its payments business — the GPU cloud itself publishes almost nothing. And 33 of the 47 companies in the Atlas expose zero callable functions.

Two facts sharpen the picture: the most similar API pair in the universe is Sakura and Rumble (70%) — a Japanese sovereign cloud and a video platform's cloud arm converging on the same general-cloud shape from opposite directions — while Nebius, Nscale and E2E form their own AI-native cluster, closer to each other than to any general cloud. In other words: "neocloud" is one label covering at least three different machines. The sections below show where each claim comes from — the method, then the maps.

Ask

Ask the function space

A small assistant grounded in this page's data: the indexed functions, the groupings, and the overlap numbers. Ask it how any two neoclouds differ, or start from a suggestion:

ask

Answers are generated from the indexed API data and can be imperfect; verify against the charts and source docs below. Not investment advice.

Method

A vector per function

# one embedding PER DOCUMENTED FUNCTION, not per company:
#   text = function name + purpose + method/route, from each company's
#          docs-discovery dossier (source-attributed extraction)
#   Japanese-documented functions translated to English BEFORE embedding
# two models, same math, so embedding artifacts are visible:
#   bge-m3 (local, 1024-dim)  |  qwen3-embedding-8b (OpenRouter, 4096-dim)
# projection: UMAP to 2D and 3D - display only, never used for grouping
# categorization A: Ward linkage on the L2-normalized vectors
#                   (Euclidean on unit vectors = monotone in cosine),
#                   k chosen by best cosine silhouette
# categorization B: HDBSCAN(min_cluster_size=8) on a 15-dim UMAP
#                   reduction - density clusters, noise points allowed
# company similarity: chamfer overlap of whole function sets
#                     (mean best-match cosine, both directions)

The function space

Every function, one map

Each documented function gets its own embedding (name + purpose + route). In function view, one dot per function: dots sit together because the functions do the same thing, whichever company documents them — the cross-company clusters (create instance, list clusters, manage SSH keys, serve a model) are the industry's de facto standard API, and the isolated dots are what only one company offers. In group view, the same dots are colored by machine-found grouping: Ward hierarchical clustering on the embeddings (cosine), the number of groups picked by silhouette score, each group labeled from its members. Functions originally documented in Japanese were translated to English before embedding and are marked (JP). In company view, companies are placed by the overlap of their whole function sets (mean best-match cosine, both directions): two companies sit together when a customer could switch between them and call roughly the same things.

Second opinion: a larger embedding model

The same 515 functions, re-embedded with qwen3-embedding-8b via OpenRouter (a dedicated 8B embedding model, ~14x the local bge-m3) and re-grouped with the identical math (Ward on the normalized vectors, k by silhouette). Where the two charts agree, the grouping is a property of the functions; where they disagree, it was an artifact of the embedding. The company highlight above applies here too.

The cloud in 3D

Same qwen3-embedding-8b vectors, projected to three dimensions instead of two. The projection is display-only (the categories are computed in the full 4096-dim space), but a third dimension roughly halves the distortion: groups that look smeared together in 2D often separate cleanly when you rotate this — that overlap was an artifact of flattening, not a real ambiguity. Drag to rotate, scroll to zoom. The second categorization, HDBSCAN on a 15-dim UMAP reduction (the BERTopic recipe), is a density clusterer: unlike Ward it may leave a function unassigned (grey) rather than force it into the nearest cluster — its clusters are tighter and there are more of them.

The holes

The unclaimed regions, described as products

The empty parts of the map can be named. We wrote a reference catalog of canonical cloud and AI-infrastructure capabilities, phrased exactly like the indexed functions, embedded it with both models into the same space, and measured each item's distance to the nearest documented neocloud function. Calibration: control items that plainly exist (create a VM, list clusters, serve a model) score 83–92. The items below score far lower under both embeddings: products the space says should exist that no neocloud ships today. Each row is a product waiting for an owner; the last column is the closest thing anyone currently documents.

Thinly claimed border zone (one company each, barely): Synthetic data generation, Managed data labeling, Capacity futures reservation, Model evaluation service. Already well covered, for contrast: fine-tuning, usage audit logs, per-second metering, price lookup.

Decoded from the space itself

See also the companion page that runs TRUE vector-to-text inversion on the holes (vec2text, no language model proposing): /neoclouds/openspaceinversion

The section above proposed products first and tested whether their region is empty. This one inverts the arrow: the geometry picks the empty region first. We searched the reduced function space for enclosed holes, cavities between clusters that are empty yet surrounded by real product on every side (evidence the region is habitable), then had the local model propose capabilities that would live between the hole's walls, embedding each candidate to verify it truly lands in empty space. A candidate survives only if no documented function comes near it under either embedding model (existing products score 83+; these score 59–77). Two candidates landed inside their target cavity; four more verified as empty space but could not be steered into the exact cavity, a resolution limit of projecting novel text into the reduced space, reported as what they are.

Read the walls to see why each hole exists: batch execution is fully built (Cerebras) while batch intelligence is not; firewalls exist everywhere while policy composition exists nowhere; templates exist while template governance does not.

Does anyone in the whole market ship this?

Each unclaimed product, from both methodologies, searched by vector against the 10-K product corpus: 4,560 public companies' product descriptions, far beyond the neocloud universe. Queries are context-disambiguated (an early run let the bare word "training" pull education companies into the provenance-ledger matches; every query now carries an explicit AI-infrastructure frame). Two things to know when reading the scores. First, corpus vectors summarize a whole company, so even control queries for products that plainly exist (GPU rental, managed Kubernetes) top out near 60: scores here rank adjacency; they do not decide existence. The existence verdict came from the function-space analysis above. Second, the verdict column therefore compares each best match against that query's own market-wide median. Hover a ticker for its matched product text.

The adjacencies say something: Datadog borders the data-provenance hole (observability is the nearest living discipline), Akamai borders the secure GPU tunnel, Cloudflare borders template policy, and CoreWeave itself borders serverless training, state snapshots, and workload migration — holes one step from its current API. One caveat the search surfaces honestly: a micro-cap whose 10-K is generic AI-infrastructure language (AIIA) borders many holes at once, which is a property of vague prose, not of product breadth. Those adjacent companies are who a builder in each hole would partner with or sell against.

Flip the view: pick a company and see every unclaimed product it borders (only companies with at least one top-8 connection are listed):

Function inventories come from each company's own developer documentation via automated docs discovery (domain resolved with independent confirmation, extraction source-attributed, evidence tiered). Companies that publish no callable functions are absent, which is the point. Japanese-language documentation translated before embedding and marked (JP). Educational; not investment advice.