DEV Community: Runware

Introducing Style LoRA Training on Runware

Ally Nicoll — Tue, 18 Aug 2026 19:06:09 +0000

Style LoRA training is now live on Runware. Train a custom style into your own model in minutes, so every image you generate already looks like your brand, without re-describing it in every prompt. Upload a small set of images, pick a base model, and get back a lightweight fine-tuned adapter that's more consistent and controllable than steering a model with reference images alone. Train on FLUX.2 [klein] 4B or 9B, FLUX.1 [dev], Qwen-Image, or Z-Image Base. Once trained, your LoRA is immediately available in your Runware account for inference.

Integrate low-cost LoRA training into your application in minutes, with Runware's enterprise API.

LoRA training is now live on Runware. This article covers the what, the why, and the how: what a LoRA actually is and which models support it, why you'd train one instead of leaning on reference images alone, and how to run one against your own dataset.

If you already know your way around LoRAs and just want the practical details, jump to How does it work for the models, parameters, and cost, or Get started for a ready-to-run API request. Otherwise, read on from here.

This is a style trainer, more on what that means below, but the short version: if you've ever burned a dozen generations trying to get a reference image on Seedream, Nano Banana, or any model which accepts reference images, to reproduce your branding or style, this is built for exactly that problem.

What is a LoRA?

A LoRA (low-rank adaptation) is a lightweight fine-tuning method: a small adapter trained on top of a base image model. Feed it a set of images and it learns a specific style, a visual identity, a recurring look, without retraining the whole model from scratch. The result is lightweight, fast to produce, and easy to plug into normal generations.

Style consistency is easiest to see rather than describe. This LoRA was trained on six illustrations sharing one bold, blue-and-yellow halftone look:

Generate new subjects afterward, never seen in training, and the style still holds:

LoRA vs reference images: which do I need?

Models like Seedream 4.5/5 and Nano Banana 2, and others that accept reference images, are useful, especially for one-off jobs where you don't have a dataset to train on. But if you're trying to hold a consistent visual identity across dozens or hundreds of generations, the tradeoffs are significant:

Consistency. A reference image is a suggestion the model interprets on each generation based on many variables. A LoRA trains a concept into the model weights, so the same style shows up reliably across a much larger volume of outputs.
Control. You can adjust LoRA strength, combine multiple LoRAs, layer them against different prompts. There's no such control with reference images.
Iteration cost. Getting a reference-image generation to land in the perfect way often means re-rolling generations multiple times. A trained LoRA gives you a stronger starting point on every single generation, so there's less trial and error per image.
Ownership. You get the raw .safetensors file for your trained model.

Reference images still make sense when you don't have 10+ images to train on, or when you just need a quick one-off generation.

How could a LoRA be useful to me?

The initial Runware LoRA trainer focuses on style capture, rather than subject, character, or specific faces, think in terms of look rather than likeness:

A studio's specific visual identity: film grain, color grading, illustration styles, held consistent across an entire campaign
Product photography with a repeatable, branded rendering style across many scenes and angles
Game or app asset pipelines that need one coherent art style across hundreds of generated assets
Any workflow where "make it look like our content" currently means long prompts, reference images, and a lot of re-rolling

Locking in your brand's visual identity

For brand and design teams, style LoRA training is a way to encode brand guidelines directly into a model: color palette, illustration style, photography treatment, whatever makes content instantly recognizable as yours. Once trained, generations default to on-brand output without rewriting a style guide into every prompt, and without depending on a reference image the model may or may not follow closely. It's a practical way to reproduce your visual identity consistently across campaigns and product lines.

How does it work?

Five models are live for style training right now, all open-weight models already available through Runware's model hosting:

FLUX.1 [dev] - runware:flux-1-dev@style-lora-training - The most widely adopted FLUX checkpoint, with broad LoRA and tooling support.
FLUX.2 [klein] 4B - runware:flux-2-klein-4b@style-lora-training - The smaller FLUX.2 [klein] checkpoint — quicker training runs, lower cost per job.
FLUX.2 [klein] 9B - runware:flux-2-klein-9b@style-lora-training - The larger FLUX.2 [klein] checkpoint, trading training speed for extra output quality.
Qwen-Image - runware:qwen-image@style-lora-training - Strong prompt following and text rendering — a solid all-round choice for style training.
Z-Image Base - runware:z-image@style-lora-training - Lightweight and fast to train. LoRAs trained here also run on Z-Image Turbo.

All five share the same recipe name, style-lora-training: you can train the same dataset across all five models in a single request by submitting one job per model, side by side.

triggerWord is the only required parameter beyond the model AIR and dataset. Leave trainingSteps and learningRate out entirely and Runware applies the defaults for that model, tuned to give you a good result on a typical style dataset - a balance of quality, training speed, and cost.
importModel details how the trained LoRA gets packaged as a named, versioned model in your org. Give it a name, a description, a hero image, and a public or private flag.
The output shows up two ways: as a model available in your org for normal inference requests, and as a downloadable .safetensors file.

Advanced settings, such as trainingSteps and learningRate, are configurable, but they're advanced options, not settings to reach for by default. Push the learning rate too high or too low, or pick a step count that doesn't suit your dataset, and the result can quickly swing from underfitting to overfitting. The defaults we've set are chosen to work well out of the box in the majority of situations.

At 300 training steps the style is only half-applied; the model is still leaning on its photoreal base. By 600 steps, the default for this model, the style has fully taken hold while the subject and composition from the prompt still come through clearly. That's the balance the defaults are tuned for.

What does training cost?

Training is billed per step, the same pay-as-you-go pricing as everything else on the Runware API: no training-specific plan or subscription to opt into.

As a concrete example: the papercraft tiger demo above was trained on Qwen-Image at 600 steps, this model's default, which works out to $0.63 for the full run. Total cost scales directly with however many training steps you choose, and the per-model defaults referenced above are tuned to hit a good style-to-cost balance without any manual tuning.

Continue training instead of starting over

Training doesn't have to be a single, one-shot attempt. If a first pass comes back underfit, you don't need to restart from zero and re-pay for every step: pass the checkpoint parameter with the AIR of a LoRA you've already trained on Runware, and trainingSteps runs as additional steps on top of that checkpoint's final state, rather than training a new LoRA from scratch. Run a few hundred steps, check the result, then decide whether to continue, all while only paying for the additional steps in each follow-up pass:

{
"taskType": "training",
"model": "runware:qwen-image@style-lora-training",
"taskUUID": "{{$guid}}",
"checkpoint": "runware:7ed4a535137bc@training",
"trainingSteps": 300,
"inputs": {
  "dataset": "your-zipped-dataset.zip"
}
}

checkpoint only accepts LoRAs previously trained on Runware; models trained elsewhere aren't supported. That makes dialing in a style an iterative, low-risk process rather than a single expensive bet on the right step count up front.

How do I prepare a dataset?

Whatever dataset images are fed into training, the LoRA learns from directly, so a good dataset is the single biggest factor in a quality result. For style training, here's what's most important to consider when preparing a dataset:

The twelve images above are a single training set: one consistent papercraft style, applied to a dragon, a fox, a steam train, a cupcake, and more. That's the pattern to copy — same look, different subjects.

