rbranson

For agentic use it impacts input tokens because the output is fed back into the model as input on subsequent turns.

Note that GPT-5.6-Sol is ~2x as token efficient as Opus/Fable, so a 258K max is equivalent to ~516K on Claude models. You also may just be fooling yourself, as context rot is still a problem[1][2] and there's evidence compaction can be equivalent or better than longer context windows for agentic tasks[3]. Obviously it would be best if the models could reason over 1M context like they do over 256K context, but they can't yet.

[1] https://arxiv.org/abs/2605.12366 [2] see F1 of GraphWalks 256K vs 1M in Opus 4.8 System Card: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f... [3] https://context-folding.github.io/

it does not require training a model from scratch for it to be updated. the entire LLM training process is iterative. essentially each step (there are hundreds/thousands for a training run) yields a complete, usable model. tokens with updated data can be added on top essentially at any time in the future.

You are correct. As a point of comparison: almost ten years ago at Segment we had a single Aurora PostgreSQL instance with ~50T of data, it was used to index potential identity data in a much larger corpus of files stored in S3.

I don't know why you're getting downvoted. This is exactly what was reported by curl's creator under the section "Five findings became one": https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

Sure, but you still need to design around this problem. It’s going to be a happy accident that everything turns out fine if you don’t.

Biggest thing to watch out with this approach is that you will inevitably have some failure or bug that will 10x, 100x, or 1000x the rate of dead messages and that will overload your DLQ database. You need a circuit breaker or rate limit on it.

This is explicitly called out in the blog post in the trade-offs section.

I was one of the engineers who helped make the decisions around this migration. There is no one size fits all. We believed in that thinking originally, but after observing how things played out, decided to make different trade-offs.

Bricken isn’t just making this up. He’s one of the leading researchers in model interpretability. See: https://arxiv.org/abs/2411.14257

The 990 Pros have a temperature sensor issue. See https://github.com/openzfs/zfs/discussions/14793#discussionc...

It's all wood construction, originally stick victorians with 2x4 exterior walls. My "loudest" neighbor is being picked up on 80MHz at -47 dBm.

It's a much better answer to hook up everything on Ethernet that you possibly can than it is to follow the more traveled route of more channels and more congestion with mesh Wi-Fi.

Certainly this is the brute-force way to do it and can work if you can run enough UTP everywhere. As a counterexample, I went all-in on WiFi and have 5 access points with dedicated backhauls. This is in SF too, so neighbors are right up against us. I have ~60 devices on the WiFi and have no issues, with fast roaming handoff, low jitter, and ~500Mbit up/down. I built this on UniFi, but I suspect Eero PoE gear could get you pretty close too, given how well even their mesh backhaul gear performs.

This seems pretty bad from the headline but there's no evidence of any in-the-wild exploits or if there is a feasible real-world exploit here. Some other domino(s) have to fall before it allows RCE. For instance, browser-based exploits are blocked by SELinux restrictions on dlopen from the downloads path.

Magnetic hard drives are 100X cheaper per GB than when S3 launched, and are about 3X cheaper than in 2016 when the price last dropped. Magnetic prices have actually ticked up recently due to supply chain issues, but HAMR is expected to cause a significant drop (50-75%/GB) in magnetic storage prices as it rolls out in next few years. SSDs are ~$120/T and magnetic drives are ~$18/T. This hasn't changed much in the last 2 years.

Is it bullshitting to perform nearly perfect language to language translation or to generate photorealistic depictions from text quite reliably? or to reliably perform named entity extraction or any of the other millions of real-world tasks LLMs already perform quite well?

For e-commerce workloads, the performance benefit of write-back mode isn’t worth the data integrity risk. Our customers depend on transactional consistency, and write-through mode ensures every write operation is safely committed to our replicated Ceph storage before the application considers it complete.

