The Neocloud Atlas

Method

A manifold per company, in two spaces

# each neocloud = a point CLOUD, not a point, in two separate spaces:
#   business space  - one standardized identity anchor per company
#                     (uniform LLM distillation so source style can't leak)
#   technical space - every chunk of its real product documentation,
#                     gathered from docs/product pages across the web
# groupings: hierarchical clustering on anchor cosine (business), and
# chamfer-style point-cloud overlap between doc-chunk sets (technical);
# plus an activity fingerprint per company from its dated event stream
# (8-K/6-K + call corpus for US names, press extraction for the rest)

The map

Explore the two spaces

Business view: one dot per company, colored by family; distance = how similarly their businesses read. Technical view: one dot per company with a documented product, positioned by feature similarity — companies sit together because they offer the same GPUs, consumption models and fabric, not because their docs read alike. Companies with no documentation are absent, which is the point. Click a dot (or any ticker chip on this page) to add that company to the comparison below.

Compare

Side by side

Pick 2–4 companies (dropdowns, map clicks, or ticker chips):

clear

Grouping 1

The value stack — who owns what, and who pays them

Assigned from gathered evidence (contracts, customers, docs, events), not clustered: the question that separates these companies economically is which layer of the stack they monetize. Every assignment carries its rationale, so disagree with specifics, not with a black box. Grey tags are cross-cutting risk/structure flags.

Landlords: sell megawatts, tenant brings GPUs (16)

Revenue is a lease on powered, cooled space. They never touch the GPU or the customer workload; their economics are real estate (per-MW rates, tenant credit, construction timelines). The defining risk is single-tenant concentration, so the flags below matter more than the category.

Compute owner-operators: own GPUs, sell GPU-hours (20)

They buy the silicon and carry its depreciation; revenue is $/GPU-hour or multi-year cluster contracts. Economics = utilization x price vs financing cost. Differentiate them by contract cover (backlog vs spot) and by whether they also own their buildings and power.

Platforms: software margin above the silicon (4)

The GPU is upstream; what they sell is a developer experience - APIs, managed training, inference endpoints. Economics look like software (gross margin, retention), not like real estate or depreciation schedules.

Still miners: the pivot is a press release (7)

AI/HPC revenue is immaterial or zero; the event streams are hashrate updates. They belong in the universe only because they claim the label - which is exactly why tracking them is useful.

Grouping 2

The documentation test

Which "GPU clouds" publish genuine developer documentation? Only 13 of 47 publish rich docs. Every pure landlord has none; the 2026 IPO wave gates its API docs behind sales; one company with $1.5B of announced GPU contracts has no developer documentation at all.

The API surface

What can you actually call?

Automated docs/API discovery per company: official domain resolved with independent confirmation (never name similarity), then deterministic probes of the domain (llms.txt, docs subdomains, OpenAPI specs, sitemap, footer links) and a source-attributed extraction of every documented function, endpoint and CLI command. T1 = evidence the domain owner controls, T2 = two independent sources, T3 = unverified claim. Pick a company:

only companies with functions

Compare APIs

Same label, different machine

Pick 2–4 companies and compare what their APIs let a customer do. Coverage is grouped into capability areas (instances, clusters & Kubernetes, storage, inference, networking, billing, identity, monitoring) from the documented functions themselves. Only companies with at least one documented function are listed; the rest have nothing to compare.

clear

The function space

Every function, one map

This section also lives at its own shareable page: /neoclouds/functionspace

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.

Grouping 3

Activity regimes — what they actually did this year

GPU buyers (10)

Event streams dominated by procurement: GPU orders, cluster deployments, hardware partnerships. These are companies converting capital into compute right now - the Japanese pair's streams are 100% procurement.

IREN HIVE NB2.DE RUM AGPU AIBZ OVH.PA 3778.T 9449.T LAMBDA

Still mining (9)

Whatever the strategy slides say, the dated events are hashrate updates, mined-BTC counts and mining economics. The pivot exists in language; the activity record hasn't caught up.

CLSK MARA PWCM ANY ABTC CANG FUFU PHX.AD ARBK

Debt-financed builders (7)

Notes offerings, term loans, GPU-backed credit facilities. The leverage cohort: fastest scaling, most exposed if GPU economics soften.

NBIS APLD KEEL CRWV BTBT SHAZ DOCN

Construction and equity (20)

Shells energizing, campuses building, leases signing - funded by equity raises rather than debt where capital appears at all. The landlords cluster here alongside equity-funded builders like Crusoe and Cerebras.

CIFR WULF CORZ HUT GLXY RIOT BTDR WYFI SLNH BRUN QMLS MIGI DGHI DMGI.V CBIT.V GREE GPUS CBRS CRUSOE NSCALE

Business anchors are LLM-distilled to one format so source style cannot drive the clustering. Technical similarity covers only companies with real documentation; absence is reported, not imputed. Activity fingerprints use the filing/call event corpus for US names and press extraction for foreign and private names (shallower, flagged by source). Several tickers renamed during 2026 (GREE→VIP, MIGI→BGDE, DGHI→DGXX; Cathedra merged into Sphere 3D). Educational; not investment advice.