Quality over quantity. A tight set of clean, well-chosen images beats a huge number of inconsistent ones. You don't need to max out the dataset to get a good result.
Every image, same style. All images should represent the exact look you want the LoRA to learn. The same visual identity is crucial to a good output. Mixing styles in one dataset confuses training and gives you a muddier result.
Variety within that consistency. Vary the subjects, compositions, angles, and lighting, just keep the style itself constant. This is what teaches the model "this is the style" rather than "this is one specific image."
Sharp, clean images. Avoid heavy compression artifacts, blur, watermarks, or text overlays, they get baked into the model along with everything else you want.
No near-duplicates. Each image should add something the others don't. Ten thoughtfully chosen images will outperform fifty crops of the same three shots.
A reasonable working range. You don't need anywhere near the 10,000-image ceiling for style training. A well-curated set of 20-30 images, chosen for quality and consistency rather than volume, is typically enough to get a very strong result.

Captioning

Captions are optional. A captionless dataset works, and for a tight, consistent set of images the trainer will learn the style without any additional guidance. But captions can make a meaningful difference, particularly when your dataset has varied subjects or compositions within the same style.

The format is straightforward: for each image in your zip, add a .txt file with the same base name. The trainer reads them automatically.

your-dataset
├── image_01.jpg
├── image_01.txt
├── image_02.jpg
├── image_02.txt
├── image_03.png
├── image_03.txt

A useful way to think about what goes in each caption: whatever you describe the same way across all images, the model treats as a constant. Whatever varies between captions, the model learns to treat as a variable you can control at inference. For style training, that means the style itself should never be mentioned explicitly in captions; it's what the model is learning from the images. What you do caption is the content: the subjects, scenes, compositions, and lighting in each image. That way the model knows what to attribute to the LoRA's style versus what's just that particular shot.

Each caption should also include your trigger word. If you've set triggerWord to mybrand in the API request, your captions might look like:

mybrand A product photograph of a glass perfume bottle on a marble surface, warm side lighting
mybrand A flat lay of skincare packaging on white linen, soft diffused light
mybrand An editorial close-up of a ceramic object against a muted terracotta background

The trigger word in captions reinforces the association between the word and the style, making the LoRA respond more reliably when you use it at inference. If you're working without captions, the triggerWord parameter in the API request still creates that association; captions just make it more precise.

Dataset requirements

Do:

Zip your dataset, keeping the archive under 4 GiB and the unzipped contents under 5 GiB
Keep individual files under 100 MB after unzip
Include at least 10 valid images (jpg, jpeg, png, or webp)
Keep individual images at or under 8192 × 8192 px
Name caption files with the exact same base name as their paired image (image_01.jpg + image_01.txt)

Don't:

Submit anything that isn't a valid, well-formed zip
Assume oversized or unsupported images are excluded without consequence: skipped files don't count toward your 10-image minimum, so a dataset that looks fine at a glance can still fail with "not enough images" once the system has filtered the inputs down to usable images.

What's next

Style is the first training type. Subject training is coming next, built for a different use case: capturing the likeness of a specific person, character, or object so you can place them consistently across different scenes and prompts. Where style training asks "what does this look like," subject training asks "who or what is this."

More base models are also on the roadmap. The current five cover a range of architectures and output characteristics, and the list will grow as we validate training quality across additional models.

Get started

LoRA training is available in the Runware Playground now if you want to test it on your own dataset before writing any API code. Use the Launch button next to any of the five models above, each one opens that model's training page directly. Prefer to browse first? Open the Playground's model search and select Training from the category list on the left to see every training recipe, these five included.

If you're calling training via the Runware API, a request to https://api.runware.ai/v1 might look like:

{
"taskType": "training",
"model": "runware:qwen-image@style-lora-training",
"deliveryMethod": "async",
"taskUUID": "{{$guid}}",
"importModel": {
  "air": "runware:7ed4a535137bc@training",
  "name": "Example Model",
  "uniqueIdentifier": "runware:0c455ce5c0434",
  "version": "1.0",
  "private": true,
  "heroImageURL": "Optional Cover Image",
  "shortDescription": "first training model"
},
"triggerWord": "mylora",
"trainingSteps": 300,
"learningRate": 0.0001,
"inputs": {
  "dataset": "your-zipped-dataset.zip"
}
}

Once training completes, the importModel.air above is a real model AIR you can call like any other, with your LoRA passed alongside the base checkpoint:

{
"taskType": "imageInference",
"taskUUID": "{{$guid}}",
"model": "runware:101@1",
"lora": [
  { "model": "runware:7ed4a535137bc@training" }
],
"positivePrompt": "mylora product shot of a ceramic mug, studio lighting",
"width": 1024,
"height": 1024
}

FAQ

How many dataset images do I need?

The system will accept between 10 and 10,000 input images, but for style training you don't need anywhere close to the maximum. A smaller, well-curated set of consistent, high-quality images will generally outperform a much larger, messier one.

Do I own the trained LoRA?

Yes. The trained model is added to your org for use in normal inference calls, and you also get the raw .safetensors file to download.

Can I use it for inference immediately after training?

Yes. The AIR returned in the training response is usable in standard image inference requests shortly after training, with no manual import steps required.

Do captions improve results?

Often yes, particularly when your dataset has varied subjects or compositions within one style. Add a .txt file with the same base name as each image, include your trigger word in every caption, and describe the image content rather than the style. A captionless dataset still works; captions just give the trainer more precise signal to work with.

Can I tweak the training settings?

trainingSteps and learningRate are both adjustable, but they're advanced settings. The per-model defaults work well out of the box, so only change them if you already understand their effect on the output.

Which models are available for LoRA training?

FLUX.2 [klein] 4B and 9B, FLUX.1 [dev], Qwen-Image, and Z-Image Base. Z-Image Base trained LoRAs are also compatible with Z-Image Turbo.

Can I continue training an existing LoRA instead of starting over?

Yes. Pass the checkpoint parameter with the AIR of a LoRA you've already trained on Runware, and trainingSteps runs as additional steps on top of that checkpoint's final state. Only LoRAs previously trained on Runware are supported; LoRAs trained elsewhere can't be used as a checkpoint.

Training glossary

LoRA training brings new terminology into the mix that doesn't come up in normal inference. Here's a quick reference for the vocabulary used throughout this article and in the API itself — the same definitions are also available inline as hoverable terms the first time each one comes up above.

LoRA
Low-Rank Adaptation. Originally a concept devised to train LLMs, LoRAs allow a small set of new weights to be trained on top of a large base model, teaching it a new style, subject, or concept without retraining the whole thing. That same idea has since been adapted for image models, which is what powers training on Runware.

Trigger word
A specific word or short phrase included in your prompt that tells the model to apply the trained LoRA's style. It's set at training time and needs to appear in your prompt at inference time for the LoRA's effect to show up.

Training steps
The number of times the model processes your dataset during training. Too few steps and the model won't fully learn the style, too many and it can start overfitting to the exact images you provided rather than generalizing the style itself.

Learning rate
Set it too high and training moves fast but misses detail. Too low and the LoRA barely learns anything. The default is tuned so you don't have to think about it.

Dataset
The set of images (packaged as a zip) used to train your LoRA. Quality and consistency matter more than volume.

.safetensors
The file format the trained LoRA is delivered in. It's the standard, portable format most image generation tools and platforms can load directly, which is why you can download it and use it outside Runware if you want.

Overfitting
A model which tries to reproduce the training data too aggressively, resulting in a LoRA which is hard to work with, doesn't follow prompts well.

Underfitting
The opposite of overfitting: the model hasn't learned enough from the dataset, usually from too few training steps, a learning rate that's too low, or a dataset that's too small or inconsistent. The result is a LoRA with a weak, barely noticeable effect on output generations.