Unless the writer is always overwriting entire files at once blindly (doesn't read-then-write), consistency requires consistency reads AND writes. Even then, potential ordering issues creep in. It would be really interesting to hear how they deal with it.

none of the things you cited are “miracle weight loss drugs.” they are things people did to lose weight. these are the first class of drugs that actually cause people to lose weight.

If you wanna run thru this list and get a tally, I quickly created this lovable app: https://cocktail-checkered-log.lovable.app/. I'm at 68/102!

No, wide events are quasi-relational. Read the literature please. I’ve never seen a structured log implementation that is anything remotely relational, it’s just a bunch of random junk thrown into a pile with maybe some common tags.

architecture docs are scant, but it appears this horizontally scales channels by adding "broker" instances and horizontally scales consumers by adding "worker" instances? i.e. a broker only needs to ever broadcast a message to the maximum number of worker instances in the cluster.

You're right. Sync writes are ten times as slow. 331µs.

  write: IOPS=3007, BW=11.7MiB/s (12.3MB/s)(118MiB/10001msec); 0 zone resets
    clat (usec): min=196, max=23274, avg=331.13, stdev=220.25
     lat (usec): min=196, max=23275, avg=331.25, stdev=220.27
    clat percentiles (usec):
     |  1.00th=[  210],  5.00th=[  223], 10.00th=[  235], 20.00th=[  262],
     | 30.00th=[  297], 40.00th=[  318], 50.00th=[  330], 60.00th=[  343],
     | 70.00th=[  355], 80.00th=[  371], 90.00th=[  400], 95.00th=[  429],
     | 99.00th=[  523], 99.50th=[  603], 99.90th=[ 1631], 99.95th=[ 2966],
     | 99.99th=[ 8225]

More specific details for EC2 instances can be seen in the docs here: https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html...

1. The ratelimit on "IOPS" is precisely a ratelimit on a particular kind of network traffic, right? Namely traffic to/from an EBS volume? "IOPS" really means "EBS volume network traffic"?

The EBS volume itself has a provisioned capacity of IOPS and throughput, and the EC2 instance it's attached to will have its own limits as well across all the EBS volumes attached to it. I would characterize it more like a different model. An EBS volume isn't just just a slice of a physical PCB attached to a PCIe bus, it's a share in a large distributed system a large number of physical drives with its own dedicated network capacity to/from compute, like a SAN.

2. Does this save me money? And if yes, is from some weird AWS arbitrage? Or is it more because of an efficiency win from doing less EBS networking?

It might. It's a set of trade-offs.

Not so sure that's true. This is single-threaded direct I/O doing a fio randwrite workload on a WD 850X Gen4 SSD:

    write: IOPS=18.8k, BW=73.5MiB/s (77.1MB/s)(4412MiB/60001msec); 0 zone resets
    slat (usec): min=2, max=335, avg= 3.42, stdev= 1.65
    clat (nsec): min=932, max=24868k, avg=49188.32, stdev=65291.21
     lat (usec): min=29, max=24880, avg=52.67, stdev=65.73
    clat percentiles (usec):
     |  1.00th=[   33],  5.00th=[   34], 10.00th=[   34], 20.00th=[   35],
     | 30.00th=[   37], 40.00th=[   38], 50.00th=[   40], 60.00th=[   43],
     | 70.00th=[   53], 80.00th=[   60], 90.00th=[   70], 95.00th=[   84],
     | 99.00th=[  137], 99.50th=[  174], 99.90th=[  404], 99.95th=[  652],
     | 99.99th=[ 2311]

Did you read the article? Dziri and Peng are not the “skeptical AI community,” they are in fact die hard AI researchers. This is like saying people who run benchmarks to find performance problems in code are skeptics or haters.

The issue is that law enforcement is flagrantly committing serious crimes, for their own profit. It’s offensive and disgusting.

tl;dr is that "ultra-processed foods" are engineered to be more palatable and that tends to result in more caloric density.

One of the only (the only?) commercial grade implementations was launched recently by us at PlanetScale:

https://planetscale.com/blog/announcing-planetscale-vectors-...

The list of circumstances for WAL-mode busy errors is in the doc linked by one of the posters above. It has nothing to do with transactions.

How does busy_timeout address a performance aspect of SQLite?