<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>AI Gateway on Margrop Blog</title>
		<link>https://blog.margrop.net/en/tag/ai-gateway/</link>
		<description>Recent content in AI Gateway on Margrop Blog</description>
		<generator>Hugo</generator>
		<language>en-US</language>
		
		
		
		
			<lastBuildDate>Fri, 10 Jul 2026 15:30:00 +0800</lastBuildDate>
		
			<atom:link href="https://blog.margrop.net/en/tag/ai-gateway/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Stop Sprinkling API Keys Everywhere: My Self-Hosted NewAPI Relay Station</title>
				<link>https://blog.margrop.net/en/post/newapi-self-hosted-relay-station/</link>
				<pubDate>Fri, 10 Jul 2026 15:30:00 +0800</pubDate>
				<guid>https://blog.margrop.net/en/post/newapi-self-hosted-relay-station/</guid>
				<description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
			</item>
			<item>
				<title>One Missing operator.write Took Down the Gateway: The OpenClaw Fallback Failure That Wasn&#39;t a Model Problem</title>
				<link>https://blog.margrop.net/en/post/openclaw-missing-operator-write-scope/</link>
				<pubDate>Fri, 10 Jul 2026 08:00:00 +0800</pubDate>
				<guid>https://blog.margrop.net/en/post/openclaw-missing-operator-write-scope/</guid>
				<description>&lt;p&gt;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:&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;missing scope: operator.write&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;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&amp;rsquo;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 &lt;code&gt;operator.write&lt;/code&gt;; the request simply did not carry the identity that could prove it.&lt;/p&gt;&#xA;&lt;p&gt;The shortest version is this: &lt;strong&gt;the badge existed, but this entrance did not scan it.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://blog.margrop.net/post-images/openclaw-missing-operator-write-scope/cover.png&#34; alt=&#34;AI-generated cover showing a gateway protected by two authorization locks&#34;&gt;&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
