Verlex

One line of Python. Every cloud's best GPU price.

Verlex reads any Python function, picks the hardware it needs, prices it live across 10 clouds, and runs it on the cheapest one. If a provider fails or stocks out, the job restarts on the next cheapest, automatically. No hardware picking. No quotas. No DevOps.

The provider's GPU price passes through at cost. Verlex adds a fixed service fee per GPU-hour, prorated per second. That is the whole model: no percentage markup, no hidden margin.

Installation

pip install verlex

Requires Python 3.10, 3.11, 3.12, or 3.13. Grab your API key from the dashboard.

Quick Start

import verlex

# Define your function
def train_model():
    import torch
    model = torch.nn.Linear(100, 10)
    # Your training code here...
    return {"accuracy": 0.95}

# Run it on a cloud GPU - that's it!
result = verlex.cloud(train_model, gpu="A100", api_key="gw_your_key")
print(result)

Basic Usage

Pass your API key

Every function accepts api_key directly, no context manager needed. Set VERLEX_API_KEY in your environment to omit it entirely.

import verlex

result = verlex.cloud(my_function, api_key="gw_your_key")

Passing inputs

Your function's inputs come right after the function. A function that takes a single input accepts a bare value; a function that takes two or more inputs must receive them as one list.

# No inputs
verlex.cloud(train_model)

# One input, a bare value is fine
verlex.cloud(square, 5)

# Two or more inputs, pass them as a single list
verlex.cloud(train, [dataset, epochs])

Specifying resources

Every hardware field is optional, and only the fields you set are pinned. Whatever you leave out is sized from your code and chosen for cost and availability — asking for a GPU and nothing else is the normal case.

# One GPU pinned; cpu, memory and provider are chosen for you
result = verlex.cloud(train_model, [data], gpu="A100")

# Pin more when you need it — each field is independent
result = verlex.cloud(train_model, [data], gpu="H100", gpu_count=8)
result = verlex.cloud(train_model, [data], cpu=4, memory="16 GB")

# A list offers alternatives: the cheapest available wins
result = verlex.cloud(train_model, [data], gpu=["H100", "A100"])

Reusing the same machine? Wrap it in a Hardware object — identical meaning, one value.

from verlex import Hardware

big = Hardware(gpu="H100", gpu_count=8, memory="512 GB")

result = verlex.cloud(train_model, [data], big)          # positionally
result = verlex.cloud(train_model, [data], hardware=big) # or by name

Values are checked in your process, before anything is provisioned: a misspelled option answers did you mean gpu=?, and gpu="64 GB" tells you it belongs in memory=. A Hardware and a keyword that disagree about the same field raise rather than one silently winning.

The full set of job options:

result = verlex.cloud(
    train_model,
    [data],
    gpu="A100",        # GPU type
    cpu=8,             # vCPU cores
    memory="64GB",     # memory
    provider="aws",    # pin to a cloud (omit to let Verlex pick the cheapest)
    timeout=7200,      # 2 hour timeout
    pip_packages=["numpy==1.26.4"],  # extra packages, always installed
    python_version="3.11",  # match your local Python
)

Execution Modes

One flag controls your price-speed tradeoff.

# Performance mode, immediate execution
result = verlex.cloud(my_function, api_key="gw_your_key", fast=True)

# Standard mode (default), wait for the lowest price
result = verlex.cloud(my_function, api_key="gw_your_key")

Performance mode (fast=True) requires the Performance plan ($10/mo). Standard mode is available on every plan.

Pricing & Billing

Two parts: a monthly plan, then a per-job cost. Verlex passes the provider's live hardware price through at cost and adds a fixed service fee per GPU-hour, prorated per second. There is no percentage markup on the hardware.

The service-fee tier is derived from the hardware's FP16 tensor performance (TFLOPS):

The service fee is charged per GPU-hour, so an 8-GPU job pays it 8 times. There is no cold-start surcharge; a cold machine and a warm one cost the same.

• Per-second billing, 1 second minimum. Both the provider cost and the service fee are prorated to the second. You pay only for the time your job actually runs.
• Prepaid credits. Buy credits in the dashboard (minimum top-up $10). Each job places a hold and settles the exact amount when it finishes.
• Auto top-up (opt-in). Adds credits with your saved card when the balance runs low (default: $50 added when it drops below $10).
• Funds-based execution. There is no maximum job runtime. A job runs until your credits are exhausted, it stops making progress, or it finishes. The optional timeout argument is a client-side wait bound.

Plans

Per-second billing, no credit card required to join.

Providers, Failover & Serverless

Every job is priced across 10 clouds (AWS, GCP, Azure, Verda, RunPod, Vast.ai, JarvisLabs, Hyperstack, TensorDock, Lyceum) plus four serverless container lanes (Beam, Northflank, Novita, Cerebrium), and routed to the cheapest machine that fits.

import verlex

# Default: priced across 10 clouds, routed to the cheapest machine that fits
result = verlex.cloud(train_model, gpu="A100", api_key="gw_your_key")

# Provider list: cost comparison and failover stay inside your subset
result = verlex.cloud(
    train_model,
    gpu="A100",
    provider=["runpod", "gcp", "verda"],
    api_key="gw_your_key",
)

