https://blog.margrop.net/en/tag/openai-compatible-api/ Recent content in OpenAI Compatible API on Margrop Blog Hugo en-US Sun, 31 May 2026 18:00:00 +0800 https://blog.margrop.net/en/post/newapi-streaming-duplicate-content-debugging/ Sun, 31 May 2026 18:00:00 +0800 https://blog.margrop.net/en/post/newapi-streaming-duplicate-content-debugging/ <blockquote> <p><strong>TL;DR</strong></p> <p>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 <strong>both <code>delta.content</code> and <code>message.content</code></strong> with identical values. The Agent&rsquo;s stream handler consumed both as &ldquo;visible text,&rdquo; concatenating the content twice. The fix was straightforward: switch the OpenClaw provider protocol from <code>openai-completions</code> to <code>anthropic-messages</code>, which OneAPI natively supports and where streaming behaves correctly.</p> <p>No internal IPs, tokens, model IDs, or private paths appear in this article. All configuration snippets have been sanitized.</p> </blockquote> https://blog.margrop.net/en/post/openclaw-wechat-duplicate-reply-debugging/ Fri, 29 May 2026 11:24:29 +0800 https://blog.margrop.net/en/post/openclaw-wechat-duplicate-reply-debugging/ <blockquote> <p><strong>Short version</strong></p> <p>The symptom looked like a messaging-channel bug: an AI assistant connected to a personal chat channel appeared to repeat the same reply multiple times. The real bug was earlier in the chain. Before the reply ever reached the message-sending layer, the OpenClaw agent had already produced duplicated visible text. The useful fix was not to patch the chat sender blindly, but to split the path into transport, session, model-routing, and provider layers, then compare the OpenAI-compatible gateway path with the native provider path. Once the faulty compatible provider candidate was removed from the visible model set and the personal IM channel was pinned to the native provider, the same minimal prompt returned exactly once.</p> <p>This post is deliberately privacy-safe. It contains no real internal addresses, account IDs, tokens, session IDs, personal chat identifiers, or private file paths. Configuration examples use placeholders. The value is the debugging method, not the private environment.</p> </blockquote>