-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.xml
More file actions
157 lines (157 loc) · 15.5 KB
/
Copy pathindex.xml
File metadata and controls
157 lines (157 loc) · 15.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
<?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>Loop & Retry</title>
<link>https://loopandretry.github.io/</link>
<description>Recent content on Loop & Retry</description>
<image>
<title>Loop & Retry</title>
<url>https://loopandretry.github.io/images/og-default.png</url>
<link>https://loopandretry.github.io/images/og-default.png</link>
</image>
<generator>Hugo</generator>
<language>en-us</language>
<lastBuildDate>Fri, 21 Aug 2026 09:00:00 -0700</lastBuildDate>
<atom:link href="https://loopandretry.github.io/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>The cost of undoing: partial failures and the cleanup bill</title>
<link>https://loopandretry.github.io/posts/the-cost-of-undoing-partial-writes/</link>
<pubDate>Fri, 21 Aug 2026 09:00:00 -0700</pubDate>
<guid>https://loopandretry.github.io/posts/the-cost-of-undoing-partial-writes/</guid>
<description>An agent writes to three systems, then fails on the fourth. The first three writes are now orphaned in a partially-succeeded state. Rolling them back costs more than the original operation — not in tokens, but in human time and coordination overhead. This is the cleanup bill: the hidden cost of partial failures that retry logic doesn&rsquo;t touch.</description>
</item>
<item>
<title>What actually drives your Claude bill: cache misses, quadratic context, and prepaid retries</title>
<link>https://loopandretry.github.io/posts/what-drives-your-claude-bill/</link>
<pubDate>Thu, 20 Aug 2026 22:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/what-drives-your-claude-bill/</guid>
<description>The per-token rate on Anthropic&rsquo;s pricing page is real, but it&rsquo;s the least useful number for predicting your actual invoice. Three multipliers move the bill far more than model choice does — a cache that silently misses, a transcript that grows quadratically with run length, and a best-of-N pattern that prepays for latency you may not need. Here&rsquo;s the arithmetic on all three, combined, with real numbers.</description>
</item>
<item>
<title>The cost of finding a failure after the customer finds it</title>
<link>https://loopandretry.github.io/posts/cost-of-late-failure-detection/</link>
<pubDate>Mon, 17 Aug 2026 21:00:00 -0700</pubDate>
<guid>https://loopandretry.github.io/posts/cost-of-late-failure-detection/</guid>
<description>An agent&rsquo;s failure isn&rsquo;t expensive because it failed—it&rsquo;s expensive because you found out about it from a customer complaint instead of an alert. Detection latency multiplies the cleanup cost by an order of magnitude. This post explores the arithmetic of failure-finding, why automated detection is worth the infrastructure cost, and how to choose detection strategies.</description>
</item>
<item>
<title>The agent that trusted a bad API: silent failures and validation debt</title>
<link>https://loopandretry.github.io/posts/tool-output-validation-cost/</link>
<pubDate>Thu, 13 Aug 2026 20:56:00 +0000</pubDate>
<guid>https://loopandretry.github.io/posts/tool-output-validation-cost/</guid>
<description>An agent called an API, got a syntactically valid response, trusted it, and built three wrong decisions on top of it. No error was thrown. Every step succeeded locally. The cascade cost was 15× the original bad call — and all of it was preventable by a two-line validation check. This is validation debt: paying the cost of skipped checks in compounding failure downstream.</description>
</item>
<item>
<title>Best-of-N is prepaid retries: the cost math of racing parallel attempts</title>
<link>https://loopandretry.github.io/posts/best-of-n-is-prepaid-retries/</link>
<pubDate>Sun, 09 Aug 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/best-of-n-is-prepaid-retries/</guid>
<description>Launching N attempts at once and keeping the first success feels like a free win over sequential retries — you trade money for tail latency, and money is supposedly the thing you have more of. It isn&rsquo;t free, and it isn&rsquo;t even always a trade: for the correlated failures that dominate real production incidents, best-of-N pays for N guaranteed-identical failures up front instead of stopping at one.</description>
</item>
<item>
<title>The transcript is a log, not an index: retrieval for long-running agents</title>
<link>https://loopandretry.github.io/posts/transcript-is-a-log-not-an-index/</link>
<pubDate>Wed, 05 Aug 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/transcript-is-a-log-not-an-index/</guid>
<description>Eviction and summarization keep a long-running agent&rsquo;s window small, but the summaries themselves still accumulate in the linear transcript — and on a run long enough, that accumulation becomes the new quadratic. Past a few hundred steps, the fix isn&rsquo;t a better compaction policy inside the window. It&rsquo;s moving history out of the window entirely and querying it like a database instead of replaying it like a log.</description>
</item>
<item>
<title>The caller gave up ten minutes ago: orphaned retries in agent fleets</title>
<link>https://loopandretry.github.io/posts/orphaned-retries-cancellation/</link>
<pubDate>Wed, 29 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/orphaned-retries-cancellation/</guid>
<description>A user closes the tab. An upstream request times out. A parent agent gets cancelled by its own budget. None of that reliably reaches the retry loop three calls deep, so the retry keeps going — burning tokens and rate-limit headroom for a result nobody will ever read. Cancellation is the one signal every fleet retry pattern assumes exists and almost none actually propagate.</description>
</item>
<item>
<title>429 is not a timeout: why rate limits need their own retry budget</title>
<link>https://loopandretry.github.io/posts/rate-limits-are-not-failures/</link>
<pubDate>Tue, 28 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/rate-limits-are-not-failures/</guid>
<description>A 429 and a 500 both land in the same except block, so most retry budgets treat them the same: one bucket, one backoff curve, one circuit breaker. That conflation is wrong in both directions — it makes you wait too little for the failure that isn&rsquo;t yours, and panic too much over the one that is. Two error classes, two buckets, and the Retry-After header everyone reads and no one obeys.</description>
</item>
<item>
<title>Measuring retry success: the metric that tells you if retries work</title>
<link>https://loopandretry.github.io/posts/retry-observability-measuring-success/</link>
<pubDate>Fri, 24 Jul 2026 18:00:00 -0700</pubDate>
<guid>https://loopandretry.github.io/posts/retry-observability-measuring-success/</guid>
<description>You can&rsquo;t tune a retry strategy you can&rsquo;t see. This is how to instrument retries so you know whether each one succeeds (saving you money) or fails permanently (burning it). Three structured metrics turn a blind spot into actionable signal.</description>
</item>
<item>
<title>Evaluating your evals: how to know the LLM judge is right</title>
<link>https://loopandretry.github.io/posts/evaluating-your-evals/</link>
<pubDate>Fri, 24 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/evaluating-your-evals/</guid>
<description>You built an LLM judge to grade your agent. What grades the judge? An eval you never validated is a ruler you never checked against a meter stick — and a biased judge doesn&rsquo;t just add noise, it moves your headline number in a consistent direction. How to meta-evaluate a judge: the labeled set, the agreement metric that isn&rsquo;t accuracy, and the drift check.</description>
</item>
<item>
<title>Retry context: building observability into retry decisions</title>
<link>https://loopandretry.github.io/posts/retry-context-observability/</link>
<pubDate>Fri, 24 Jul 2026 06:00:00 -0700</pubDate>
<guid>https://loopandretry.github.io/posts/retry-context-observability/</guid>
<description>The retry decision (when to give up, how long to wait) only works if you can see inside it. Idempotency keys, retry-attempt correlation, and cost accounting are the foundation. Without them, your retry logic is flying blind — you can&rsquo;t tell if you&rsquo;re fixing a transient failure or burning your budget on a permanent one.</description>
</item>
<item>
<title>When a pipeline beats an agent: three shapes that don't need a loop</title>
<link>https://loopandretry.github.io/posts/when-a-pipeline-beats-an-agent/</link>
<pubDate>Tue, 21 Jul 2026 07:35:00 -0700</pubDate>
<guid>https://loopandretry.github.io/posts/when-a-pipeline-beats-an-agent/</guid>
<description>&lsquo;When not to build an agent&rsquo; made the case against the loop in the abstract — quadratic cost, serial latency, an untestable failure surface. This is the concrete follow-on: three fixed pipeline shapes (linear chain, router-plus-handlers, fan-out/fan-in) that cover most of what people default to a loop for, why each one is cheaper and more testable, and the one test for when a real loop actually earns its cost.</description>
</item>
<item>
<title>Retry patterns: when you should give up (and why most code doesn't)</title>
<link>https://loopandretry.github.io/posts/retry-patterns-when-to-give-up/</link>
<pubDate>Tue, 21 Jul 2026 07:30:00 -0700</pubDate>
<guid>https://loopandretry.github.io/posts/retry-patterns-when-to-give-up/</guid>
<description>Retry budgets cap HOW MUCH you retry; this is about WHEN to retry at all. The decision isn&rsquo;t uniform: user-facing operations, background jobs, and fleet-wide cascades each have different failure costs, different retry ceilings, and different layers where the decision lives. A cost model for when to fail fast instead.</description>
</item>
<item>
<title>Failure modes in multi-agent teams: how a crew of agents breaks differently</title>
<link>https://loopandretry.github.io/posts/multi-agent-failure-modes/</link>
<pubDate>Tue, 21 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/multi-agent-failure-modes/</guid>
<description>A single agent fails by getting the task wrong. A team of agents fails in ways no single agent can: correlated collapse, diffused responsibility, context fragmentation, and consensus that converges on nothing. The four failure modes that only exist once you have more than one agent — and why adding agents can lower reliability.</description>
</item>
<item>
<title>Prompt caching: what actually gets cached, and when it silently misses</title>
<link>https://loopandretry.github.io/posts/prompt-caching-silent-misses/</link>
<pubDate>Mon, 20 Jul 2026 21:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/prompt-caching-silent-misses/</guid>
<description>Prompt caching can cut your input-token bill by 90% on the reused part of a request — or do nothing at all, with no error to tell you which. It&rsquo;s an exact-prefix match with a short TTL, and small, common mistakes in how agents build requests break it silently. Here&rsquo;s what actually gets cached, the five ways real agents lose the discount without noticing, and how to check whether yours is.</description>
</item>
<item>
<title>Context contamination: why retrying the same prompt makes it worse</title>
<link>https://loopandretry.github.io/posts/context-contamination/</link>
<pubDate>Sun, 19 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/context-contamination/</guid>
<description>The default retry pattern — catch the failure, append &rsquo;that didn&rsquo;t work, try again,&rsquo; resend the same messages — doesn&rsquo;t give the model a clean second attempt. It gives the model a context window containing its own wrong answer, which is exactly the thing most likely to make the second attempt rhyme with the first. Why retries poison the window, how to tell a poisoning retry from a safe one, and a scrub step that keeps the constraints without keeping the wrong path.</description>
</item>
<item>
<title>Context window sizing for fine-tuning: how long should your training examples be?</title>
<link>https://loopandretry.github.io/posts/context-sizing-for-fine-tuning/</link>
<pubDate>Sat, 18 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/context-sizing-for-fine-tuning/</guid>
<description>Fine-tuning example length is a design decision, not a byproduct of your data. Pad too short and you teach a distribution you&rsquo;ll never see at inference; let examples sprawl and you pay quadratic training cost to memorize context you should be retrieving. How to size training sequences to the context you&rsquo;ll actually serve.</description>
</item>
<item>
<title>Your timeout is a bet: pricing the tradeoff before you pick a number</title>
<link>https://loopandretry.github.io/posts/timeout-is-a-bet/</link>
<pubDate>Sat, 18 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/timeout-is-a-bet/</guid>
<description>Every per-step timeout is a number someone typed in without a model behind it — too short and you kill real work in flight, too long and you pay to sit idle waiting on a hang. Both mistakes are failure modes with a price tag. A small cost model finds the number that actually minimizes total cost instead of the one that felt safe.</description>
</item>
<item>
<title>Streaming tool calls without losing your mind</title>
<link>https://loopandretry.github.io/posts/streaming-tool-calls-without-losing-your-mind/</link>
<pubDate>Thu, 16 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/streaming-tool-calls-without-losing-your-mind/</guid>
<description>Streaming a text response is easy: print tokens as they arrive, order doesn&rsquo;t matter to the reader. Streaming a tool call is not, because the payload is JSON, and partial JSON is not valid JSON. The three ways people handle that mismatch, why two of them break in production, and the pattern that lets you show progress without ever executing on a half-formed argument.</description>
</item>
<item>
<title>Retry budgets by language: Python, Go, and JavaScript</title>
<link>https://loopandretry.github.io/posts/retry-budgets-by-language/</link>
<pubDate>Wed, 15 Jul 2026 09:00:00 -0400</pubDate>
<guid>https://loopandretry.github.io/posts/retry-budgets-by-language/</guid>
<description>A retry budget is a language-agnostic idea, but the place you enforce it is not. Python&rsquo;s tenacity decorators, Go&rsquo;s context-plus-backoff, and JavaScript&rsquo;s promise chains each make a different mistake easy and a different guarantee hard. Where the shared budget lives, and the per-language trap that leaks it.</description>
</item>
</channel>
</rss>