# Hard pin: one provider, no cross-provider failover if it is out of stock
result = verlex.cloud(train_model, gpu="A100", provider="aws", api_key="gw_your_key")

• Automatic failover. If a launch fails or a region is out of stock, Verlex fails over: nearby regions first, then other providers, then substitute GPUs, always cheapest first. Your job does not fail because one cloud ran out of capacity.
• Pinning. A single provider pins hard with no failover. Prefer a provider list, which keeps cost comparison and failover inside your chosen subset.
• Serverless. Small jobs route to serverless container lanes (billed per second) when that is cheaper than a VM. This happens automatically; nothing to configure.

Files & Workspace Sync

Send local files up to the VM before your job runs and bring generated files back when it finishes. Pass a Workspace to any cloud call. Auto mode mirrors your project root (respecting .gitignore) and returns whatever your code creates or changes; or list explicit Upload and Output specs for full control.

import verlex
from verlex import Workspace

def train():
    from pathlib import Path
    Path("runs").mkdir(exist_ok=True)
    Path("runs/loss.json").write_text('{"loss": 0.42}')
    Path("model.pt").write_text("weights")
    return {"status": "done"}

# Auto mode mirrors your project root up to the VM, then returns
# new and changed files to the same paths locally
result = verlex.cloud(train, workspace=Workspace(), gpu="A100", api_key="gw_your_key")

# ./runs/loss.json and ./model.pt now exist locally

Your function runs inside the synced workspace, so relative paths like open("data/train.csv") work unchanged. Import Workspace, Upload, and Output from the top-level verlex package.

Dependencies

Verlex scans your function's source, pins the versions of imported packages installed locally, and bundles local .py modules automatically. When you need certainty, pass pip_packages: those packages are authoritative, always installed, and a failed install fails the job loudly instead of continuing silently.

result = verlex.cloud(
    train,
    api_key="gw_your_key",
    pip_packages=["torch==2.3.1", "numpy==1.26.4"],
    python_version="3.11",  # 3.10, 3.11, 3.12, or 3.13
)

Pre-warming

Kill the cold start before it happens. verlex.prewarm(fn) analyzes your function, boots the right hardware, and hands you back a handle once the machine is ready. Calling the handle runs your function with no provisioning wait, and the machine stays attached between calls, so every call is warm.

import verlex

def train(batch):
    import torch
    ...

wf = verlex.prewarm(train, gpu="A100", api_key="gw_your_key")  # A100 starts booting NOW

data = load_and_clean()      # local preprocessing runs meanwhile

result = wf(data)            # runs train(data) on the warm machine
more = wf(other_data)        # still warm, the VM stays attached

wf.release()                 # or use `with verlex.prewarm(train, "A100") as wf:`

Automatic Cloud Offloading

Don't want to manage when code runs in the cloud? Let Verlex decide. verlex.overflow() watches CPU, memory, and GPU. When usage exceeds 85%, heavy functions are transparently offloaded to the cheapest cloud provider; everything else keeps running locally.

import verlex

verlex.overflow(api_key="gw_your_key")

# Your code runs normally.
# When CPU, memory, or GPU exceeds 85%, functions go to the cloud.
data = load_data()
result = train_model(data)   # system overloaded? → cloud
evaluate(result)             # resources free → runs locally

Install the monitoring dependency with pip install 'verlex[overflow]'.

Checkpoints & Spot Recovery

Spot capacity is 60-80% cheaper than on-demand, but the provider can reclaim it at any time. Anything your job writes into the checkpoint directory syncs to object storage while it runs. When a spot instance is reclaimed, the job is re-enqueued on the next cheapest capacity, the checkpoint directory is restored before your code runs again, and the reclaimed time is not billed. HuggingFace Trainer, PyTorch Lightning, and Keras jobs resume with no code changes.

Available GPUs

Request a GPU by name (gpu="A100", or as a spec value). Verlex finds the cheapest available instance across all 10 clouds: T4, L4, A10, V100, A100, L40S, H100, H200, B200, B300, and consumer RTX cards. If you don't specify a GPU, Verlex auto-detects your code's needs and picks the best option.

Authentication

import verlex

# Pass api_key directly to any function
result = verlex.cloud(my_function, api_key="gw_your_key")

# Or use the environment variable (VERLEX_API_KEY)
result = verlex.cloud(my_function)  # picks up from env

Both gw_live_ and gw_test_ prefixes only name the key type; every key runs against the live service with live billing.

Error Handling

Verlex raises specific exceptions so you can handle failures gracefully:

from verlex.errors import (
    VerlexError,              # Base class for all Verlex errors
    AuthenticationError,      # Invalid or missing credentials
    InsufficientCreditsError, # Not enough credits to run the job
    ProviderMaintenanceError, # Pinned provider is under maintenance
    JobFailedError,           # Job execution failed in the cloud
    JobTimeoutError,          # Job exceeded its timeout
    SerializationError,       # Function could not be serialized
    NetworkError,             # Connection to Verlex API failed
    RateLimitError,           # Too many requests
)

Links

• Website: verlex.dev
• Documentation: verlex.dev/docs

Contact

• Support: support@verlex.dev
• Sales: sales@verlex.dev
• General: contact@verlex.dev

License

Apache 2.0