A GPU price move.
What does it prove?

Nebius: the last public rates BEP observed

These are USD on-demand list rates per GPU-hour from Nebius’s public price page, captured 2026-09-18T04:49:35.343Z. The page does not specify regions per row. Regional eligibility and taxes must be checked in the provider’s pricing documentation.

Last check: 2026-09-18T04:49:35.343Z · ok. This is a dated observation, not a live booking quote. A failed later check preserves the last successful capture. Check the timestamp before using these figures.

Three records that should never be confused

1. Observed price: a rate captured from a provider source at a known time, with GPU, currency, region and rental terms. It does not reveal the exact moment the provider changed its rate.
2. Announced future price: a separately reviewed notice with an effective date and source strength. A customer repost remains unverified until supported by authenticated or official evidence. Reaching its effective date does not prove implementation.
3. Market benchmark: an index or market sample that gives context. It is not necessarily an executable offer for the same configuration, region, contract or available capacity.

From a headline to a budget question

If a B200 rate rises from $7.15 to $8.50 per GPU-hour, the increase is $1.35, or 18.9%. At 1,000 GPU-hours, that scenario adds $1,350 before taxes, storage, networking, discounts and workload differences. These figures illustrate the customer-reported October 1 notice; they are not an authenticated provider announcement.

For a compute buyer, the next question is whether that rate and effective date apply to the actual contract and region. For an investor, it is whether matched prices elsewhere also rise, and whether higher posted rates translate into realized revenue. Neither answer follows automatically from one social post.

How the BEP monitor works

• Nebius public pricing and regional documentation, Lambda and Vultr catalogs, RunPod secure/community prices, and a separately scoped Nebius account estimate are scheduled for collection every two hours at :17 UTC. Scheduler delays, source failures and deployment time can increase latency.
• Each completed check preserves its own timestamp, result, configuration and source evidence. SHA-256 hashes identify saved source bytes. They do not authenticate the truth of a source.
• Changes compare the same configuration within the same source. New or removed configurations create coverage-review records instead of synthetic price moves. The first capture establishes a baseline.
• Price moves of at least 5% appear in the significant-change view. Smaller moves remain available. Changed pricing text creates a review item even when parsed rates stay flat.
• Future notices use a separate editorial intake and revision trail. Private customer email is not automatically collected. BEP does not claim it discovered the existing October report before the preserved record.
• Failed checks remain visible. Stale prices do not receive new successful observation timestamps. No email or push-alert service is configured; updates appear in the subscriber feed.

The subscriber record adds source snapshots, before/after checks, adjustable cost scenarios, and available Ornn market context. It keeps raw evidence and account-specific data behind subscriber access.

What this research cannot yet establish

A verified same-region, same-configuration competitor panel, realized transaction prices, available fleet capacity and provider margins are separate research questions. The account-estimate coverage currently covers H100 in eu-north1 only. It is account-specific and is kept separate from public list quotes. Monitoring two public pages does not guarantee early discovery of private notices or announcements published elsewhere.

Corrections preserve earlier records and explain the revision. Research disclosures describe the broader scope of BEP’s work.