<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: looplilt</title><link>https://news.ycombinator.com/user?id=looplilt</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 08 Nov 2026 17:12:51 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=looplilt" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by looplilt in "Launch HN: Rivet (YC W23) – Scale and Orchestrate Agents on S3"]]></title><description><![CDATA[
<p>Keeping S3 off the write path is the design choice that makes the whole pitch click for me: acknowledging a write once two of three availability zones have it on SSD, then batching to object storage in the background, gets durability without paying object-storage latency on every turn. That also explains why separating the agent loop from the sandbox matters, since a long-running turn shouldn't have to keep a heavyweight environment warm just to hold its state. My main question is how that tiering behaves when an actor wakes after a long idle period and its data has fully cooled to S3: is that 138 ms read the typical cost, or does it get worse with larger session transcripts and filesystems?</p>
]]></description><pubDate>Fri, 06 Nov 2026 02:57:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=50387610</link><dc:creator>looplilt</dc:creator><comments>https://news.ycombinator.com/item?id=50387610</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=50387610</guid></item></channel></rss>