Introducing Sonic Inference Pods: Modular data centers built for inference

Ally Nicoll — Tue, 18 Aug 2026 14:39:16 +0000

Originally posted by Founder Ioana Hreninciuc, on the Runware Blog, Aug 4th 2026.

Sonic Inference Pods are Runware's modular 1MW inference data centers: 1,200 GPUs in a 20-foot container, closed-loop liquid cooling, and 30–80% lower cost per GPU-hour. Here's how we got here.

A Sonic Inference Pod is 1MW of IT compute in a 20-foot shipping container, with a chiller roughly the size of the container sitting on top of it. Inside: around 1,200 GPUs across custom servers with no cases, custom racks, our own PCIe switching, high-frequency CPUs, local NVMe, and a closed-loop liquid cooling system that consumes no water. It arrives on a truck. It needs ground, power, and a network connection. It runs as one node in a single distributed inference network.

Pods are deployed in the United States and Europe. Over the second half of 2026 we will bring up to 10,000 nodes online, and we're targeting more than 1GW of inference compute in 2027. Because we design, build, and operate the hardware ourselves, inference on Sonic Inference Pods costs 30–80% less per GPU-hour than other inference providers depending on the workload. For most workloads it's 50% or more. You can run your models on that capacity today through Runware Serverless.

Learn more & reserve capacity

That's the announcement. The rest of this post is how we got here, and I'd argue it's the more useful part. We did not set out to build data centers. We set out to make inference fast enough and cheap enough to build a product on, and after three years of chasing that, the data center was the last place the cost was hiding.

We do inference. We don't sell data center space.

Worth saying up front, because "startup builds data center" invites the wrong comparison. We're not trying to out-build a hyperscaler, and we don't sell square footage, racks, or colocation. We sell inference. The building is a cost input, not the product.

We build the building because of where the money goes. Sarah Friar, OpenAI's CFO, has put the cost of a gigawatt-scale AI data center at roughly $15 billion for the facility alone, before a single GPU goes in it. Every inference provider renting space in someone else's building pays a share of that, plus the operator's margin, plus the cost of cooling GPUs inside a facility designed for web servers. That was the one layer of our stack we hadn't touched. So we took it out, and what we save there we pass on in the price.

Here's how we got to that conclusion, which took about four years and several things going wrong.

2022: a product that couldn't afford to exist

Stable Diffusion's weights went public in August 2022, and 1.5 followed in October. Like a lot of people, my co-founder Flaviu Radulescu and I thought it was magical technology. It was also extremely slow. Beyond everyone having seven fingers, generating a handful of 512x512 images took close to a minute, sometimes longer.

Flaviu had an idea that sounded implausible at the time: you should be able to use image generation the way you use Google Images. Type a prompt, scroll the results, watch them appear in real time. If that were actually possible, surely one of the labs would already have done it.

He built it anyway. He called it PicFinder, the tagline was "image generation as fast as image search," and he put it on the internet with no plan whatsoever. Some YouTubers found it and featured it. It went from nothing to millions of users in less than two months, and passed 100 million images in three. Generation took under a second while comparable apps took thirty.

He also stopped sleeping, because keeping the GPUs and the product up was a full-time job on its own. I had another job at the time, so what I could usefully do was help pay for the GPUs. We started talking about whether there was a company here. I applied to a16z Speedrun, we got in, I quit my job, and in 2023 we went to San Francisco and got our first check.

Then we came back to London and ran into the wall. The GPU prices we could get made the product impossible. We wanted people to generate effectively unlimited images; the cost per image wouldn't come down far enough to support that. This is the first time we talked seriously about owning hardware.

The GPUs we rented were not the same as each other

We were buying capacity wherever it was cheapest: marketplaces, aggregators, spot instances, whatever we could find. And the quality varied enormously. Same GPU, same price, meaningfully different throughput.

We started testing to work out why, because we needed to understand what a low enough cost per image would take. The answer was that the parts around the GPU mattered far more than anyone was accounting for. CPU clock speed in particular. Nobody selling us GPU hours was optimizing for that, because they weren't selling inference. They were selling GPUs by the hour, and those are different products.

That was the moment hardware stopped being a cost question and became a control question. You can't tune what you don't own.

Summer 2023: three servers on a kitchen table

We had both run infrastructure before and managed clouds, so this felt less mad to us than it probably should have. We bought three nodes with liquid-cooled GPUs, three GPUs each, mostly as an experiment to see what performance we could actually get. They were delivered to my house.

We put the first server case on my living room table, which was also my kitchen table. We decided to document the build as a step-by-step guide, on the reasoning that if we bought more of these, Flaviu was not going to be the person assembling all of them. We assumed the first one would take an afternoon.

It took three days. Not three twelve-hour days, three to six hours each, but three days. The liquid cooling was genuinely intricate: dozens of small parts, everything needing to fit in a particular order. The documenting wasn't what slowed us down; there were two of us. It was just harder than it looked. Every evening we said we'd finish tomorrow. On the third day we finished because we'd run out of tomorrows.

That server then ran in my home office for the entire summer, producing an unbearable amount of heat in a London flat with no air conditioning. It also worked, well enough that we kept it running and used it to test things. We spent the summer swapping components, different CPUs, different RAM, trying to find what actually moved the numbers. Between the hardware changes and the software work happening alongside them, we got roughly 50% more performance out of the same GPUs.

The pivot we didn't want

While that was going on, we tried to raise money for the image generator and failed. In the process we worked out something more useful than the money would have been: we didn't have founder-product fit for a consumer app. Both of us had spent our careers building deeply technical platforms. Neither of us was the right person to run an image generator.

What we did have was the first real-time inference engine for media. So we stopped trying to be the image generator and started building the engine underneath all of them. We called it Runware, went back out to raise, and this time it worked. An oversubscribed pre-seed closed in December 2023.

2024: nobody would take our servers

By then we'd gone from three custom servers to a few dozen, and we were colocating them in data centers. That turned out to be its own problem.

GPU servers draw far more power than the servers those facilities budget for, even with the smaller GPUs we were running then. Operators priced accordingly. Worse, almost none of them supported liquid cooling. In 2023 and 2024 it was very hard to find any data center that would take a liquid-cooled rack at all. So we air-cooled GPUs, which is expensive, inefficient, and throws away a good part of the efficiency we'd just spent a summer engineering in.

This is where it stopped being a procurement annoyance and became the thing we believed. We think every product will eventually touch a GPU. All of those GPUs need somewhere to go, and the data centers that exist don't have the power or the cooling to take them at scale. That isn't a shortage that clears. It's a mismatch between the buildings that exist and the workload arriving.

So at the end of 2023 we started designing our own: the servers and the data center around them, together.

What we built, and why each part is the shape it is

The software platform had to exist first. Most of the first half of 2024 went into building Runware itself, which launched in October 2024 and scaled quickly. Our GPU spend went up with it, which settled any remaining argument about whether we needed our own hardware.

Hiring for it was easier than we expected. Hardware engineers aren't in the bidding war software engineers are in, and we hired people we'd worked with before, so we had a team by the beginning of 2025. Flaviu had been head of R&D and managing director at an infrastructure company in the early 2000s, running data centers with hundreds of thousands of servers, and later co-founded a bare-metal cloud. He'd designed hardware before. He conceived the pod and led the engineering, and that's why the first concept and the finished thing look so similar. We knew which problems we were solving before we started drawing.

Servers with no cases

