DEV Community: Ally Nicoll

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.