Coretype Collections

concept · Reviewed 2026-09-15 GA

Coretype Collections are curated groups of compatible coretypes exposed as a single "Plus" tile on the Hardware step. Each Collection is anchored on an entry point coretype (for example, Emerald Plus is anchored on Emerald) and guarantees that any underlying member used at runtime is at least as performant as that entry point.

When you pick a Collection, the per-core ODP price is fixed at submit time regardless of which underlying instance runs the job, your core count is locked, and the platform may provide more memory, storage, network bandwidth, or memory bandwidth per node than the entry point without charging extra.

A Collection appears as one tile on Hardware Settings. This job selected Emerald Plus at 32 cores.

Collections are ODP-only and Linux-only today. They do not have ODE or ODR variants. If you select an individual coretype that belongs to a Collection, the UI may suggest switching to the matching Plus tile.

Seeing which coretype actually ran

When a job runs on a Collection, the platform displays which specific coretype was used. The Collection remains the product identity (what you selected and are billed for), and the actual coretype is shown as operational detail useful for performance analysis.

Where	Before launch	After launch
Hardware Settings	Emerald Plus	Emerald Plus, with the coretype that ran
Review page	Emerald Plus	Emerald Plus → Emerald
Jobs list, Hardware column	Emerald Plus	Emerald Plus (Emerald)

The job CSV export carries both, in two columns:

Column	Contains	Example
hardware_setting	What you selected	Emerald Plus
coretype_name	What actually ran	Emerald

For a job submitted on a single coretype rather than a Collection, both columns carry the same value.

Available Collections

Each Collection is anchored on its entry-point coretype, the first one listed. Collection membership is set by Rescale and can change as new hardware is added, so treat this as the current set rather than a contract.

Collection	Coretypes included
Catseye Plus	Catseye, Calyptolite
Elm Plus	Elm, Balsam
Emerald Plus	Emerald, Calyptolite, Catseye, Starlite
Hickory Plus	Hickory, Balsam, Rowan, Rutile
Jacinth Plus	Jacinth, Kinoite
Kyanite Plus	Kyanite, Andalusite, Moissanite
Larch Plus	Larch, Hickory, Rowan
Lavender Plus	Lavender, Hydrangea
Lilac Plus	Lilac, Thomsonite
Linden Plus	Linden, Hazel
Malachite Plus	Malachite, Caesium, Reidite
Maple Plus	Maple, Larch
Melanite Plus	Melanite, Andalusite, Clerite, Kyanite
Moonstone Plus	Moonstone, Malachite, Tantalum
Oak Plus	Oak, Box
Redbud Plus	Redbud, Hickory, Linden
Rutile Plus	Rutile, Balsam
Spindle Plus	Spindle, Elm, Hickory, Larch
Starlite Plus	Starlite, Calyptolite, Jacinth
Willow Plus	Willow, Spindle
Zeolite Plus	Zeolite, Erionite

A coretype can belong to more than one Collection: Balsam, for example, is a member of both Elm Plus and Hickory Plus.

Collections behave like ordinary coretypes for templates, job duplication, automations, scripting and budget enforcement.

Collections and Sets are different things

	Coretype Sets	Coretype Collections
Shape	An ordered fallback list you move down	A single tile with several eligible machines
Price	Varies with the coretype that succeeded	Fixed at the tile price
Core count	May change on fallback	Fixed
Priority	Can mix ODE and ODP	ODP only

A Collection can be a member of a Set. Use a Collection when you want one price and one core count with room for the platform to optimise underneath; use a Set when you would rather accept a different coretype, price or core count than wait for capacity.

Related

• Coretype Sets for ordered fallback across coretypes and priorities
• Coretypes for the individual coretypes and their specifications
• Coretype Explorer for comparing hardware side by side
• Hardware for how hardware selection works overall