razorBridge AI Blades and sessions

Acest conținut nu este încă disponibil în limba selectată.

A blade is one GPU machine that razorBridge provisions for you on demand and takes away again when it is no longer needed. You reach it over SSH. There is no console to configure, no image to build and no capacity to reserve in advance — which is also why a blade is disposable, and why nothing on its disk survives teardown.

Sessions and events

Every blade comes from one of two flows, and the difference decides who pays and who controls its lifetime.

	Self-serve session	Event blade
Started by	You, in the web app	The schedule, before the event starts
Paid by	Your credit balance	The organizing account’s balance
Lifetime	A duration you choose	The event’s start and end times
Stopped by	You, or the duration expiring	Automatic teardown after the event
Extending	You, in the web app	The organizer, for the whole event
Managed in	GPU Sessions in the web app	The REST API

Both kinds are billed at the same published hourly rate for the GPU type. The API’s blade endpoints cover event blades only; a self-serve session lives entirely in the web app.

What you actually get

A blade is a GPU host running your workload inside a container, with one Linux account per user. Your credentials are a username, a port and a password on the blade’s IP address — for example user01 on port 2201. They are shown only to the person the blade belongs to: in the SSH panel of a self-serve session’s row, or through the API for an event blade.

Because access is password-based rather than key-based, every SSH client — plain ssh, scp, rsync, VS Code Remote-SSH, JetBrains Gateway — will prompt for the password. Installing sshpass lets you script it.

An event can also put more than one user on the same machine (the organizer sets Users per blade, which defaults to one), in which case each participant gets their own container and their own port on a shared GPU host.

AI Blade statuses

The web app and the API report one of six values:

Status	Meaning
`pending`	Accepted, not yet handed to a provider
`provisioning`	The machine is being created and configured
`running`	Ready — you can connect
`stopping`	Teardown in progress
`stopped`	Gone. Billing for it is final
`failed`	Provisioning failed, or an event blade failed a health check. Not billed for runtime

There is no idle status and nothing observes whether you are actually using a blade — see Limits and guardrails for what does stop it.

Lifecycle of a self-serve session

You pick a GPU type and a duration of 1, 2, 4 or 8 hours in the web app under GPU Sessions.
Before starting it, razorBridge checks that your available credit covers the whole duration, that you are under your concurrent-blade limit, and that the session would not exceed your monthly spend cap. The cost of the whole duration is then held from your credit — see Credits and billing.
The blade is provisioned. This usually takes a few minutes; the row updates from Pending through Provisioning to Running, and you get an email when it is ready. The duration counts from the moment it is running. A session that is still coming up can be called off with Cancel; nothing is charged.
Select SSH on the row to reveal the connect command and password.
You can extend a running session by 30, 60 or 120 minutes, as many times as you like, up to the maximum total session length for your account. Each extension enlarges the hold, so it needs available credit and room under your monthly cap.
The session stops when the duration expires, when you choose Stop, or if its accrued cost reaches your balance. You are charged for the time it ran, never more than the amount held, and the rest of the hold is released.

An expiry warning email is sent for self-serve sessions roughly 10-15 minutes before auto-stop. Do not rely on it as your only reminder.

If a running self-serve blade fails a health check, it is stopped and billed for the time it ran. Start a new session to carry on; the new blade has an empty disk.

Lifecycle of an event blade

The organizer schedules an event with a start time, an end time and a GPU type.
Participants join with the event’s code, or are added by the organizer.
Blades are provisioned shortly before the start time — 30 minutes ahead by default. Joining earlier does not create a blade earlier.
Each participant receives an email when their GPU is ready, containing the host, port, username and ready-made SSH command. The password is not emailed: fetch it with GET /v1/blades/<id>/ssh/.
Blades are torn down a few minutes after the event’s end time. Participants get no warning before this happens.
The organizer’s account is charged once, for the total runtime of every blade the event used.

If a blade fails a health check while its event is still running, razorBridge terminates it and provisions a replacement. The replacement has new SSH credentials, so fetch them again rather than reusing the old command — and note that the replacement starts with an empty disk.

Limits and guardrails

These defaults apply to a new account and can be raised per account on request:

Limit	Default
Concurrent self-serve blades	2
Longest single session	8 hours
Spend per calendar month	€50

Two more safety behaviours are worth knowing about:

Balance-triggered teardown. A running self-serve blade whose accrued cost reaches your available balance is stopped immediately, without waiting for its duration to expire.
Orphan reaping. A blade stuck in pending or provisioning for more than 20 minutes is terminated, and its hold released without a charge; a blade still running well past its expiry is torn down. Nothing needs to be cleaned up by hand.

Nothing stops an idle blade. A session you forget about bills for its full duration, whether you were connected or not.

Quickstart — get onto a blade for the first time.
Credits and billing — how runtime turns into a charge.
API reference — the event blade endpoints.
Run an event — the organizer’s side of the event flow.