Our servers don't have cases. They're shelves that click into place like LEGO. That decision comes directly from three days at my kitchen table. It isn't enough for a data center to be efficient to run. It has to be efficient to install. We couldn't have people assembling servers for weeks. The cooling is already routed into the racks so everything lands where it's supposed to. Installation takes hours.

Our own PCIe switch

Having established that CPU frequency matters more than anyone was pricing in, we chose high-frequency CPUs that clock up to 6GHz. Those don't carry enough PCIe lanes for the GPU density we wanted. So Flaviu designed our own PCIe switch. GPUs connect to the CPU and to each other through it. Nodes run 2 to 8 GPUs depending on the workload, and the architecture supports up to 16.

Local NVMe, so models stay warm

One of the real limits on running hundreds of thousands of models is loading time. When you bring up more servers, you have to get the weights onto them, and pulling hundreds of gigabytes from distributed storage is slow. Each of our servers carries enough local NVMe to hold the current generation of large models, frontier LLMs, video models, image models, on the node itself. The whole path is optimized for loading weights into GPU memory as fast as possible, over PCIe. Models are always warm and always local, so cold starts largely stop being a problem.

Cooling nobody would sell us

There was no off-the-shelf system that could cool a megawatt at the density we wanted. We looked at several, worked with a number of companies on a design, and it took an enormous amount of input from Flaviu. The first cooling system we commissioned was never delivered, and we had to start over with someone else. We ended up sourcing components from several suppliers and built it ourselves.

Along the way, expert cooling engineers advised us to fill the system with the wrong liquid. He caught it. That's the difference between hardware and software: there's no debugger, mistakes take months rather than minutes, so you validate everything yourself in more detail than feels reasonable.

What came out of it is a single closed loop that recirculates about 1.5 cubic meters of liquid and holds GPU temperatures within 2°C of target in ambient conditions up to 50°C. Nothing is plumbed in. It has no connection to water mains and consumes no water in normal operation. Physically, there is nothing left to make more efficient.

A shipping container, and a crane

All of it had to fit in a 20-foot container: three rows of servers, one along each side wall and one down the middle, with two aisles to walk between them. The center row is single-sided, with the back of it carrying the rest of the equipment. That comes to around 1,200 GPUs in a shipping container. The chiller sits on top and is about the same size as the container underneath it.

"It ships on a truck" makes this sound simpler than it is. Moving a pod means a crane, which means a crane operator. Then you position the container, lift the chiller onto it, and connect the two. We've now done that enough times to know exactly how long each step takes, which is a different kind of knowledge from designing it.

Any GPU, including the next one

The first working prototype went into production in early 2025 with smaller GPUs, because we still had Stable Diffusion workloads and we were being careful about the most expensive component. It became clear quickly that this wasn't enough. Video models were much larger, and we knew we'd want to run LLMs. So we upgraded that first pod, with the additional funding, to handle any class of model.

The cooling blocks fit multiple GPU types. We run RTX PRO 6000 as the workhorse node because we tested what actually delivers throughput per dollar, and we can also run B200 and B300. We expect to be among the first providers deploying Vera Rubin GPUs at scale, because when a new generation arrives we update the pod, not the building.

From mid-2025 to now, the work was optimization: getting the PCIe switch, the components, and the interconnects running at the speeds they should. Much like shipping software and then tuning it, except each iteration takes months. Once the pod was fully optimized, we ran our own inference on it.

We built it for ourselves. Then the market ran out of room.

At the start of 2026 the ground moved. Data center capacity started running short, announced large data center projects were cancelled or deferred, and local moratoria on new data center construction began appearing in places that had been building without much friction. Everyone needed somewhere to put GPUs, and the places to put them were getting harder to build, not easier.

We already had the answer, because we had spent three years building it for our own product. So we ramped production.

This is the second time we've done the same thing. We built a real-time inference engine because our image generator needed one, then made it an inference engine anyone could use. We built modular data centers because our inference engine needed somewhere to run, and now we're making them available to everyone else.

That's why we're deploying the first 10,000 nodes, why we have our first 160 locations booked, and why we're currently bringing modular data center capacity online faster than the rest of the world combined. There'll be more news on this shortly.

Why inference on Sonic InferencePods costs less

Every saving traces back to something above.

No facility to amortize. A pod needs ground, power, and connectivity, not a hundred-acre engineered building.
No overhead we don't use. No raised floors, no oversized redundancy tiers, none of the enterprise data center apparatus that general-purpose workloads require and inference doesn't.
No inefficient cooling. Liquid, closed loop, designed for this density instead of adapted to it.
No unnecessary components. No server cases. Custom PDUs. Power supplies bought direct from wholesale vendors. Our servers are built for inference and nothing else, so we don't pay for anything else.
Single tenant facilities. A pod site runs our workloads only, so there is no shared-facility margin to pay. (Serverless capacity is multi-tenant at the software layer; dedicated and bare-metal pods give you a hardware boundary.)
Manufactured, not constructed. Pods are produced and shipped. No permitting queue, no multi-year build, no grid interconnect wait.
Power bought at generation price. In our benchmarking, power is around 30% of the lifetime cost of running a GPU. We put pods at wind farms, solar parks, and near hydro, buying at generation price rather than grid price, with no transmission losses between the generator and the GPU. This is the largest single lever.

At the facilities and deployment layer, our pods cost roughly $150M per gigawatt against about $15B on the traditional path, up to 100x lower, with GPU hardware excluded on both sides. Which comes out, at the level that matters to you, as 30–80% lower cost per GPU-hour than other inference providers, and 50% or more for most workloads. Where a given workload lands in that range depends mostly on the model: its size, how it parallelizes, and how well it fits the node.

Where we can put them

We have 160 locations available to us today: sites with power where we can place containers now. Cooling is redundant. Networking is redundant. Where a site has redundant power we use it; where it doesn't, we can trade that for very cheap power, because pods are built around similar workload profiles and traffic reroutes across the network instead of relying on local redundancy. The blast radius is one pod, not one data center.

Because a pod is a shipping container, it can be deployed inside any national border or jurisdiction. Organizations with data residency or regulatory requirements can run inference on dedicated, locally sited infrastructure without waiting years for in-country construction. We say internally that we're the only provider who could put a data center in the Vatican. If a customer wants one near their office, or on their roof, that's a logistics conversation, not a construction project.

The other reason sites are available to us is that pods don't ask anything of the local utilities. A growing share of data center projects are now blocked or delayed because they can't secure power and water, and because communities object to a facility drawing millions of gallons for cooling. Our cooling loop is closed. Pods need no water mains and consume no water in normal operation, there is no evaporative cooling, and there is no hundred-acre site to clear. They can run entirely on renewable power. Where moratoria on new data center construction are becoming a real constraint on capacity, essentially none of the objections apply to a container sitting on an existing power site.

Deykhan Ten, VP of Strategic Partnerships at Higgsfield, put it better than we would:

"We started with Runware's Model API, but quickly expanded into their inference infrastructure because of the scale and efficiency they could deliver. Our models reach millions of users every week, so reliable capacity and cost-efficient inference are critical. The lower our inference costs, the more value we can pass on to our users. Runware understands that deeply, which is why we work closely with them on our most important model launches."

Capacity beyond our own pods

The pod fleet is the engine, not the ceiling. We manage inference capacity across both our own pods and hyperscaler networks, so when you need more capacity, or need it earlier, or need it in a region where we haven't landed a pod yet, we extend into those networks rather than telling you to wait. Same platform, same contract, same routing layer.

The cost advantage lives in the pods, which is why we keep building them. But no workload should be capped by how fast we can ship containers.

