Studio
Build the workflow.
Watch it run on real cards.
A canvas for agent pipelines where each step can hold a GPU. Draw the graph, attach the hardware, and read back exactly what happened.
Studio
The diagram is the workflow
Steps are nodes and the wiring is the plan: gather fans out to embed, tool calls and rank; they merge to generate, a step grades the draft and revises on a low grade, then a person reviews and answer delivers. Every step that needs a GPU gets its own card.
Inspector · no step selected
Hover any step in the pipeline to inspect it: what it takes in, what it hands back, and which resource it actually runs on.
worked example · rates from data/gpu-rates · hover a step to inspect it
Designed to help you build
Gather, embed, grade, train, evaluate. The expensive step is one of five, and the other four do not need the expensive card.
- An H100 only where it earns its rate
- Approval steps hold nothing, cost nothing
- Price frozen at match time
One cheap card per shard, many shards, and a step that waits for a person to sign off before the costly half begins.
- Fan out across many small cards
- A human gate before the spend
Run the same set twice against two prompts, score both, and keep the hardware identical so the only thing that changed is the prompt.
- Two arms, one scoreboard
- Identical cards, so the delta is the prompt
A single always-warm step that scales its card up for a burst and releases it the moment the queue drains.
- Autopilot lends idle cards between steps
Studio
A workflow you grow, then run on real cards
Start with a single step. Attach a card, add a human gate, branch it, read it back. Nothing is required except the first line, and everything else is added only when the work asks for it, until the graph you drew is the graph that runs.
4 cards held while their steps ran, 4 released. Billed by the second, at the rates beside them.
Start with a stepsteps
A workflow is a graph, and one node holds one piece of work. Studio draws the graph it runs, so the shape of the work and the cost of the work are the same picture.
Attach a cardgpu
Give a step a GPU and it holds that card only while it runs, billed by the second, then released.
Add a human gategate
Put an approval between two steps. It holds no card and costs nothing for the hour it waits on a person.
Branch it, and loop itedges
Lanes work themselves out from the wiring, so what runs at once is something you read. A loop with no exit condition is marked before it runs.
Bring a graph you already wroteimport
LangGraph, LangChain and CrewAI graphs are import sources, not competitors. The intent is an existing graph arrives as nodes you can see. The importer is still being built.
Read back what happenedobservability
Spans nested as traces, and where the time went, once a run has happened. Every span flat and sortable when a tree is not what you need.
Put it on a scheduleschedule
Run a workflow on a cron so a nightly job continues durably without an active session. Planned, not shipped.
Hand it to Autopilotautopilot
Autopilot reads the same runs and says where a different card or a different schedule would change the bill. Studio builds it; Autopilot makes it cheaper.
Powered by Compute
Every step you drew is a real rental underneath: a GPU held only while the step runs, billed by the second, then released. Studio is the picture. Compute is the machine.
See Computescroll on: the run and its thread appear once the graph is drawn.
A run
Three ways in, one plan, a trace out
A push, a schedule or a person's approval starts a run. The plan fans into steps that each hold the card they need, or none, and the steps gather into a trace the next plan reads.
Studio is planned. This is how a run is designed to flow, not one that ran.
Jobs
A job fans out, and the tasks add back
The control plane splits a job into job_tasks rows, places each on a card, and marks the job done only when every task has: queued, running, succeeded or failed, and nothing else.
One big embedding job cut into four shards by source: wiki pages, PDFs, support tickets and emails. Same work, same card, four at once.
Observability
Read a finished run, span by span
Every step becomes a span: when it ran, for how long, and the card it held. embed and rank overlap because they run at once, and review holds no card while it waits.
samplerelative widths, not measured durations
A run, typed out
What a run prints
One command, then one line per step as it takes a card, does its work and gives it back. The two steps that run at once appear together.
sampleRunning a graph is still being built, and kracht studio is not in the CLI yet. This is the designed output, not a recording.
What it shows
Studio
No cluster, nothing left idle
You never configure queues, servers, or storage. A step holds a card only while it runs.
Nothing to provision. A step asks for a card when it runs and releases it when it is done, with no scheduler or spare box to keep warm.
A card per step. An embedding pass and a 70B generation do not share a GPU, so the heaviest step does not set the rate for the graph.
A gate waits for free. A run can wait on a person for minutes or hours, and the gate holds no card while it pauses, so nothing meters during the wait.
Pay by the second. Metered in euro; a released card bills nothing, so idle time between the busy steps costs nothing, all the way down to the second.
In practice
What people build with Studio
Each is a job the canvas is for. The ones marked need something not yet shipped, and say so. Open one to see how it holds up.
Each step gets the card it needs rather than the one the whole pipeline was sized for. The shape of the work and the cost of the work become the same picture.
- 1 card
- per step, not per pipeline
- per-second
- held only while it runs
Beyond the graph
A workflow is more than its shape
It saves, moves as one file, and remembers what it did. The badge on each cell says what's here today.
Import and export
liveA workflow is its /v1 payload. Export the JSON to keep it, share it, or diff it in review; post it back to import. No lock-in, no bespoke format.
{ "steps": [
{ "id":"gather", "gpu":"h100" },
{ "id":"grade", "kind":"human" }
] }POST /v1/workflows
{ "steps": [ … ] }
→ nodes on the canvasStorage
liveA workflow you draw saves to your account the moment you draw it. No file to lose, no export step to remember.
Run memory
plannedThe thread, per-step state and traces of a finished run. The runs shown today are worked examples; yours arrive once a workflow can execute.
From your editor
plannedBecause a workflow is the /v1 payload, you can build one from code today. An editor extension that renders and edits it in place is on the way.
import { workflow } from "@kracht/studio" // planned
const wf = workflow()
.step("gather", { gpu: "h100" })
.step("grade", { kind: "human" })
.edge("gather", "grade")Cookbook
Recipes to copy
The worked examples the console ships with, as workflows you can lift. Real rate card, nothing stored.
Where to go next
Studio is one surface on a marketplace. These are the others.
Frequently
asked questions
You can draw a workflow and save it to your account. You cannot yet make it run: attaching a card to a step is drawable, and executing the graph so a step actually holds one is the part still being built.
Continue through the platform
The next part of the same job
Every step runs on a rented card
Studio decides which GPU each step holds; Compute is where that GPU comes from. Same per-second rate, euro ledger, and catalogue. Compute is live today.
The graph becomes a cost model
Autopilot reads the time and utilisation behind each step, then shows where a different card or schedule could change the bill.
Spin up a GPU, or earn from your own
Rent on-demand compute by the second, or list idle hardware and let it pay for itself. Same marketplace, both directions.
No card required
- 85%
- revenue to providers
- Per-second
- billing, live
- EUR
- metered to the microeuro