<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Go on Mengboy Tech Notes</title>
    <link>https://www.mfun.ink/en/tags/go/</link>
    <description>Recent content in Go on Mengboy Tech Notes</description>
    <generator>Hugo -- 0.156.0</generator>
    <language>en</language>
    <lastBuildDate>Wed, 08 Apr 2026 01:22:53 +0000</lastBuildDate>
    <atom:link href="https://www.mfun.ink/en/tags/go/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Go Dual-Provider LLM Routing (OpenAI &#43; Claude): Timeout Tiers, Cost Caps, and Fallback Control</title>
      <link>https://www.mfun.ink/en/2026/04/08/go-dual-model-routing-openai-claude-timeout-cost-fallback/</link>
      <pubDate>Wed, 08 Apr 2026 01:22:53 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/04/08/go-dual-model-routing-openai-claude-timeout-cost-fallback/</guid>
      <description>&lt;p&gt;If your Go service relies on one LLM provider, two failures hurt the most, timeout spikes and billing spikes. A real production setup is not just “add another provider”, it is a single control plane for routing, timeout tiers, cost caps, and fallback.&lt;/p&gt;
&lt;p&gt;This guide gives you a practical OpenAI + Claude dual-provider pattern with one priority, keep uptime first, then optimize quality.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OpenAI Responses &#43; Go Stream Recovery: Delta Persistence, Resume Tokens, and Duplicate Chunk Dedup</title>
      <link>https://www.mfun.ink/en/2026/03/23/openai-responses-go-stream-resume-delta-dedup/</link>
      <pubDate>Mon, 23 Mar 2026 01:13:09 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/23/openai-responses-go-stream-resume-delta-dedup/</guid>
      <description>&lt;p&gt;In production, the painful part is not “streaming is slow.” It’s “streaming breaks and then duplicates output after reconnect.”&lt;br&gt;
This guide gives you a practical recovery loop: &lt;strong&gt;delta persistence + resume token + idempotent dedup&lt;/strong&gt;, so reconnection does not replay garbage.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Go &#43; OpenAI Responses Agent Memory Layering: Short-Term Context, Long-Term Index, and Cost Caps</title>
      <link>https://www.mfun.ink/en/2026/03/18/go-openai-responses-agent-memory-layering/</link>
      <pubDate>Wed, 18 Mar 2026 16:33:52 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/18/go-openai-responses-agent-memory-layering/</guid>
      <description>&lt;p&gt;In production Go agents, the first thing that breaks is usually not model quality. It is memory management: context grows, bills spike, and answers drift.&lt;/p&gt;
&lt;p&gt;Use a 3-layer memory design:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;L1: short-term conversational window (seconds)&lt;/li&gt;
&lt;li&gt;L2: rolling summary (minutes)&lt;/li&gt;
&lt;li&gt;L3: long-term retrieval memory (days)&lt;/li&gt;
&lt;/ul&gt;</description>
    </item>
    <item>
      <title>Handling OpenAI 429/5xx Storms in Go: Token Bucket, Exponential Backoff, and Circuit Breakers</title>
      <link>https://www.mfun.ink/en/2026/03/18/go-openai-429-5xx-storm-defense-token-bucket-backoff-circuit-breaker/</link>
      <pubDate>Wed, 18 Mar 2026 01:14:00 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/18/go-openai-429-5xx-storm-defense-token-bucket-backoff-circuit-breaker/</guid>
      <description>&lt;p&gt;Most Go teams are not killed by a single API error. They are killed by a retry storm they created themselves.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OpenAI Batch API with Go: Offline Batching, Failure Replay, and Cost Boundaries</title>
      <link>https://www.mfun.ink/en/2026/03/13/openai-batch-api-go-cost-control-offline-batching-failure-replay/</link>
      <pubDate>Fri, 13 Mar 2026 01:08:00 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/13/openai-batch-api-go-cost-control-offline-batching-failure-replay/</guid>
      <description>&lt;p&gt;Short answer: if your workload is &lt;strong&gt;delay-tolerant, batchable, and replay-safe&lt;/strong&gt;, move it from online calls to Batch API. The savings are real, but only if you design splitting, failure routing, and replay first.&lt;/p&gt;
&lt;p&gt;Many teams treat Batch API as a cheaper sync endpoint. That usually creates a replay mess instead of stable savings. A conservative rollout starts with cost boundaries and SLOs, then implements offline batching and controlled replay.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OpenAI Responses Structured Outputs with Go: Schema Evolution, Bad-Case Fallbacks, and Gradual Rollback</title>
      <link>https://www.mfun.ink/en/2026/03/11/openai-responses-structured-outputs-go-schema-evolution-fallback-rollback/</link>
      <pubDate>Wed, 11 Mar 2026 01:08:00 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/11/openai-responses-structured-outputs-go-schema-evolution-fallback-rollback/</guid>
      <description>&lt;p&gt;The hardest part of Structured Outputs is not getting JSON once. It is surviving schema changes without turning production into a small fire with excellent logs and terrible business results.&lt;/p&gt;