What happens next

Our $50M Series A in December 2025 is what makes the rollout possible. Over H2 2026 we will bring up to 10,000 nodes online across the United States and Europe. We're targeting more than 1GW of inference compute in our pods in 2027, and we'll say more soon about how we plan to get there.

We'll also write in more detail about the engineering: the cooling design, the PCIe switching, the distributed network and routing, and the decisions we'd make differently.

Running your models on Sonic Inference Pods

Capacity is available now through Runware Serverless. Deploy your own models, containers, and AI workloads while we handle provisioning, scaling, and operations. What we commit to is the economics rather than any particular price: we intend to offer the best cost per inference in the industry, and owning the hardware is what lets us keep doing that as the hardware changes.

If you'd rather see the numbers before you commit, we'd prefer that too. We'll benchmark your model as-is on the exact hardware that would serve it, profile it across the GPU options that fit, and work with your engineers on the serving path. You get a clear view of your unit economics before you decide anything. We'd rather show you results on your model than publish numbers from ours.

We're talking to frontier labs, AI studios, enterprises, and organizations with sovereign or data residency requirements.

The goal hasn't changed since the server on the kitchen table. We want inference to cost as close to the price of electricity as it possibly can. Owning the building, and putting the building where the electricity is, is how we get there.

The closed-source LLM premium has collapsed

Ally Nicoll — Mon, 29 Jun 2026 14:36:28 +0000

Originally published on the Runware blog. Written by Ioana Hreninciuc, Co-Founder at Runware.

Open-source models now match closed-model benchmarks at 87% lower cost. Here's what that means for developers choosing between open source inference and OpenAI.

What was your first call to an LLM? Almost definitely, something like this:

import OpenAI from "openai";
const client = new OpenAI();

const response = await client.responses.create({
model: "gpt-5.5",
input: "Write a short bedtime story about a unicorn.",
});

console.log(response.output_text);

The entry point to LLMs is through the frontier. This is where everyone starts, but it’s also where too many stay. They build entire apps, workflows, and harnesses around variations on this call, then wince at their API bill come end-of-month.

That used to make sense when the proprietary models were so dominant. If you want your product to excel, the quality of the underlying model must be high. And high quality has always meant proprietary. So developers ate the cost for excellence.

Does that still hold? Not really. Yes, proprietary is still the frontier, but what was the frontier 18 months ago is now well-mapped territory, and open-source models are closing the gap at a fraction of the cost.

Why? And what should developers make of, and with, these newfound lands of open source?

What kept open source on the bench

We should be clear. Open models aren’t close to taking over from proprietary. There is still a lag in uptake. Open source models are 87% cheaper at equal intelligence but still hold only 25-30% of the token share.

But that gap is no longer about quality. For years, the buying decision was binary: pay proprietary prices, or accept a worse model. Serious teams paid up. That habit is what keeps closed models dominant today, long after the quality gap that justified it closed.

Let’s take GPT-4 as our example. When it launched in 2023, GPT-4 was at $30/M tokens, but it was also the only model that could actually do the work.

(Sources: GPT-4 Technical Report and the Llama2 paper)

Llama 2 wasn’t wildly behind the curve, but it was far enough behind to be a risk for anything production-grade. HumanEval was the rough one: a 37-point gap meant Llama 2 wasn't a real option for anything code-adjacent.

When you extrapolate this to all models, the trend is clear: Closed models are “better”.

Figure 9: Prompt price vs. intelligence for closed- and open-source models. Source: NBER Working Paper 34608.

They are also more expensive. This was the in for OS models, but it came with a catch. Whatever you saved on tokens, you paid back in GPU plumbing. Llama 2 70B at fp16 needed roughly 140GB of VRAM, so two H100s at a minimum, or a more painful quantized setup with its own quality tradeoffs. Add to that the engineering resources to wire together your serving stack, and the costs start to equalize.

But perhaps the biggest reason closed models won was that they weren’t just models. Closed labs shipped a steady drumbeat of product alongside the weights. Function calling, structured output, vision, file uploads, batch processing, fine-tuning, all wired together and versioned.

Here's a timeline of OpenAI releases over 18 months:

Function calling, June 2023
JSON mode, November 2023
Vision (GPT-4V), November 2023
Batch API, April 2024
Structured outputs, August 2024
Prompt caching, October 2024
Realtime API, October 2024

Open source gives you weights. Everything that turns a model into a product, you build yourself.

But if there is one thing AI has taught us, it is that today isn’t tomorrow. A year ago, no one was coding with agents significantly. Now, no one is coding without them. AI is in constant flux, and underneath all this frontier progress, the economics keep drifting. Inference got roughly 10x cheaper per year. The capability lag compressed from 18 months to a few. Then three things hit at once:

Open source started landing on frontier benchmarks.
Frontier labs started raising prices.
Agents broke the simple math.

The performance margin has disappeared

Let's take a look at Kimi.

Moonshot AI shipped Kimi K2 in July 2025, then Kimi K2.5 in February 2026, then Kimi K2.6 in April. The current version is a 1-trillion-parameter MoE with 32B active. The benchmarks land in territory that was Opus-only six months ago.

Kimi K2.6 benchmark comparison vs frontier closed models. Bar heights blend raw scores with within-benchmark contrast. Source: Moonshot AI.

Kimi is leading or keeping pace with top models. It's a model you can download, run on your own hardware, and deploy to production for the same tasks the frontier handles.

And the catch-up isn't unique to Kimi. DeepSeek V4 Pro, GLM-5.1, Qwen 3.6, and Mistral Medium 3.5 all shipped frontier-tier benchmarks in Q1 2026. Why?

Open labs are riding the slipstream. Frontier closed models do the expensive exploration. Open labs distill trajectories, learn from synthetic data, and post-train against patterns the frontier has already proven out. The first model to solve a problem pays the full cost. The second model pays a fraction.
The architecture playbook is now public. MoE routing, long-context tricks, test-time reasoning, agent harnesses. Three years ago, these were lab secrets. Now they're papers, blog posts, and reference implementations on Hugging Face. Once a technique is in the open, the gap to implement it is weeks, not quarters.
Compute is no longer the bottleneck it was. Training a frontier-class model in 2023 took an OpenAI-sized cluster. In 2026, a well-funded lab with a few thousand H100s can ship a competitive model in a single quarter. DeepSeek did it. Moonshot did it. Zhipu did it. The barrier dropped enough that "frontier-class" is no longer a one-company achievement.

The labs that ship these models also depend on a long tail of inference providers ready to host them on day one. Distillation pipelines, benchmark validation, and developer adoption all run through that layer.

There are still gaps. Closed models lead on the hardest reasoning and on the polish that comes from years of RLHF and red-teaming. But the lag is small, and the open labs say so themselves. DeepSeek themselves put their own V4 models 3 to 6 months behind the state-of-the-art frontier, beating last generation's flagships while trailing the current ones. For most production work, a few months of lag on the hardest problems doesn't change the decision.

Tokens are going to zero

Proprietary pricing is messy right now, and getting messier. The frontier labs don't really know where to set prices, and the last six months have been them figuring it out in public.

The trigger is agentic usage. A chat call burns a few hundred tokens. An agent can easily burn through millions. Claude Code Max users were extracting around $5,000 in usage from $200 monthly plans. Even subsidized, flat-rate subscriptions don't survive a delta like that.

How is pricing shaking out? Users are seeing:

Explicit hikes. GPT-5.5 launched at roughly 2x the per-token cost of its predecessor.
Stealth hikes. Opus 4.7 kept the same sticker price, but its new tokenizer generates up to 35% more tokens for the same prompts. Same rate, higher bill.
Access changes. Codex shifted to per-token billing. Anthropic cut off OpenClaw from Claude subscriptions. Google added spend caps on the Gemini API.

The goodwill built through the “product” model above is undone bit by bit every time a developer suddenly finds their access locked or their limits hit. Meanwhile, the floor under open-source pricing continues to drop. MiniMax M2.7 on Runware runs at $0.30/$1.20 per million input/output tokens. For comparison, Opus 4.7 is $5/$25, and GPT-5.5 is $5/$30. Agents are output-heavy, and output is where the gap is widest. A non-trivial coding task can easily run through hundreds of thousands of output tokens. At GPT-5.5 ($30/M out), each task costs several dollars. At M2.7 ($1.20/M out), it's pennies.

Per-token billing is the right model for agentic workloads, and the labs know it. Done right, it means paying for the seconds of inference you actually run, no minimums, no commitments, no rounding up. The frontier labs aren't there yet.

But their customer base anchored on "flat rate, unlimited," and they can't walk that back cleanly. So they're raising prices without raising prices, restricting access without restricting access, and hoping no one tallies the cumulative effect.

Harnesses are becoming more important than models

Lock-in to a single model is dissipating. Agents must route across models and modalities for any task at hand.

This is a fundamental premise of Runware. We are a single destination for 400k+ models across modalities, making model choice a simple config decision. This needs to happen for two reasons.

First, frontier agents can use multiple models to perform tasks.

Claude Code uses a main model to do the heavy lifting, a small model handles cheap background jobs like the one-line summaries of your sessions, and a separate model answers the side-questions feature so a quick question mid-task doesn't interrupt the main model.
A message to ChatGPT doesn't hit one model. A small router reads the request first and decides where it goes: a quick factual question to the fast model, a hard reasoning or coding task to the deeper one. The router doesn't reason or generate anything itself. It dispatches. Easy work goes to the cheap model, hard work to the expensive one, so you stop paying frontier rates for trivial requests.

The dispatcher can be cheap and route to expensive models to do the work. Once model choice is just a configuration, you can build the same thing on open source, with one addition the closed products don't offer: you can pick models by what they're good at, not just by size.

Reasoning and planning. Breaking a request into steps and deciding when it's done wants the strongest reasoning available. That can now be an open-source model like DeepSeek V4 or Kimi K2.6, both within a few months of the closed frontier.
Code generation. Turning a clear spec into a working file suits a coding-tuned model. Something in the Qwen family handles it at a fraction of the reasoning model's cost.
The conversational layer. Whatever the end user talks to benefits from a more conversational model, such as Gemma.

This works much better for cost. A chat turn that lands on a conversational model never pays frontier rates, and neither does a code generation step that lands on a coding model. As long as each model is capable at its own job, your effective per-request cost is one small-to-medium model, well below a single large model doing every job itself.

Which brings us to the second reason: workflows necessitate multimodality. Most useful agents touch more than text. Say you're building an agent that turns a written product brief into a 60-second launch video. The pipeline hits:

A text model for the script.
A TTS model for the voiceover.
An image model for background visuals.
A video model for b-roll.
A text model again for captions.

Without a unified API, the agent is wired into five separate services, each with its own SDK, auth flow, rate limit, billing pipeline, and error semantics. That's a layer of integration your team writes once and maintains forever. A unified API across modalities removes that layer.

The long-term shape of this is agents deciding which models to use for their task lists in an LLM market economy. The developer writes the initial spec. After that, the agent shops the spread across providers in real time. Model capability becomes a commodity.

Open source will build better infrastructure

Once the model question is settled, the next question is latency and placement.

Agents amplify latency in a way that chat never did. A user opening a support chat notices 500ms once. With an agent making 50 sequential calls to plan, route, and execute, that 500ms compounds into a 25-second delay the user actually waits through. Multiply by the cold-start, retrieval, and tool-call hops in a real agent loop, and round-trip latency starts to dominate the user experience.

Vertical integration will be the answer to bringing costs down while increasing speed. Owning the boards, servers, and orchestration end-to-end beats commodity GPU clouds on utilization, which is where most of the cost actually sits. A custom inference stack on hardware you control gives you headroom on both axes:

Lower marginal cost per token. On-demand hyperscaler H100 rental costs about $7/hour, while buying chips and running them directly puts the equivalent rate at about $1.60 for Runware. Idle capacity from one workload also becomes usable seconds for another, rather than sitting paid for and empty.
Lower latency on the calls that matter. Pods placed close to traffic beat hyperscaler regions on round-trip time. Tuning the stack purely for inference (high-frequency CPUs, disabled hyperthreading, custom PCIe topology) also yields more performance per chip. That compound effect carries through every step in an agent loop.

Frontier labs are heading the other way. To make the compute economics work at their scale, they sign multi-year deals with the hyperscalers: OpenAI on Azure, Anthropic on AWS and GCP. That locks them into the datacenter model for years. The upstream is volatile enough that Architect have launched compute futures on H100 and H200 prices. The input to every hyperscaler API endpoint is now a hedged commodity.

Modular compute is what unlocks the alternative. A pod in a shipping container, dropped near the traffic, routes around the 2-to-4-year wait for new AI data center capacity. A pod with power, cooling, and an uplink is enough. The placement decision drops from quarters to weeks. For scale: xAI's 300 MW Colossus build took four months and depended on rented power generators and a large share of the mobile cooling capacity available in the US. A factory shipping containerized inference pods can deploy equivalent compute in days, with everything owned and water-cooled in place.

The regulatory case is the second tailwind. Multiple frameworks push in the same direction:

GDPR and the EU AI Act: inference inside European borders, with auditable controls.
FedRAMP and CMMC: US federal and defense workloads, with explicit hardware security postures.

The answer that satisfies all of these is a regional pod running open-source models you can audit. A US hyperscaler endpoint serving Frankfurt traffic is not the answer, no matter how good the model is.

Today is closed; tomorrow is open

Open-source models are now good enough for most production work, and frontier closed models are repricing to cover their actual costs.

The frontier will still be there. Closed labs will keep pushing the leading edge, and there will keep being workloads where that edge is worth paying for. But the share of work that needs the frontier is shrinking, and the share that runs well on an open-source model with the right infrastructure is growing.

The meaningful decision has moved up the stack. The platforms that win the next phase will be the ones that put open source first, expose every modality behind a single API, charge for the inference you actually run, and operate on hardware designed entirely for this purpose and placed close to where you serve traffic from.

The model is becoming the easy part. The stack underneath it is where the next few years of competitive advantage live.

Where to start

Runware is building exactly this. One API spans every leading open and closed LLM alongside image, video, audio, and 3D, billed per token with no subscriptions. Open-source models run on our own hardware at up to 80% lower cost, and you pick each model by what it does best.

See it in full on the LLM API page, with live pricing and the open-versus-closed comparison drawn from current benchmarks. When you are ready, get an API key and run your first open-source model in minutes. For committed-use rates and dedicated capacity, talk to us.

Your Agents Can Now Use Runware

Ally Nicoll — Fri, 26 Jun 2026 15:26:58 +0000

TL;DR: Runware now provides two new entry points into the Runware environment; an MCP server for AI agents, and a CLI for the terminal. Both get you to a working first generation faster than integrating directly, and both reach the same catalog: every major model provider plus thousands of community models, across image, video, audio, 3D, and LLMs, accessible through one interface.

