DEV Community: RouterBase

Three AI Video Inputs, One Integration Boundary: Shipping MiniMax H3 on RouterBase

RouterBase — Mon, 03 Aug 2026 10:33:39 +0000

MiniMax H3 is now available on RouterBase through three video-generation routes: text-to-video, image-to-video, and reference-to-video.

Those labels sound like three separate products. From an application architecture perspective, they are better treated as three input contracts around the same asynchronous job lifecycle.

The lifecycle is familiar:

Submit a generation job.
Store the returned task identifier.
Poll until the task reaches a terminal state.
Retrieve the completed video URL.
Copy the asset into storage you control if the result needs to remain available.

What changes is the context you send at step one.

Use text-to-video when the scene can be described from scratch. It is the cleanest route for exploration, storyboard alternatives, and prompts where no existing visual identity needs to survive.

Use image-to-video when you already have the opening visual. The source image becomes the anchor, while the prompt should describe motion, camera behavior, and what must remain unchanged.

Use reference-to-video when the input is guidance rather than the literal first frame. This is the better fit for a subject, product, or visual style that should influence the generated clip.

On RouterBase, the currently published MiniMax H3 routes support 2K output and 6- or 10-second clips. That is a narrower product contract than every capability described in MiniMax’s own H3 documentation, so production code should follow the RouterBase route you are actually calling—not assume that every upstream option is already exposed.

A useful abstraction is to keep your queue, polling, timeout, retry, storage, and audit logic independent from the selected input mode. Then changing from a prompt to a source image is a request-shape decision, not a second integration project.

Explore the live routes

Text-to-video: https://routerbase.com/models/minimax/minimax-h3/text-to-video
Image-to-video: https://routerbase.com/models/minimax/minimax-h3/image-to-video
Reference-to-video: https://routerbase.com/models/minimax/minimax-h3/reference-to-video

The practical question is no longer only “Which video model should we call?” It is also “What context do we already have, and what role should that context play?”

Build a Human Approval Gate for Agent Tool Calls in JavaScript

RouterBase — Thu, 23 Jul 2026 03:25:06 +0000

An agent should not treat every available tool as permission to execute it.

A production-friendly tool layer needs at least three outcomes:

allow: safe to execute automatically
review: pause and ask a person
deny: reject the call

Here is a small, dependency-free gate you can run with Node.js.

Prerequisites

Node.js 18 or later
No external packages

Save the following as approval-gate.mjs:

const policy = {
  searchDocs: { risk: "low", required: ["query"] },
  updateCustomer: { risk: "medium", required: ["customerId", "patch"] },
  issueRefund: { risk: "high", required: ["paymentId", "amount"] },
};

function decideToolCall(call) {
  const rule = policy[call.name];
  if (!rule) return { decision: "deny", reason: "Unknown tool" };

  const missing = rule.required.filter(
    (key) => call.arguments[key] == null,
  );
  if (missing.length) {
    return {
      decision: "deny",
      reason: `Missing: ${missing.join(", ")}`,
    };
  }

  if (rule.risk === "low") return { decision: "allow" };

  return {
    decision: "review",
    reason: `${rule.risk}-risk action requires human approval`,
    approvalKey: call.id,
  };
}

const calls = [
  {
    id: "call_1",
    name: "searchDocs",
    arguments: { query: "refund policy" },
  },
  {
    id: "call_2",
    name: "issueRefund",
    arguments: { paymentId: "p_123", amount: 49 },
  },
  {
    id: "call_3",
    name: "deleteWorkspace",
    arguments: { workspaceId: "w_1" },
  },
];

console.table(
  calls.map((call) => ({ tool: call.name, ...decideToolCall(call) })),
);

Run it:

node approval-gate.mjs

Expected decisions:

```plain text
searchDocs allow
issueRefund review
deleteWorkspace deny




## Why this pattern helps

### 1. Unknown tools fail closed

If a model invents a tool name or reaches a tool that was not registered for this workflow, the gate returns `deny`. It never assumes that an unknown action is harmless.

### 2. Arguments are checked before execution

The example only checks required fields. In production, validate types, ranges, identifiers, and object shapes with a schema library before any side effect.

### 3. Risk changes the execution path

Low-risk reads can continue. Medium- and high-risk actions return `review` with a stable `approvalKey`. A UI or queue can use that identifier to collect a human decision.

## What to add before production

This example is intentionally small. A real approval service should also include:

- An immutable audit log
- An approval expiry time
- The exact tool arguments shown to the reviewer
- Idempotency protection
- The reviewer identity and decision reason
- A fresh authorization check when execution resumes
- Tests for policy changes and previously observed failures

Do not execute the original call just because an approval record exists. Verify that the approval matches the same tool, arguments, user, and current policy version.

OpenAI’s Presence announcement describes the same broader production problem: companies need to define allowed actions, approval points, evaluations, escalation rules, and controlled changes after launch.

If your agent also needs one OpenAI-compatible API for models across providers, RouterBase is available at [https://routerbase.com](https://routerbase.com).

Measure Prompt Cache Usage with an OpenAI-Compatible Python Client

RouterBase — Wed, 22 Jul 2026 11:24:15 +0000

Prompt caching is easy to describe and easy to measure incorrectly.

A second request is not automatically proof of a cache hit. The model, provider, prompt length, request shape, and cache lifetime can all affect the result. The safest workflow is to send a controlled pair of requests and inspect the complete usage object returned by the API.

This tutorial uses RouterBase’s OpenAI-compatible chat completions endpoint.

Prerequisites

Python 3.10+
The current openai Python package
A RouterBase API key
A model ID copied from the live catalog at GET https://routerbase.com/v1/models

Store both values as environment variables:

export ROUTERBASE_API_KEY="sk-rb-..."
export ROUTERBASE_MODEL="your-current-model-id"

Do not hard-code production credentials in source code.

Install the SDK

pip install openai

Send two controlled requests

import json
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ROUTERBASE_API_KEY"],
    base_url="https://routerbase.com/v1",
)

model = os.environ["ROUTERBASE_MODEL"]

shared_context = """
You are reviewing an API operations handbook.
Focus on error classification, tenant isolation, and observability.
Return one concise engineering recommendation.
""" * 80

def run(label: str) -> None:
    response = client.chat.completions.create(
        model=model,
        user="prompt-cache-observability-demo",
        messages=[
            {"role": "system", "content": shared_context},
            {"role": "user", "content": "What should the team log for each request?"},
        ],
    )

    usage = response.usage.model_dump() if response.usage else {}
    print(f"\n{label}")
    print(json.dumps(usage, indent=2))

run("first request")
run("second request")

The repeated system content and stable user value make the pair easier to compare. They do not guarantee that the second request will be cached.

What to inspect

Look for the cache-related fields exposed in the response usage, including cached_tokens where available. RouterBase’s current documentation also describes provider-native cache read and cache creation fields.

Compare them with:

total input tokens
model ID
request latency
task success
cost per successful task

If the cache field is missing or zero, keep the result. It is evidence, not an error to hide. Recheck the current model, provider behavior, prompt shape, and documentation before drawing a conclusion.

Production notes

Use a stable end-user identifier so cache isolation matches your tenancy model. Never reuse one user identifier across unrelated customers merely to chase a higher hit rate.

Also avoid measuring only one request pair. A useful production view groups cache usage by model, prompt family, tenant, and task outcome over time.

Source of truth

RouterBase documents cache behavior and response fields here:

https://docs.routerbase.com/api-reference/chat-completions.md

For current model IDs, use the live catalog:

https://routerbase.com/v1/models

RouterBase: https://routerbase.com/?utm_source=devto&utm_medium=article&utm_campaign=prompt_cache_observability

Call GLM-5.2 from the OpenAI Python SDK with RouterBase

RouterBase — Mon, 20 Jul 2026 08:30:30 +0000

Correction (July 22, 2026): The current RouterBase model ID is zai/glm-5.2. An earlier version of this article used an incorrect ID.

GLM-5.2 is live on RouterBase. If you already use the OpenAI Python SDK, you do not need another client library. Keep the SDK, change the base URL, and use the exact live model ID.

Prerequisites

Python 3.9 or later
A RouterBase API key stored as ROUTERBASE_API_KEY
The current openai package

pip install openai

Make the call

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ROUTERBASE_API_KEY"],
    base_url="https://routerbase.com/v1",
)

response = client.chat.completions.create(
    model="zai/glm-5.2",
    messages=[
        {
            "role": "system",
            "content": "You are a careful software engineering assistant.",
        },
        {
            "role": "user",
            "content": "Give me a five-point review checklist for a risky database migration.",
        },
    ],
    max_tokens=800,
)

print(response.choices[0].message.content)

The two RouterBase-specific values are:

base_url = https://routerbase.com/v1
model = zai/glm-5.2

Do not shorten the model name to glm-5.2. RouterBase's live catalog and current docs expose the full ID zai/glm-5.2, and exact IDs prevent an integration from silently pointing at the wrong route.

Before sending a million-token prompt

Z.ai documents a 1M-token context window for GLM-5.2. That is a ceiling, not a recommended starting prompt.

Start with a smaller baseline, then increase context while recording:

Time to first token and total wall-clock time.
Whether the answer uses the right evidence from the prompt.
Tool-call failures and retry behavior.
Whether tool state survives a long, multi-step run.
Cost per successful task, not only cost per token.

A longer context window reduces some chunking pressure, but it does not replace retrieval tests, observability, or a fallback path.

Scope and limitations

This quickstart verifies the current RouterBase base URL and model ID. It does not claim a benchmark ranking, a latency target, or a fixed price. Those values can change, so check the live catalog and current docs before a production rollout.

Switch AI Models Without Rewriting Your OpenAI SDK Integration

RouterBase — Thu, 16 Jul 2026 02:17:58 +0000

If your application already uses the OpenAI Python SDK, you can keep the same client and point it at RouterBase by changing the base URL.

This gives the application one request interface while model selection stays configurable.

Prerequisites

Python 3.9 or newer
The current openai package
A RouterBase API key stored in an environment variable

Install the SDK:

pip install --upgrade openai

Set the key in your shell:

export ROUTERBASE_API_KEY="sk-rb-..."

Do not place an API key in browser code, mobile binaries, or a public repository.

Create the client

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ROUTERBASE_API_KEY"],
    base_url="https://routerbase.com/v1",
)

The important line is base_url. The SDK remains the same; requests go through the RouterBase OpenAI-compatible endpoint.

Make a chat request

Choose a model ID from the current RouterBase model catalog and keep it in configuration instead of hard-coding it throughout the application.

import os

model_id = os.environ.get(
    "ROUTERBASE_MODEL",
    "google/gemini-2.5-flash",
)

response = client.chat.completions.create(
    model=model_id,
    messages=[
        {
            "role": "user",
            "content": "Explain idempotency in one paragraph.",
        }
    ],
)

print(response.choices[0].message.content)

To test a different compatible chat model, change ROUTERBASE_MODEL and run the same request again.

Add a small evaluation before switching

A successful API response is not enough to justify moving production traffic. Test candidate models against the same tasks and rubric.

candidates = [
    "google/gemini-2.5-flash",
    # Add other current RouterBase chat model IDs here.
]

prompt = "Return a JSON object with keys: summary and risk."

for candidate in candidates:
    result = client.chat.completions.create(
        model=candidate,
        messages=[{"role": "user", "content": prompt}],
    )
    print(candidate, result.choices[0].message.content)

In a real evaluation, record correctness, latency, retry rate, and the cost of a successful task.

Important caveats

An OpenAI-compatible endpoint does not mean every model has identical behavior.

Before switching models, verify:

tool and function calling behavior;
structured output requirements;
supported input modalities;
context and output limits;
streaming behavior;
model-specific parameters.

Keep the integration stable, but keep the evaluation model-specific. For a concise companion overview, see this practical OpenAI-compatible multi-model setup.

RouterBase provides one OpenAI-compatible API for GPT, Claude, Gemini, and 200+ AI models. Check the live catalog before using a model ID in production.

One OpenAI-compatible endpoint for 200+ AI models

RouterBase — Tue, 02 Jun 2026 11:47:11 +0000

If you build with multiple LLM providers, you've probably written a separate integration for each one — OpenAI, Anthropic, Google, Meta. Different SDKs, different auth, different billing.

RouterBase is an AI API gateway that collapses this into a single OpenAI-compatible endpoint. You connect once and route requests to 200+ models across providers. Switching models is a string change, not a code rewrite.

What it does

One endpoint, 200+ models — chat, reasoning, vision, embeddings
Drop-in OpenAI compatibility — point your existing client at a new base URL
Smart routing — pick a provider by price, latency, or availability, with automatic fallback
Unified usage tracking — one dashboard and one bill across every provider

There's a free tier with usage-based pricing, so cost scales with what you actually use.

Docs and signup: https://routerbase.com