&lt;p&gt;Once a Go service starts evolving prompts and response contracts, the usual failure modes show up fast: a new required field breaks older consumers, an enum expands and strict validation kills valid requests, or one bad sample drags the whole chain into retries and rollback panic.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OpenAI Realtime &#43; Go in Production: WebRTC Token Rotation, Interruption Recovery, and End-to-End Latency Budgets</title>
      <link>https://www.mfun.ink/en/2026/03/09/openai-realtime-go-webrtc-auth-recovery-latency-budget/</link>
      <pubDate>Mon, 09 Mar 2026 01:13:00 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/09/openai-realtime-go-webrtc-auth-recovery-latency-budget/</guid>
      <description>&lt;p&gt;If you plan to put OpenAI Realtime into production, do not let a passing demo fool you.&lt;/p&gt;
&lt;p&gt;What usually breaks the system is not the model itself. It is &lt;strong&gt;non-rotating short-lived auth, missing interruption state, and zero end-to-end latency budgeting&lt;/strong&gt;. Miss those three and your voice UX starts sounding like an angry walkie-talkie.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Go &#43; OpenAI Responses: Connection Pooling and Timeout Budgets from HTTP/2 Reuse to Error-Budget Control</title>
      <link>https://www.mfun.ink/en/2026/03/06/go-openai-responses-connection-pool-timeout-budget/</link>
      <pubDate>Fri, 06 Mar 2026 01:13:12 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/06/go-openai-responses-connection-pool-timeout-budget/</guid>
      <description>&lt;p&gt;When Go services call the OpenAI Responses API in production, the real failures are rarely about model quality. Most incidents come from transport instability: weak connection pooling, conflicting timeout layers, and retry storms.&lt;/p&gt;
&lt;p&gt;This guide gives you a practical baseline: HTTP/2 reuse, layered timeout budgets, bounded retries, and error-budget driven operations.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OpenAI Responses &#43; Go: Taming Retry Storms with Idempotency Keys, Jittered Backoff, and Circuit Breakers</title>
      <link>https://www.mfun.ink/en/2026/03/04/openai-responses-go-retry-storm-idempotency-backoff-circuit-breaker/</link>
      <pubDate>Wed, 04 Mar 2026 01:10:40 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/04/openai-responses-go-retry-storm-idempotency-backoff-circuit-breaker/</guid>
      <description>&lt;p&gt;The most expensive outage is not a single failure — it is a failure amplified by retries.&lt;/p&gt;
&lt;p&gt;In an OpenAI Responses + Go tool-calling stack, missing idempotency, jittered backoff, and breaker thresholds can turn 10 failing requests into 1000 downstream calls in minutes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming Context Explosion in OpenAI Assistants/Responses with Go: Truncation, Summary Backfill, and Cost Caps</title>
      <link>https://www.mfun.ink/en/2026/03/02/openai-assistants-responses-go/</link>
      <pubDate>Mon, 02 Mar 2026 12:44:00 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/02/openai-assistants-responses-go/</guid>
      <description>&lt;p&gt;Long-running agent sessions usually fail the same way: context keeps growing, latency spikes, costs blow up, and answer quality gets worse.&lt;/p&gt;
&lt;p&gt;That is rarely a model-quality issue. It is almost always missing context governance.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Go &#43; OpenAI API Timeout Troubleshooting: DNS, TLS, Proxy, and Connection Pool</title>
      <link>https://www.mfun.ink/en/2026/03/02/go-openai-api-timeout-troubleshooting-dns-tls-proxy-connection-pool/</link>
      <pubDate>Mon, 02 Mar 2026 01:12:10 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/03/02/go-openai-api-timeout-troubleshooting-dns-tls-proxy-connection-pool/</guid>
      <description>&lt;p&gt;When OpenAI API calls start timing out in production, the real problem is usually not “OpenAI is down.”&lt;/p&gt;
&lt;p&gt;The real problem is you don’t know which hop is failing: DNS, TLS handshake, proxy path, or your own connection pool.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OpenAI Agents SDK with Go: Tool Calling, Session Memory, and Error Recovery</title>
      <link>https://www.mfun.ink/en/2026/02/25/openai-agents-sdk-go-tool-calling/</link>
      <pubDate>Wed, 25 Feb 2026 01:18:00 +0000</pubDate>
      <guid>https://www.mfun.ink/en/2026/02/25/openai-agents-sdk-go-tool-calling/</guid>
      <description>&lt;p&gt;Most teams can connect an LLM in a demo. The real pain starts in production: multi-step tasks, flaky tool calls, unclear retries, and rising cost.&lt;/p&gt;
&lt;p&gt;This guide gives you a pragmatic Go-first blueprint for shipping an Agent workflow that can survive real incidents.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