The MCP server: Runware inside your agent

MCP (Model Context Protocol) is an open standard that lets AI agents talk to external services through a defined set of tools. If you're using Claude, Cursor, Codex, VS Code, or any other MCP-compatible client, connecting to the Runware MCP server gives your preferred agent the ability to generate media, search the model catalog, and check pricing without you leaving the session, or writing any integration code.

There are two ways to connect:

Hosted - point your client at https://mcp.runware.ai, paste your Runware API key when prompted, and you're connected. The key is stored server-side, encrypted inside the OAuth session, so your client only ever holds a token, never the key itself.

Local - for agents that can't reach external MCP servers, or restricted and air-gapped networks, you can run the MCP server on a local machine instead:

npx @runware/mcp

Set RUNWARE_API_KEY in your environment and point your client at the local server. The toolset is identical to the hosted version, it just runs on your machine and connects differently.

Either way, your agent gains a set of tools it can call directly.

The MCP Toolbox

Once connected, your agent gains access to a broad set of Runware tools.

The run tool is the core one. It handles image generation, video generation, audio, 3D, LLMs, upscaling, background removal, everything the Runware API supports, through your agent interface. You don't need to tell the agent which task type to use or look up model parameter schemas. You describe what you want, and if you know you want a specific model you can name it; otherwise the agent figures out the best fit for your use case using the catalog tools.

Those catalog tools (list_models, model_details, model_pricing, model_examples) are what give the agent the ability to search and reason about the available models before committing to a generation. This is genuinely useful in various ways; you could ask something like "what does each Veo model cost for an 8-second 1080p clip?" and the agent will use the list_models and model_pricing tools to look up the options and compile a comparison - displayed directly in your agent application.

On pricing: There’s no MCP surcharge. If a generation costs $0.05, you pay $0.05. The browsing and inspection tools are free.

A Practical Example

You're building a product page in a Claude Code session and you need a hero image in a specific aspect ratio. Normally you'd stop, open a separate generation tool, come up with a prompt, iterate on it, download the result, and bring it back to your workspace.

With the Runware MCP integrated into Claude, you can simply ask:

I need a 16:9 banner image for our product page, use Runware, generate two examples for me, one with Nano Banana 2, one with GPT Images 2.0

This example highlights a number of core capabilities;

One of the requested model names wasn’t found in the Runware model catalogue, so the MCP model search tool was employed by the agent to locate it.
One of the generation requests returned an error and was automatically retried.
The agent used the ToolSearch capability to look up the correct schema for the model, identifying acceptable dimensions to solve the issue.

With two sample images generated, Claude Code then offers to wire one into the project, adding it to the repository, all from within the coding agent app - no context-switching required.

The CLI: Runware from your terminal

The CLI is a separate tool, a native runware binary that you install on your machine. It's built for working directly without an agent in the loop: generating from the terminal, scripting, testing models, and dropping generation into automated pipelines. The CLI is fully open source and released under the MIT License, so you can inspect the source, build it yourself, and review exactly what you're installing. The source code is available on the Runware GitHub: https://github.com/Runware/runware-cli/tree/main

The core command is runware run:

runware run runware:101@1 positivePrompt="a chess match in the park" width=1024 height=1024

Results download automatically to an ./outputs folder.

The same run command works for video, audio, 3D, and text inference, just swap the model identifier. The CLI fetches the model's schema automatically and validates your parameters before the job runs, so you find out about mistakes before any spend.

Beyond generation, the CLI can search the model catalog, check pricing, inspect a model's full parameter schema, and manage presets for configurations you run often. Output supports --format json for piping into other tools or scripts, making it practical for automation.

Search models

runware model search -q "flux"

Check a model's parameters before running

runware model schema runware:101@1 --format json

Check your account and usage across your API keys

runware account details --format JSON

Like the MCP Server, browsing and inspection calls via the CLI are free. There’s no additional fee to access Runware’s services via CLI.

CLI or MCP: which one do you need?

The MCP server is the right choice when you're already working inside an agent. You describe what you want, the agent handles the tool calls, and generation happens inside the conversation. It's particularly useful when you want the agent to figure out model selection, chain calls across modalities, or work media generation into a bigger task.

The CLI is the right choice when you want to work directly, without an agent. Unlike the MCP, it isn't conversational; you need to know which command to run and what parameters to pass, rather than describing what you want in plain language. That's a reasonable tradeoff when the task is well-defined: scripting a batch job, running generations in CI/CD, or just generating something quickly from a terminal window without spinning up an agent session.

Getting started

Hosted MCP (Claude, Cursor, VS Code, and most other clients):

Add https://mcp.runware.ai as a custom MCP server in your client's settings and complete the OAuth flow when prompted. You'll paste your Runware API key into a Runware-branded page - that's the only time your API key is ever visible.

Local MCP server:

npx @runware/mcp

Set RUNWARE_API_KEY in your environment and point your client at the local server.

The landing page with per-client MCP setup information is at runware.ai/mcp.

CLI:

macOS:

brew tap runware/tap brew install runware

Windows (via Scoop):

scoop bucket add runware https://github.com/Runware/scoop-bucket.git scoop install runware

Linux:

curl -fsSL https://cli.runware.ai/install.sh | sh

Then authenticate on any platform with your API key:

runware auth login

Once authenticated, run runware ping to confirm connectivity, and you're ready.

Full CLI reference at github.com/Runware/runware-cli.

The landing page with per-client CLI setup information is at runware.ai/cli.

FAQ

What's the difference between the MCP and the CLI?
The MCP is conversational; you describe what you want and the agent handles the model selection, parameters, and tool calls. The CLI is direct; you write the commands yourself, which makes it better suited to scripting, automation, and situations where you don't want an agent in the loop. Both provide access to the same tools and models.

What platforms does the CLI support?
macOS, Windows, and Linux. macOS via Homebrew, Windows via Scoop, Linux via a shell installer.

Can I build from source?
Yes. Clone the repo and run make build. The full steps are in the docs.

Do I need a Runware account to use either?
Yes, both require a free Runware API key. You can create an account and generate an API key at runware.ai

Can I use both CLI and MCP?
Yes. They can share the same API key, linking to the same account balance, and the same model catalog, or be set up with different keys, depending on your needs. Use the MCP when you're working with an agent, and the CLI when you're in a terminal or a script.

WebSocket or REST?
It's WebSocket by default, but you can switch with --transport http.

We Hosted OpenClaw So You Don't Have To

Ally Nicoll — Thu, 11 Jun 2026 13:04:53 +0000

TLDR: we just launched free OpenClaw hosting. One-click deploy, no infrastructure to manage, only pay for the AI tokens your agent uses.

Free Hosted OpenClaw for Everyone
What Is OpenClaw?
How Provisioning Works
What You're Actually Running
Model Switching Without Redeployment
Pricing Model
Current Limitations
FAQ

Free Hosted OpenClaw for Everyone

Self-hosting OpenClaw is certainly doable (if anything, a bit of a faff).

The community guide walks you through provisioning a VPS or setting up Docker, creating SSH keys, connecting to the server, installing Node.js and dependencies, installing OpenClaw itself, configuring it, setting up TLS certificates, adding a TLS renewal cron job, connecting an LLM provider, and pairing a messaging channel. The guide even has time estimates for each step. The total is about 80 minutes before your first message goes through, and that assumes you're familiar with all the aforementioned tech, and nothing breaks along the way. After that, ongoing updates, monitoring, and troubleshooting are all yours.

