NewAPI on Margrop Blog

Stop Sprinkling API Keys Everywhere: My Self-Hosted NewAPI Relay Station

Fri, 10 Jul 2026 15:30:00 +0800

TL;DR

NewAPI is not a free-model trick and it is not a mysterious proxy. In my setup, it is the front desk for AI usage: every app talks to one endpoint, while the gateway routes requests to authorized upstream providers and handles tokens, quotas, groups, model limits, logs, and usage accounting. For a personal deployment, the big win is not “one more dashboard”; it is no longer scattering upstream keys across every client, script, and agent.

This post explains why I wanted a self-hosted model relay, what people usually misunderstand, how to deploy a minimal Docker Compose version, why I add persistent storage, and how to use one-click scripts for Windows 11, Ubuntu 26.04, and macOS 26. It also includes an agent-driven setup prompt with strict boundaries. No private address, complete machine name, private domain, or real secret is included.

One Missing operator.write Took Down the Gateway: The OpenClaw Fallback Failure That Wasn't a Model Problem

Fri, 10 Jul 2026 08:00:00 +0800

This incident looked like a model-provider outage at first. OpenClaw had just received three NewAPI-backed fallback models, but gateway-based model calls started failing with a provider authentication error. After peeling back the outer message, the real error was much more specific:

missing scope: operator.write

That string changed the direction of the investigation. The provider key was not the root problem. The NewAPI endpoint was not the root problem. The model names were not the root problem either. The failure lived inside OpenClaw’s gateway authorization path: when a model override was used, the gateway call switched into a backend/gateway-client mode, but did not force the request to use the already paired stored device identity. The device had operator.write; the request simply did not carry the identity that could prove it.

The shortest version is this: the badge existed, but this entrance did not scan it.

Stop Letting Agents Burn Tokens: Wiring Headroom into NewAPI, OpenClaw, and HermesAgent

Sat, 20 Jun 2026 12:30:00 +0800

TL;DR

I did not replace NewAPI, and I did not point OpenClaw or HermesAgent at an unproven gateway. The actual design is simpler: place Headroom in front of NewAPI, then move only the already validated OpenAI-compatible providers to http://<headroom-host>:8787/v1. The original NewAPI endpoint stays available. Long agent context now goes through Headroom first, gets compressed, then continues to NewAPI for the same routing and model management as before.

The rule that kept the rollout boring was: test first, edit second; migrate only OpenAI-compatible providers that pass; leave non-OpenAI fallbacks alone. This post is both a write-up and a runbook you can hand to an Agent or follow manually.

Double-Consumed Streaming: Debugging a NewAPI v1.0.0-rc.10 MiniMax Proxy Bug

Sun, 31 May 2026 18:00:00 +0800

TL;DR

An AI Agent was producing duplicated replies in DingTalk — not two separate messages, but a single message whose content appeared twice. The root cause traced back to a streaming bug in NewAPI (the QuantumNous fork of OneAPI) v1.0.0-rc.10: when proxying MiniMax through the OpenAI Chat Completions protocol, the finish chunk contained both delta.content and message.content with identical values. The Agent’s stream handler consumed both as “visible text,” concatenating the content twice. The fix was straightforward: switch the OpenClaw provider protocol from openai-completions to anthropic-messages, which OneAPI natively supports and where streaming behaves correctly.

No internal IPs, tokens, model IDs, or private paths appear in this article. All configuration snippets have been sanitized.

Why HermesAgent Would Not Reply in WeChat or WeCom: The Real Culprit Was a Local Relay With a 3-Second Timeout

Sun, 31 May 2026 08:00:00 +0800

The short version

This incident looked like a model problem or a broken messaging channel, but the real failure happened one layer lower: my local relay cut the upstream request off after 3 seconds. That was fine for quick health checks, but it was wrong for real WeChat and WeCom turns, which often take longer to produce a complete answer from the NewAPI gateway. Once the relay disconnected too early, HermesAgent could only see Connection error, RemoteProtocolError, and then exhausted fallback attempts.