That might be reasonable if you need full control over your infrastructure. If you don't, it's a lot of overhead for something that should just work.

We've built a free hosted version of OpenClaw on Runware to take the stress out of the whole process. This post covers how the setup works, what the infrastructure looks like, and where the current limits are.

What Is OpenClaw?

OpenClaw 🦞 is an open-source framework for running AI agents. The key word is agent: it doesn't just answer questions, it actually does things. Clear your inbox, send emails, manage your calendar, check you in for flights, browse the web, run shell commands, control your browser, write and execute code, the possibilities are endless.

You connect it to channels such as WhatsApp, Telegram, Discord, Slack, Signal, iMessage, or similar, and from that point on you interact with it the same way you'd message anyone else. It has persistent memory, supports community-built skills, and can write new skills for itself.

It's incredibly useful and has exploded in popularity since launch. We believe everyone should be able to get in on the action, without the stress of a self-hosted deployment.

How Provisioning Works

On Runware, when you click "Deploy OpenClaw" from the OpenClaw dashboard, the platform spins up a container for OpenClaw, in an isolated secure environment. This takes about three minutes.

The part that usually causes friction in a manual setup is connecting your LLM provider. You'd normally generate an API key from your provider, copy it, SSH into your server, and paste it into a config file. With the hosted version, that step is removed entirely. Runware generates an API key tied to your Runware account and pulls it directly into your OpenClaw instance. By the time the container is live, inference is already wired up. You don't see a key, you don't have to paste anything, and there's no config file to edit.

From there you open OpenClaw's Control UI, pick a model, connect a messaging channel, and you're running.

What We're Actually Running

The hosted container we're deploying is the same OpenClaw you'd run yourself, deployed into a isolated environment on our infrastructure. Updates to the container and underlying infrastructure are handled automatically.

Channels are configured through the Control UI after deployment. Supported channels include WhatsApp, Telegram, Discord, Slack, Signal, Google Chat, iMessage, and Nostr.

Model Switching Without Redeployment

Because inference routes through our hardware, you can switch between models without redeploying anything - it's as simple as selecting a new model.

We're offering the full Runware LLM catalogue, including both open-source and closed-source models, including

GLM-5.1 & GLM-4.7
Qwen3.5-397B & Qwen3.5-27B
Kimi K2.6
MiniMax M2.7, MiniMax M2.7 Highspeed & MiniMax M2.5
DeepSeek V4 Flash
Claude Opus 4.7, Claude Sonnet 4.6 & Claude Haiku 4.5
GPT-5.5, GPT-5.4, GPT-5.4 Mini & GPT-5.4 Nano
Gemini 3.1 Pro, Gemini 3.1 Flash Lite, & Gemini 3 Flash.
Grok 4.3

New models added to the Runware model catalogue will show up for use, automatically.

Pricing

Hosting OpenClaw on Runware is entirely free. Compute, storage, networking, the container, updates, and security are all included at no charge. There's no subscription, no monthly minimum spend, and no per-instance fee. All you need is credit in your Runware account to cover LLM usage.

Model inference is billed at our market leading rates; you're only charged for LLM token usage - a fully pay-as-you-go model. New accounts with a business email get $2 in free credit to start with.

Current Limitations

This system is in beta, and there's a few things to know before you start building;

Each Runware account is currently limited to one instance. If you need multiple agents running in parallel, the self-hosted path is the better option for now.

We're monitoring performance and listening to community feedback as the service matures. If you run into issues, or want to share what you've built, we'd love to hear from you in the Runware Discord.

Get started

Happy to answer questions in the comments about anything that's unclear, and we'd love your suggestions and input!

You can also join the conversation and stay up to date with the latest news in the Runware Community Discord

FAQ

How fast can I deploy OpenClaw?
The provisioning itself takes about three minutes. From clicking deploy to having a working agent is under five minutes total, and most of that is the sign-up flow. There's no configuration to fill in and nothing to install locally.

Is hosting really free?
Yes. Compute, storage, the container, networking, updates, and security are all included at zero charge. The way Runware's model works is that you pay for the AI inference your agent generates, not for the infrastructure running it. If your agent is live but never calls a model, you pay nothing.

How does pricing work?
The only thing you pay for is the AI tokens your agent uses. Open-source models are billed at Runware's published rates. There's no monthly subscription and no per-instance charge on top of that.

What models does OpenClaw support on Runware?
Every model in the Runware catalogue is available, and you switch between them from inside OpenClaw without redeploying. That covers open-source models like Qwen, GLM, Kimi, MiniMax, and DeepSeek running on Runware's own infrastructure, and closed-source frontier models including Claude, GPT-5, Gemini, and Grok. New models are added to your instance automatically as they're added to the catalogue.

How do updates work?
We handle updates to the OpenClaw container and the underlying infrastructure automatically.

Is my instance isolated?
Yes. Each OpenClaw instance runs in its own secure environment inside an isolated container. There's no shared state with other customers' instances.

What happens if I outgrow the hosted tier?
OpenClaw is open source, so you can move to a self-hosted setup at any point. Nothing about the hosted setup locks you into any ongoing contract.

What happens if I don't use my instance for a while?
If an instance is unused for 5 days it's temporarily suspended to free up capacity. You won't lose any data. Just log back into the Runware dashboard and redeploy, it takes a couple of minutes to reinitialize, then you continue as normal.

DEV Community: Runware

Introducing Style LoRA Training on Runware

What is a LoRA?

LoRA vs reference images: which do I need?

How could a LoRA be useful to me?

Locking in your brand's visual identity

How does it work?

What does training cost?

Continue training instead of starting over

How do I prepare a dataset?

Captioning

Dataset requirements

What's next

Get started

FAQ

How many dataset images do I need?

Do I own the trained LoRA?

Can I use it for inference immediately after training?

Do captions improve results?

Can I tweak the training settings?

Which models are available for LoRA training?

Can I continue training an existing LoRA instead of starting over?

Training glossary

Introducing Sonic Inference Pods: Modular data centers built for inference

We do inference. We don't sell data center space.

2022: a product that couldn't afford to exist

The GPUs we rented were not the same as each other

Summer 2023: three servers on a kitchen table

The pivot we didn't want

2024: nobody would take our servers

What we built, and why each part is the shape it is

Servers with no cases

Our own PCIe switch

Local NVMe, so models stay warm

Cooling nobody would sell us

A shipping container, and a crane

Any GPU, including the next one

We built it for ourselves. Then the market ran out of room.

Why inference on Sonic InferencePods costs less

Where we can put them

Capacity beyond our own pods

What happens next

Running your models on Sonic Inference Pods

The closed-source LLM premium has collapsed

What kept open source on the bench

The performance margin has disappeared

Tokens are going to zero

Harnesses are becoming more important than models

Open source will build better infrastructure

Today is closed; tomorrow is open

Where to start

Your Agents Can Now Use Runware

The MCP server: Runware inside your agent

The MCP Toolbox

A Practical Example

The CLI: Runware from your terminal

Search models

Check a model's parameters before running

Check your account and usage across your API keys

CLI or MCP: which one do you need?

Getting started

Hosted MCP (Claude, Cursor, VS Code, and most other clients):

Local MCP server:

CLI:

FAQ

We Hosted OpenClaw So You Don't Have To

Table of Contents

Free Hosted OpenClaw for Everyone

What Is OpenClaw?

How Provisioning Works

What We're Actually Running

Model Switching Without Redeployment

Pricing

Current Limitations

Get started

FAQ