DEV Community: szp2005

Our IP score knows this is iCloud Private Relay and still rates it like a paid VPN

szp2005 — Wed, 30 Sep 2026 02:08:02 +0000

Paste 104.28.28.5 into our IP checker and you get 65 out of 100, amber, with a relay tag sitting next to vpn and proxy. Paste a Mullvad WireGuard exit in Atlanta and you get the same score. One is an Apple egress carrying ordinary Safari traffic from people who flipped a switch in their iCloud settings. The other is a node on a VPN people pay for.

It looks like a bug. We looked at it as one, and then decided to keep it.

What the vendors actually return

Our score is a weighted average across a set of reputation sources, plus hard floors. The floor that matters here: if enough dedicated sources vote proxy or VPN, the score can't drop below 65. "Dedicated" means everyone except ip-api, whose flags are coarse booleans. For an address that already sits in a datacenter, "enough" means two votes, because a lone proxy flag on cloud space is usually one vendor painting a whole range.

On the Apple address, three sources voted: Scamalytics, proxycheck and vpnapi.io. The odd part is what two of them said next to the vote. Scamalytics returned is_apple_icloud_private_relay: true and flagged the IP as a VPN in the same response. vpnapi.io returned relay: true and vpn: true together. So they know exactly what this address is, and they still call it a VPN.

You can check it yourself, no key needed:

curl -s 'https://ipok.io/api/ip?ip=104.28.28.5' \
  | jq '{risk, signals, evidence, floors: .riskBreakdown.floors}'

The weighted average of the individual source scores comes out around 30. The floor is what drags it up to 65.

What we tried

The first fix was the obvious one. We already detect relay: Apple publishes its egress ranges and we load them into our offline list, and IPHub and vpnapi.io both expose a relay field. So exempt relay IPs from the VPN floor and move on.

We shipped half of that. Relay now exempts an IP from the hosting floor of 35, which exists because datacenter traffic gets treated with more suspicion even when nothing specific is wrong with the address. That floor was plainly wrong for Private Relay. The exit is in Cloudflare's address space, but there's a normal person behind every connection. Our own offline list also stopped casting a VPN vote on those ranges.

Dropping the 65 was a different question. The score isn't a verdict on whether the person behind the IP is up to something. It's a forecast of how other services will treat the address. Any site that asks one of those same vendors gets "VPN" back, relay or not. If we removed the floor, we'd be overruling three vendors whose verdicts other sites may well be reading. The score would look friendlier and predict worse.

What we do now

The decision sits in the code, right next to the check, so nobody "fixes" it later:

const isRelay = any("relay");
// Relay only exempts the hosting floor, NOT the 65 proxyVpn floor.
// The score describes how the outside world treats this IP,
// and many services really do block iCloud Private Relay.
if (any("hosting") && !hasTrustedWhitelist && !isRelay)
  floors.push({ key: "hosting", floor: 35, bucket: "contextual" });

(The comment is translated; the original is in Chinese.)

The relay tag in the result is the explanation, and the methodology page has a paragraph saying the same thing in plain language.

This has a cost. The headline number can't tell "you turned on an Apple privacy feature" apart from "you're on a paid VPN". If that difference matters to you, you have to look for relay in signals, or open the per-source raw fields and read Scamalytics' relay boolean yourself. We accepted that. The alternative is a score that disagrees with the vendors doing the actual blocking, which would make it wrong about the one thing it is supposed to predict.

If you run any kind of reputation scoring, it's worth deciding which of the two your number is: a judgment about the user, or a prediction of how others will judge them. We went with the prediction, and Private Relay is where that choice feels worst to explain to a user.

I built ipok, the checker used in the examples above.

Fable 5.1 costs twice as much as Opus 5, until your cache gets big enough

szp2005 — Mon, 28 Sep 2026 02:10:53 +0000

Claude Fable 5.1 shipped on September 1 with the same $10 input / $50 output per million tokens as Fable 5. One number moved: cache reads dropped from $1 to $0.25 per million.

On the price sheet it still costs twice what Opus 5 does ($5 / $25). But look at the cache-read column and the order flips. Fable 5.1 charges $0.25 there, Opus 5 charges $0.50. So which one is cheaper depends on how much of each request is served from cache, and I wanted the actual crossover instead of a vibe.

A request bill has three parts

Cached tokens times the cache-read price, fresh input times the input price, output times the output price. Fable 5.1 only changed the first term, so the saving over Fable 5 is exactly as big as that term's share of your bill.

Two workloads I priced out from the table on my site:

Per request	Fable 5	Fable 5.1	Opus 5
Agent: 100K cached, 2K new input, 1K output	$0.170	$0.095	$0.085
Chat: 5K cached, 1K new input, 800 output	$0.055	$0.051	$0.028

In the agent loop, cache reads are about 60% of the Fable 5 bill, so the price cut takes 44% off each request. That lines up with the "around 45% for heavy agent use" figure in the launch coverage.

The chat case barely moves. Output dominates, and Opus 5 stays roughly half the price. Switching there is just paying more.

The crossover

Fable 5.1 pays double for fresh input and output, and half for cache reads. Set the two bills equal:

0.25 * R = 5 * U + 25 * O
R = 20 * U + 100 * O

R is cached tokens per request, U is fresh input, O is output. Plug in the agent numbers above and the line sits at 140K cached tokens. Both models cost $0.105 a request there.

Past that point the gap keeps widening. At 200K cached, Fable 5.1 is about 11% cheaper. Double the cache again and it's more than a quarter cheaper.

Output length is what pushes the line out. Every extra thousand output tokens needs another hundred thousand cached tokens before Fable 5.1 catches up.

The part I got wrong the first time

My first pass stopped there and the conclusion was "long-context agents should move to Fable 5.1." Then I remembered that tokens have to get into the cache before they can be read from it.

Anthropic bills a 5-minute cache write at 1.25x the input price for Opus 5. My price table has no separate write price for Fable 5.1. If it follows the same 1.25x rule, writing a 200K prefix costs $1.25 more on Fable 5.1 than on Opus 5. At 200K cached, Fable 5.1 saves $0.015 per request. That's more than 80 requests on the same prefix before the write premium is paid back.

So if your prefix expires every five minutes, or your agent keeps rewriting its context, you may never reach the crossover at all. Measure how many requests actually reuse each prefix before you switch.

How I'd decide

Pull three averages from your logs: cached tokens, fresh input and output per request. Then check how many requests reuse the same prefix.

Below 20U + 100O cached tokens: stay on Opus 5.
Above it, but prefixes get rebuilt every few dozen requests: the write premium eats the difference. Stay on Opus 5.
Above it, with one long-lived prefix (a coding agent in a long session, Q&A over one big fixed document): Fable 5.1 wins per request, and it scores 66 vs 63 on the quality index I track.
Already on Fable 5: switch. Nothing got more expensive.

I built llmabacus.com, the LLM API price table these numbers come from. The full write-up, in Chinese, is at https://www.llmabacus.com/articles/fable-5-1-cache-read-vs-opus-5

CoreText said 59 points, the Chinese caption needed 71, and the export "succeeded" blank

szp2005 — Fri, 25 Sep 2026 02:12:44 +0000

The export finished. The file played and the size looked right. There was not a single caption on screen.

That's what my iOS caption-burning app did the day I tried to make Chinese App Store screenshots. Every Chinese caption came out blank. English was fine, which is why nobody had noticed. No API returned an error, and CGContext.makeImage() happily returned a non-nil image. It was fully transparent.

It was two separate bugs with the same symptom, and both only show up if you look at pixels.

How the captions get into the video

Captions are drawn with CoreText into a CGImage, put on a CALayer, and composited over the video with AVVideoCompositionCoreAnimationTool. Each caption layer starts at opacity = 0 and gets a discrete keyframe animation that switches it on and off at the segment's start and end times. Both steps can fail silently.

Bug 1: CoreText measured Chinese text too short

To size the bitmap, the old code asked CoreText how tall the text would be:

let size = CTFramesetterSuggestFrameSizeWithConstraints(
    framesetter, CFRangeMake(0, 0), nil,
    CGSize(width: width, height: .greatestFiniteMagnitude), &fitRange)
return ceil(size.height) + 2

For a 57.6pt Chinese caption (no spaces anywhere), it suggested 59 points. Actually laying out the same string needed 71. We built a CTFrame with a 61pt path, and CTFrameGetLines returned zero lines. Zero lines means nothing gets drawn, and every API involved treats the transparent result as a successful render.

We'd been bitten by this class of bug before. boundingRect once measured 68.0 where CoreText wanted 68.4, and half a point was enough to drop the only line. Our takeaway then was "use the CoreText API". It should have been "measure with the exact code path you draw with".

The current version lays the text out for real inside a path too tall to constrain anything, then sums the actual line metrics:

let probePath = CGPath(rect: CGRect(x: 0, y: 0, width: width, height: 100_000), transform: nil)
let frame = CTFramesetterCreateFrame(framesetter, CFRangeMake(0, 0), probePath, nil)
for line in CTFrameGetLines(frame) as? [CTLine] ?? [] {
    var ascent: CGFloat = 0, descent: CGFloat = 0, leading: CGFloat = 0
    CTLineGetTypographicBounds(line, &ascent, &descent, &leading)
    total += ascent + descent + leading
}

I didn't trust that alone. A second step builds the frame at the measured height and checks that CTFrameGetVisibleStringRange(frame).length covers the whole string. If not, it adds height and retries, up to five times. It's cheap, and it's the only code in the pipeline that can see this failure.

Bug 2: a caption covering the whole clip never appears

This one showed up on a 4-second screenshot clip with one caption running from 0 to the end. Our timing code turned that into keyTimes = [0, 1], values = [1]. That's a legal shape for a discrete animation (one more key time than values), but a one-value discrete animation changes nothing, and the layer sat at opacity 0 for the whole export.

Same sentence, measured both ways: spanning the whole clip, 0 caption pixels. Moved to 0.5s through 3.5s, 14,100.

The fix is boring on purpose. When the track has one value, skip the animation:

if track.values.count == 1 {
    return track.values[0] > 0 ? .always : .never
}

and .always just sets container.opacity = 1.

Counting pixels instead of watching videos

Neither bug throws or logs. A test asserting "export returned a URL" passes on both. Watching output by hand doesn't scale across 26 caption presets.

The simulator was no help either. CoreAnimation offline rendering crashes there in IOSurfaceCreate, and a round trip on a real device took about five minutes. So we added a thin shim (PlatformFont, PlatformColor) that lets the production ExportService.swift compile unchanged on macOS, and wrote a command-line harness, Tests/LocalHarness/burnin-main.swift, that links the real source files rather than a copy.

The harness:

Synthesizes a solid-color 6-second source video with a 90° rotation transform.
Runs the real ExportService.renderBurnIn on it.
Grabs frames at exact timestamps with AVAssetImageGenerator, zero tolerance on both sides.
Samples the background color near the top of the frame and counts pixels in the caption band that differ from it.

When a caption should be visible, it expects more than 500 foreign pixels. In a gap, exactly zero, which also catches captions lingering past their end time.

Both bugs are now permanent sections. Section 5 renders three space-free Chinese strings, one long enough to wrap. Section 6 renders a caption from 0 to 6 seconds and checks frames at 0.5s, 3.0s and 5.5s. Any ❌ exits non-zero.

What this costs

"Pixels that aren't background" tells you something was drawn. It can't tell you it's the right text, font or position. We have a few narrower checks (color-specific pixel counts for custom styles, alpha on rounded corners), but the core test is deliberately dumb, and because the source is a solid color it won't notice problems that only appear over busy footage.

I'll take that. In a caption app, the failure I worry about most is a successful export with nothing in it, and this is the check that catches it.

I built this for CapScribe, an iOS app that transcribes on device with Apple's SpeechAnalyzer and burns captions into the video file. grep -rn URLSession Sources/ in the repo returns nothing. https://apps.apple.com/app/id6801041856

One vendor was deciding our residential proxy verdicts, and I couldn't grade it against itself

szp2005 — Wed, 23 Sep 2026 02:07:54 +0000

My IP reputation checker has a rule that moves scores more than the weighted average ever does. When enough sources say "this address is a proxy or VPN", the score gets a hard floor of 65, which puts it in the caution band. How many sources count as "enough" depends on the address type:

const need = isDatacenter ? 2 : 1; // dedicated votes, ip-api excluded
const realProxy = dedicatedVotes >= need || !!knownAnonAsn;
if (realProxy) floors.push({ key: "proxyVpn", floor: 65 });

Datacenter ranges need two independent vendors, because a couple of feeds like to tag whole cloud blocks as proxies. Residential addresses need one, on the theory that residential proxies are rare but real when you do see them. I picked both numbers in August and never measured either.

What the logs said

Last week I pulled the per-lookup vote signatures we already keep. They record which source said what and the final verdict, with no IPs, ASNs or countries. Over a 15-day window the residential one-vote row was the uncomfortable one: 1,256 verdicts pushed into the caution band by a single vote, and in 96% of them that vote came from the same vendor.

So "one dedicated vote" really meant one vendor deciding, alone, for people on home connections. Nothing in the pipeline pushed back, because almost nothing else was voting at the time. One source sat behind a quota gate, another was dormant, and our own offline list only votes when an address is on it.

The datacenter side looked fine. The two-vote rule was absorbing that vendor's habit of flagging entire cloud ranges, which is what it was written for.

The yardstick I almost used

The obvious check is to compare the single vote against our final verdict. On a residential address with one vote, the final verdict is that vote, so the comparison returns 100% and tells you nothing.

Calibration needs a field the thing being graded can't write to. We had just wired in two more vendors, IPHub and vpnapi.io, which are unrelated to each other and to the one under test. The check became: on lookups where only that vendor said "proxy", what did the other two say?

for (const row of rows) {
  if (state(row, SUBJECT) !== ANON) continue;       // only its solo proxy calls
  const votes = YARDSTICKS.map((s) => state(row, s));
  if (votes.includes(ANON)) t.confirmed += row.n;
  else if (votes.includes(CLEAN)) t.refuted += row.n;
  else t.absent += row.n;                            // no opinion: not in the denominator
}
const rate = t.confirmed / (t.confirmed + t.refuted);

I care most about the absent bucket. If both yardsticks time out, or only report Tor or abuse history, they said nothing about proxies. Counting those rows as refuted would drag the rate down for no reason.

The decision rule is coarse on purpose. For residential, 70% confirmation or better keeps one vote, under 40% tightens it to two, and anything in between holds the current value. The datacenter rule can only get stricter, from two votes to three.

Letting a script touch a scoring rule

A weekly job rewriting a threshold that decides user-facing verdicts is a risk of its own, so three guardrails live in code. Each threshold has hard bounds (residential 1 or 2, datacenter 2 or 3). Nothing moves until confirmed plus refuted reaches 500 samples. One run can shift a threshold by one step at most.

My first version still got it wrong. The weekly build wrote the new JSON and deployed it, then the next ordinary push redeployed whatever file sat in the repo. Production would have flipped between the two, and nobody could have said which threshold was live on a given day.

Now the job only proposes. It writes the result to a temp file, and if a threshold would move, CI opens an issue with the full JSON and the evidence. Production reads the committed file and nothing else. I either paste the proposal into the repo or close the issue.

Where it stands, and what it costs

The first run changed nothing. The 500-sample gate held both thresholds, because the two yardstick vendors went live the same day the job did. The published calibration file still shows zero samples and the August values, and until data piles up, residential proxy verdicts remain one vendor's call.

The yardstick has a blind spot I can't measure yet. "Confirmed" means two other commercial feeds agreed. It doesn't mean anyone saw a real proxy, and if all three vendors buy from the same upstream list, agreement costs nothing.

What I actually got out of this week is a smaller thing than a better threshold: I know which number in the scoring code carries the most weight, and I know it had never been checked against anything.

I built ipok.io. The current calibration file is public at ipok.io/api/data/calibration if you want to watch the rate fill in.

Our 3 a.m. batch job was running at Beijing's afternoon peak rate

szp2005 — Mon, 21 Sep 2026 02:20:23 +0000

DeepSeek's API charges two different prices for the same tokens. Which one you pay depends on what time it is in Beijing when the request lands.

That is the whole bug. It took me an embarrassingly long time to find, because nothing in our code was wrong.

The rule

Beijing time, Monday through Friday, 09:00-12:00 and 14:00-18:00 are peak hours. Everything else is off-peak: nights, weekends, Chinese public holidays. Off-peak is exactly half of peak.

For V4 Pro, per million tokens, in CNY:

	Off-peak	Peak
Input, cache miss	¥4.5	¥9
Input, cache hit	¥0.15	¥0.30
Output	¥13.5	¥27

Peak is seven hours a day on weekdays, about a fifth of the week. So most of the time you are already in the cheap band by accident, which is why nobody notices the rule until they land in the other fifth.

Where it goes wrong

Our reindex job ran at 3 a.m. Eastern. That felt like the safe, nobody-is-awake slot.

3 a.m. EDT is 07:00 UTC. That is 15:00 in Beijing, the dead center of the second peak window.

Converted out of Beijing time, the two peak blocks land here:

Zone	Block 1	Block 2
Beijing (UTC+8)	09:00-12:00	14:00-18:00
UTC	01:00-04:00	06:00-10:00
US Eastern (EDT)	21:00-24:00 prev day	02:00-06:00

Read the last row again if you schedule on a US clock. The classic overnight maintenance window, roughly 2 a.m. to 6 a.m. Eastern, is peak from end to end.

Ordinary East Coast business hours, 6 a.m. through 9 p.m., are all off-peak. So the cheap slot is the middle of your working day and the expensive one is the middle of your night.

There is a day-boundary version of the same trap. Beijing Monday morning is Sunday evening Eastern, so a "start of week" full recompute kicked off Sunday night bills at peak from its first request.

The fix

One line at the top of the crontab:

TZ=Asia/Shanghai
0 12 * * 1-5  /usr/local/bin/reindex

Write the schedule in the timezone of whoever is billing you. For systemd the equivalent is an explicit timezone on the timer:

[Timer]
OnCalendar=Mon-Fri 12:00
Timezone=Asia/Shanghai

Do not hardcode the converted UTC times instead. US daylight saving shifts twice a year, so a hand-converted "02:00 UTC" quietly becomes wrong every spring and autumn. Pinning the timezone makes the conversion someone else's problem.

Two things I had to fix after the cron itself.

Long jobs straddle the boundary. A job starting at 11:00 Beijing and running two hours pays off-peak for one hour and peak for the next. Starting it an hour later puts the whole run in the cheap band.

Retry queues quietly move work into peak. Failures pile up overnight and get drained when someone comes in and restarts the consumer, which is exactly the expensive window. That cost never surfaces in a dashboard grouped by model, because the model did not change.

Caching matters more than scheduling

Moving a job out of peak saves half. Caching is the bigger multiplier: an off-peak cache hit is ¥0.15 per million input tokens against ¥9 for a peak cache miss, a spread of 60x once both axes stack.

The two multiply, so you do not have to choose. But if you only have time for one, stabilize your prompt prefix first and move the cron second.

This only applies where the vendor actually prices by time of day. Most APIs charge the same around the clock, so check before you build scheduling logic around it.

Prices here are from DeepSeek's official pricing page, checked 21 September 2026. The longer Chinese version, with the full timezone table, is on my own price-comparison site: https://www.llmabacus.com/articles/off-peak-pricing-timezone-trap

I built that site because price tables go stale without ever throwing an error.

Cache API drops the fragment, so every chunk I stored was the same entry

szp2005 — Fri, 18 Sep 2026 02:13:44 +0000

Our highest-quality model tier never once worked in production. From the day it shipped, every attempt died with the same line:

ERROR_CODE: 7, Failed to load model because protobuf parsing failed

I read that as an out-of-memory symptom and went hunting for memory. The error had already ruled that out and I wasn't listening.

Why memory was a believable story

The tier is genuinely big: 388 MB gzipped, 445 MB after decompression. We had been burned once already by holding the compressed buffer and the decompressed result at the same time, which peaked near 830 MB and killed the tab every time. So when a second failure turned up on the same tier, "too big for the device" fit the shape of what I thought I knew. A previous bug that looked similar makes the new one feel explained before you've looked at it.

What should have stopped me was the clock. Loading and running this thing takes tens of seconds. The failures came back in two or three. A job dying far faster than it could possibly finish is not running out of anything, because it never got started.

What was actually happening

We cache the model in chunks of 32 MB, then write a small manifest last, so that seeing a manifest means the chunks are all there. The keys looked like this:

const chunkKey = (cacheKey, part) => `${cacheKey}#${part}`;
// key#0, key#1, ... key#meta

The Cache API strips the URL fragment. It does it on put and on match, so key#0, key#7 and key#meta are one entry, not three. Every chunk write overwrote the one before it. The manifest goes in last, so what survived was a JSON blob of under thirty bytes.

Then the top of our load path does a plain lookup with no fragment at all:

const cached = await cache.match(cacheKey);

Which hits, because there was only ever one entry. So we handed ONNX Runtime a manifest, and it told us, accurately, that those bytes were not a protobuf.

Every layer here behaved as documented and nothing threw. The writes reported success and the read reported a hit. The parser was the first thing in the whole chain with an opinion about what the bytes actually contained.

The fix, and the gate behind it

Path segments instead of fragments:

const chunkKey = (cacheKey, part) => `${cacheKey}/part/${part}`;

That fixes this bug. It doesn't fix the class of bug, because the cache can still hand you truncated or evicted bytes through no fault of your keys. So there's a second check before anything reaches the parser:

const looksLikeOnnx = (bytes) =>
  bytes.byteLength > 1024 * 1024 && bytes[0] === 0x08;

ONNX is protobuf, and its first field is ir_version, a field-1 varint, so the first byte has to be 0x08. Add a size floor and a tiny manifest can never masquerade as a model again. When the check fails we delete the entry and treat it as a miss, which costs a re-download. I'll take the re-download over feeding questionable bytes to a parser and then reading its error message as gospel about my hardware.

If you cache anything in chunks, it's worth checking your own code for the same shape. Keep # out of cache keys entirely. After writing, read back and count the entries you expect, since overwrites are silent and successful. And validate a magic byte plus a size floor before cached bytes reach a parser.

The part I keep thinking about isn't the fragment rule. That one is in the spec and I could have looked it up any time. It's that I spent weeks treating a symptom as a resource problem when the duration of the failure ruled that out on the first day. A fast failure and a slow failure tell you different things about where the work stopped, and I only knew how to read one of them.

I build koutuxia, a background remover that runs the model in your browser, which is how I met this one.

A /24 where every address is flagged is weaker evidence, not stronger

szp2005 — Wed, 16 Sep 2026 02:10:01 +0000

A few months ago I wrote here about merging eight IP reputation feeds into one score, and I ended by asking what people do with the /24 neighbor signal. Nobody had a clean answer, so I built it. Then it lied to me, and the way it lied was more interesting than the feature.

The idea seems sound. If the address you're checking sits in a /24 where most of the other addresses are known VPN exits or sit on a spam blocklist, that range is probably being handled as a range by whoever is filtering. Signup forms and fraud rules do CIDR bans constantly. So the neighbor picture is real context even when the address itself looks clean.

I implemented it as a ratio: scan all 256 addresses in the /24 against a local offline list, count how many carry a flag, raise a floor on the score when that share crosses a threshold. Below a quarter it does nothing, past a quarter the floor is 40, past half it's 50. I capped it there on purpose, because a bad neighborhood is not a bad address.

Where it broke

The first version scored 1.19.0.5 and reported 256 of 256 neighbors flagged, verdict toxic. Maximum contamination, perfect signal.

Except there are no 256 neighbors. Spamhaus DROP lists 1.19.0.0/16 as one hijacked network, in one line. My scan expanded that line into thousands of addresses and then dutifully reported that every one of them was independently suspicious. The address already carried its own abuse flag from that same list entry. So one fact got counted as a direct hit on the address, and then again as 256 corroborating witnesses.

That isn't evidence stacking, it's one witness wearing 256 hats.

The tell is that the signal runs backwards. A /24 where 60 addresses are flagged by 60 separate entries really is 60 independent observations. A /24 where all 256 are flagged is almost always one observation about the whole range, and the fuller the coverage, the likelier that's what happened.

There was a second, dumber version of the same mistake. I had host-level evidence (an address appearing on three independent blocklists, or answering as an open proxy) counted into the neighbor numerator. That's evidence about one machine misbehaving, dragged in to convict the people next door. It also made the UI argue with itself: the score up top said high risk while the map below drew that address's own cell bright green.

The fix and what it costs

The check turned out to be one function. Is this /24 fully covered by a single entry in the list?

/** Is [a,b] fully contained in ONE range? A /24 painted by one wide CIDR is a
 *  range-level label, not 256 independent bad neighbors. */
function fullyCovered(ranges: [number, number][], a: number, b: number): boolean {
  let lo = 0, hi = ranges.length - 1;
  while (lo <= hi) {
    const mid = (lo + hi) >> 1;
    const [s, e] = ranges[mid];
    if (b < s) hi = mid - 1;
    else if (a > e) lo = mid + 1;
    else return s <= a && e >= b; // the matched entry swallows the whole block
  }
  return false;
}

const net = ipInt - (ipInt & 255);
const blanket = fullyCovered(VPN, net, net + 255) || fullyCovered(ABUSE, net, net + 255);

When blanket is true the neighbor floor is skipped. The address keeps whatever flag it earned on its own and gets nothing extra for the company it keeps. Host-level evidence moved into its own counter that the neighbor ratio never reads.

You can watch both halves from outside without logging in:

curl -s 'https://ipok.io/api/segment?ip=1.19.0.5' | jq .summary
# flagged 256 of 256, verdict "toxic"

curl -s 'https://ipok.io/api/ip?ip=1.19.0.5' | jq '.riskBreakdown.floors'
# only the address's own abuser floor. No neighbor floor at all.

curl -s 'https://ipok.io/api/ip?ip=89.149.52.9' | jq '.riskBreakdown.floors'
# block floor 40, bucket "contextual". 116 flagged, from many separate entries

The cost is that fullyCovered trusts the list to arrive merged and sorted. If a source emits a /24 as two adjacent halves, the block reads as non-blanket and the double count comes back for that range. Merging at build time covers the sources I pull, but it's an assumption rather than a guarantee, and I'd rather say that than pretend the rule is airtight.

The other thing I didn't solve is recency. A neighbor flagged last week and one flagged last spring count the same. Weighting by age is the obvious next move, I don't have a decay curve I can defend, so the flat count stays.

If you run range reputation anywhere, I'd like to know whether you dedupe at ingest instead. Handling it at scoring time still feels like the wrong layer to me.

I build ipok.io, a free IP reputation checker that shows this breakdown instead of one number.

A stale price never throws, so we made freshness a build failure

szp2005 — Mon, 14 Sep 2026 15:27:06 +0000

A hardcoded unit price never throws. It won't turn a test red. It just quietly becomes false on some Tuesday, and you hear about it from a customer.

I keep a price comparison table for LLM APIs: 57 models across 16 vendors, in one JSON file. The change log next to it is the part worth looking at. It holds 28 records so far this year, and once you drop the launches and the deprecations, 14 of them actually moved a unit price.

The magnitude is what got my attention. For the entries where I could compute the input-price delta, the median change was 60%, and two came in at 200%. At that size, calling the table "a bit out of date" is just a politer way of saying it's wrong. A monthly estimate built on last quarter's numbers isn't off by a rounding error.

The field that made it visible

Every vendor entry carries two extra fields: lastVerified, the date someone last read that vendor's official pricing page, and verifyMethod, how they read it.

{ "name": "Baidu", "lastVerified": "2026-06-05", "verifyMethod": "monitored" }

Sort the 16 by date and a correlation falls out. The seven on auto_official, meaning a scraper reads the vendor's own page, all sit within 24 days. The nine on monitored, meaning a human is supposed to remember, run back to 2026-06-05. That is 101 days. It isn't a forgotten week, it's a standing condition, and no amount of good intentions has ever fixed it.

Report the floor, not the max

The tempting way to show freshness is max(lastVerified). Today that renders as this morning's date and implies the whole table was checked today, while two vendors sit three months back.

So the public number is the oldest date instead, with coverage reported separately against a two-week window:

const freshnessWindowDays = 14;
const freshVendorCount = dates.filter((d) => d >= cutoff).length; // 8 of 16

Fifty percent. It is an unflattering number to publish, and it's the only version that makes anyone go move those two vendors onto the scraper. If a freshness metric takes its reading from whichever record you happened to touch most recently, it will flatter you every time.

Make the build fail

Timestamps don't help prose. Once the price sync started running daily, sentences in the comparison pages reading "Model X (¥a in / ¥b out)" kept their old numbers while the JSON moved underneath them. tsc cannot see that. Neither can review-by-reading.

Two scripts now run in prebuild. One diffs every "model ¥in/¥out" phrase in the copy against the JSON and reports drift. The other rejects any hardcoded ¥1.00-style literal on the pricing page outright, so the figure has to be derived from the data.

I earned that second gate the embarrassing way. Our trust page twice shipped "verbatim" quotes of vendor privacy policies that were not in the linked source. The word verbatim is now a banned regex in that file, and the page may link to a policy but may not characterize what it says.

The gate then caught the article I wrote about the gate. I had typed "13 models" into a sentence with no date anywhere in it, and the check refused to build until I anchored it, on the grounds that a sentence about history should keep its historical number while a sentence about today has to match the table. Fair.

Four steps, no dependencies

Give every record a lastVerified and a source URL. A number missing either one doesn't get committed.
Aggregate to the floor. Publish the oldest date, plus coverage inside a window you pick on purpose.
Derive prose numbers from the data. Where you can't, regex-scan the copy for literals in prebuild and exit non-zero on a hit.
Timestamp the derived inputs separately. 40 of the 57 models carry their own cached-input price, and the USD vendors get converted at an FX rate (6.7156 today) that moves even when the vendor's dollar price doesn't.

The table still goes stale. It just says so now.

I build llmabacus.com, where this table is the product; the Chinese version of this writeup has the full per-vendor breakdown.

Twelve of thirteen stale docs were kept alive only by each other

szp2005 — Fri, 11 Sep 2026 02:12:31 +0000

My coding agents are prolific note-takers. Every non-trivial session leaves a PLAN.md, a SUMMARY.md, a HANDOFF.md, sometimes a FINAL_REPORT_V2.md. Across 36 repos on this machine there are about 1,200 markdown files, and I could not tell you which ones anybody still opens.

The obvious cleanup is a glob and a date filter:

find . -name 'PLAN*.md' -o -name 'SUMMARY*.md' -mtime +30 -delete

I did not run that, because I already knew what it would hit. A PLAN.md from May can still be the file a README points at when it explains why the approach changed. Age alone says nothing about whether a file is load-bearing.

The rule that looked right

So the next rule: keep anything that something else links to. Count inbound references, and if the count is above zero, the file is still wired into the repo. Old and unreferenced means safe to move.

That rule survived about a day. Here is the scan that killed it, from a trading repo with a reports/ folder:

reports/E_F_G_RESULTS.md              116d  stale  refs=1
reports/FINAL_HONEST_PLAN.md          116d  stale  refs=1
reports/FUNDING_HARVEST_REPORT.md     116d  stale  refs=2
reports/HONEST_FINDINGS.md            116d  stale  refs=1
reports/J_SUMMARY.md                  114d  stale  refs=1
reports/FINAL_REPORT.md               114d  stale  refs=6
... 13 files, all 114-116 days old, every one with refs > 0

Every file passed the "someone links to it" test. Then I traced where the links came from:

grep -rl "J_SUMMARY\.md" --exclude-dir=.git .
# reports/L1_AUDIT_REPORT.md

L1_AUDIT_REPORT.md is in the same folder and is just as dead. I walked all thirteen. Twelve of them had every single inbound link coming from another file inside reports/. The folder was citing itself in a circle. Only FINAL_REPORT.md had a reference from outside: mql5/README.md, and a Python script that actually runs.

A reference count of 1 was not evidence that anyone used the file. It was evidence that the agent wrote two files in the same session and made one mention the other.

Three grades, and only one of them moves

I stopped trying to find a rule that decides. The scanner now sorts into three buckets and hands the ambiguous one back to me:

h.grade = h.ageDays <= days   ? 'active'   // touched recently, leave it
        : h.refs > 0          ? 'stale'    // old but linked, I read these by hand
        :                       'orphan';  // old and unlinked, movable

Across those 36 repos: 687 active, 172 stale, 176 orphan. The 172 in the middle are exactly the files the glob would have eaten, and the ones the reference rule would have blessed. They are not a category the tool can resolve, so it doesn't pretend to.

Orphans get moved rather than deleted. fs.renameSync puts them in .mdsweep/trash/<timestamp>/ next to a manifest that records every original path. mdsweep undo renames them back. Nothing in your tree gets unlinked; the only rmSync in the codebase targets the trash directory itself after a full restore.

What I would not put on a slide

The same scan flags 1,035 of 1,199 files, which is 86%, and that number is almost meaningless. One of the three detection signals is "untracked by git," so a repo with a messy working tree lights up wholesale. The flag rate measures my hygiene, not the tool's precision. The grading is the part that earns its keep.

The stale bucket is also a genuine dead end, not a staging area. The reports folder above proves the tool cannot distinguish a live citation cluster from a dead one, and I do not think heuristics will get there. Thirteen files is a two-minute read for a human. Thirteen hundred would not be, and I have no answer for that yet.

It is a single .mjs file, no dependencies, Node 18+. It reads your repo and prints a table; you have to pass --apply before it touches anything.

git clone https://github.com/szp2005/mdsweep
node mdsweep/bin/mdsweep.mjs scan ~/code/your-repo

I built it (szp2005/mdsweep) for my own repos, and the reports folder above is why the middle bucket exists at all. If your agents also write more markdown than you read, the scan is read-only, so the worst case is that you find out your repos were fine.

A bot fleet rewrote its headers three times in 48 hours, so I stopped matching signatures

szp2005 — Wed, 09 Sep 2026 02:16:38 +0000

Early September, the explicit-lookup endpoint on my IP-reputation site started seeing tens of thousands of distinct source IPs a day, and most of them queried exactly once. Every request asked about its own address. The sources were residential and mobile ISPs across Europe: BT, Vodafone Italy, Orange, Charter, Telenor.

That shape is somebody validating a residential proxy pool against my endpoint, one exit at a time. And it walks straight past per-IP daily quotas, because a quota caps depth and this has no depth. Thirty thousand exits at one query each sits under any per-IP limit you'd want to set, while spending a full upstream fan-out per request. AbuseIPDB's daily allowance was gone in three hours.

Matching the signature buys you about a day and a half

First attempt: block the signature. wrangler tail showed the fleet's requests were internally impossible under Fetch Metadata. They announced sec-fetch-mode: navigate with dest: document and site: none, which is what an address-bar navigation looks like, while carrying accept: application/json, text/plain, */*, which is axios's default. They carried an Origin, which a GET navigation never has. And a Referer, while claiming site: none, meaning no initiator at all.

I shipped a rule for exactly that. Thirty-six hours later the fleet came back as mode: cors, site: same-origin, still axios's Accept, with a Referer copied from a real page request. A clean impersonation of my own page's fetch, and it went through to full upstream. A day after that, version three: a complete top-level navigation, text/html, no Origin, no Referer.

Signature matching was always going to lose this race. Every rule I ship works as a free oracle for them: flip one header, retry, and the response says which header it was.

What failed worse was my own shortlist of obvious tells. I had three candidates out of the tail logs: connection: Keep-Alive on HTTP/2, which is illegal; x-real-ip and x-forwarded-proto; and a missing priority header. All three turned out to be present or absent on real human traffic in the same minute. Cloudflare and my adapter layer put them there. Ship those and I'd have been 403ing real people without ever finding out. A detection rule has to be falsified against known-good samples before it goes anywhere near a block.

Contradictions instead of signatures

The checks that survived all name a pair of headers the browser generates from one source, which therefore cannot disagree.

const mode = (h.get("sec-fetch-mode") ?? "").toLowerCase();
const site = (h.get("sec-fetch-site") ?? "").toLowerCase();
const accept = (h.get("accept") ?? "").toLowerCase();
const ua = h.get("user-agent") ?? "";

// 1. Claims a top-level navigation, carries things only XHR/axios sends.
const forgedNavigation =
  mode === "navigate" &&
  (accept.includes("application/json") ||
    h.get("origin") !== null ||
    (site === "none" && (h.get("referer") ?? "") !== ""));

// 2. Claims a page fetch, carries navigation-only headers.
//    Browsers never set either one on fetch()/XHR.
const forgedFetch =
  (mode === "cors" || mode === "no-cors" || mode === "same-origin") &&
  (h.has("sec-fetch-user") || h.has("upgrade-insecure-requests"));

// 3. The UA's OS disagrees with the client hint. Windows and Mac only:
//    Android desktop-mode reports Linux, iOS WebKit sends no hints at all.
const platform = (h.get("sec-ch-ua-platform") ?? "").replace(/"/g, "").toLowerCase();
const platformMismatch =
  platform !== "" &&
  ((ua.includes("Windows NT") && platform !== "windows") ||
    (ua.includes("Macintosh") && platform !== "macos"));

The third one caught version three. Its UA said Windows NT 10.0 and its sec-ch-ua-platform said "macOS". Real Chrome derives both from the same place; UA reduction froze the version numbers, it didn't touch the OS. Android and iOS stay out of the check rather than getting guessed at. Eighteen tests cover this file and about half are negative controls taken from real user agents.

The second change mattered more. I had been treating this as one trust bit, first-party or not, which means copying the first-party shape once wins you unlimited upstream, and everything else shares a single pool the fleet can drain in any disguise it likes. Now each client kind gets its own hourly upstream bucket: official app, browser extension, cross-site webapp, address-bar navigation, plain script, suspect. Impersonating the app starves the app pool and nothing else. Total upstream is bounded by the sum of the buckets no matter which costume turns up.

What it costs

This is not a cryptographic boundary and I don't want it read as one. A script can produce headers that pass every check above; version two already did. What's gone is the free ride. Each rewrite now costs them a calibration pass against a real browser.

Real users do get caught. Someone behind an HTTP/1.1 proxy that strips Fetch Metadata lands in the suspect bucket. That's why suspect is a small pool rather than a 403: a self-contradiction is the only thing that earns a hard rejection, and a header that is merely absent never does. The page-proof path works the same way. A same-origin fetch that can't produce a Turnstile token isn't refused; it drops into an unproved pool, because Turnstile fails to load for plenty of real people.

The fleet's independent-IP count fell from around four thousand to roughly a hundred the next day, with no sign of it resurfacing in a new disguise. I read that as a retreat, not a win. Version four is coming, and the point of the buckets is that version four is capped before I've noticed it.

I build ipok.io, the IP checker all of this runs on.

Reconciling 8 IP-reputation feeds into one verdict: averaging is the wrong default

szp2005 — Fri, 19 Jun 2026 08:42:18 +0000

Wire more than one IP-reputation source into a risk check and sooner or later they disagree. One feed says the IP is a residential ISP address. Another calls it a datacenter VPN. A blocklist says it relayed spam last week. A geolocation provider says it's clean and unremarkable.

The naive move is to normalize everything to 0–100 and average it. I did that first. It produces a number that's wrong in specific, reproducible ways, and on top of that a number nobody can act on. The moment a verdict matters, someone asks "why is this 0.62?" and the average has no answer.

The version I landed on after the averaging one kept embarrassing me reads as a decision log. Every rule below is there because some real IP broke the version before it.

Why averaging fails: three concrete failure modes

1. Low-precision sources dominate the consensus. Some feeds label entire datacenter /16 blocks as "proxy" or "VPN" wholesale. They're cheap and high-recall, so they're noisy. Average them in and a plain Hetzner or Linode box that two of these feeds tagged as "proxy" gets dragged up into mid-risk territory, even when every higher-precision source says it's just hosting. You've shipped a scorer that cries wolf on half of AWS.

2. A single low-confidence report flips a binary feed. Abuse-report databases are community-fed. If your rule is flagged = (totalReports > 0), one retaliatory or mistaken report marks an address as a known abuser. I watched 8.8.8.8, Google Public DNS, come back as "abuser" because somebody somewhere reported it once. Averaging doesn't save you. It buries the bad signal under the good ones for most IPs and then surfaces it on the unlucky ones.

3. Averaging dilutes the one source that matters most. A live spam-relay listing, or membership in a Tor exit-node list, sits close to ground truth. Seven geolocation feeds saying "nothing unusual" should not be allowed to wash that out. Risk signals aren't symmetric, and an average pretends they are.

The model: visible per-source verdicts, asymmetric floors

Two ideas did most of the work.

The first: don't collapse to one opaque number. Keep every source's verdict and show it as its own line item. Which feed, what it claimed, what signal category it falls under (datacenter, residential proxy, Tor exit, active abuser, spam-list hit). Then whoever consumes the score decides whether a given flag matters for their case. A Tor-exit listing is disqualifying for a signup flow and irrelevant for a geo-IP cache.

The second: keep a weighted baseline, but let signal type set a hard floor. The aggregate starts as a precision-weighted average, and then certain confirmed signals impose a minimum the average can't pull below.

Tor exit node (confirmed)      → floor 90
Dedicated proxy/VPN (consensus)→ floor 65
Confirmed abuser               → floor 55
Datacenter / hosting           → floor 35

A floor says: if this signal is present, the score can't drop below X no matter how many geo feeds call the address clean. Swapping type-driven floors in for the pure average is the one change that got the output to line up with what an analyst would actually conclude.

The rules that keep the floors honest

A floor is only as trustworthy as the boolean that trips it. Each of these earned its place by killing a specific false positive.

Proxy/VPN needs consensus from dedicated sources. The low-precision general feed never gets to establish a proxy verdict on its own. On datacenter ranges I require ≥2 dedicated (purpose-built proxy/VPN) sources to agree. On residential ranges ≥1 is enough, since a residential proxy is rarer and so means more when a specialized feed flags it. Hetzner and Linode fall back to "hosting 35" instead of a phantom "proxy 65," and a real consumer-ISP proxy still trips.
Tighten the noisy binary feed. An abuse listing now requires score ≥ 25 AND reports ≥ 3 (or ≥2 distinct reporters), and the address can't be on the provider's own allowlist. 8.8.8.8 stops being an abuser.
Whitelist known infrastructure ASNs. Google, Cloudflare, and the like suppress the abuser and hosting floors. A CDN edge node isn't a threat, and you don't want your scorer picking fights with the backbone of the internet.
Treat ASN reputation as standalone evidence. A small set of autonomous systems are VPN/proxy-only businesses: M247, Mullvad, Proton, a handful of others. For these, membership alone settles it, with no cross-source consensus needed, because the network operator's identity is the signal. This recovers the case where one feed alone recognizes a niche VPN that the consensus rule above would otherwise suppress.
Add a hard, independent signal: DNSBL over DoH. I query a handful of DNS blocklists, reversing the octets against each zone and going over DNS-over-HTTPS so it runs from an edge runtime. A hit there is close to ground truth and leans on nobody's opaque vendor score.
Short-circuit reserved and CGNAT ranges before scoring. CGNAT (100.64.0.0/10), TEST-NET, benchmark, multicast, and the IPv6 equivalents get an explicit "reserved, here's the category" response rather than going through the pipeline to be mislabeled. It also keeps thousands of carrier-NAT users behind one exit from being scored as a shared proxy.

Make the verdict auditable, not just displayable

If I had to press one point on anyone building this, it's this: emit the breakdown as structured data, not just the final number. Every lookup returns each source's contribution, the weighted average before floors, which floors fired and why, and the final value. You get debuggability out of it. When a verdict looks wrong, the breakdown tells you at a glance whether it was a bad weight, a floor that shouldn't have fired, or thin data. You also let the user overrule you: the person reading the score can tell whether it rests on one thin signal or a five-way consensus, and judge for their own case. A black-box number forces all-or-nothing, trust it blind or throw it out.

What I still haven't solved well

A few open problems, since anyone who's done this for real will have opinions.

CGNAT and mobile carriers are the worst of them. Shared-exit NAT and a residential proxy pool throw off the same surface signal: many users, one IP. Short-circuiting the reserved CGNAT block helps, but carriers also use public ranges that look identical to a proxy from the outside. I flag uncertainty rather than guess, and I still don't have a clean discriminator.

Then there's absence of evidence versus evidence of absence. For smaller regional ISPs the databases run thin. "No source flagged it" reads as "clean" when it often just means "nobody has data." Right now I surface coverage, the count of how many sources had any opinion at all, next to the verdict. I'm not convinced that's enough.

Last, the residential-versus-datacenter split. When two classifiers disagree on the same IP I show both labels and leave it unresolved. Whether a confidence-weighted merge beats preserving the raw disagreement, I genuinely don't know.

If you've run reputation scoring at scale, I'd value your take on the /24 neighbor signal (contamination ratio weighted by flag recency?) and on the residential/datacenter conflict above.

The scorer described here runs behind ipok.io, a free, no-login IP reputation checker that shows the per-source breakdown instead of a single number. The CLI is MIT on GitHub. Happy to go deeper on any of the data-source quirks in the comments.

Making "files never leave your browser" verifiable with DevTools and CSP

szp2005 — Mon, 15 Jun 2026 03:23:04 +0000

"Files never leave your browser" is becoming standard copy for PDF tools, image editors, and document converters. But a trust claim and a verifiable fact are different things. Here's how to turn "zero upload" into something any user can audit in about two minutes, and how to enforce it at the browser level so it isn't just a promise.

Step 1: Read the Network panel

Open DevTools → Network, enable "Disable cache", reload. While processing a file, filter by "Fetch/XHR" and "Doc". A genuinely client-side tool should show only HTML/CSS/JS/WASM asset loads — no POST requests, no GETs carrying file content in query parameters.

The non-obvious trap: third-party analytics, Google Fonts, and CDNs all show up as outbound requests. If you claim zero uploads, those count too. The honest move is to self-host fonts and scripts and drop analytics entirely, so the request list is genuinely short enough to eyeball.

The Network panel is the human-readable check. The next part is what actually makes it hold.

Step 2: Enforce egress with CSP `connect-src`

This is the piece people get backwards, so it's worth stating precisely.

CSP's connect-src is an egress allowlist the browser enforces before the request is sent. A fetch/XHR to an origin that isn't on the list is blocked by the browser and never leaves the machine. You'll see it fail in the console as a CSP violation, with no entry in the Network tab going out to that origin.

This includes no-cors requests. no-cors is sometimes assumed to be an escape hatch, but it isn't one for this purpose. All no-cors does is let you issue a cross-origin request while making the response opaque (you can't read the body). It does not bypass connect-src: if the target origin isn't in your connect-src allowlist, the no-cors request is blocked exactly the same way — it never goes out. So you can't smuggle a file out to a third party with no-cors under a tight CSP.

That's what makes CSP the actual proof, not just documentation. Tighten connect-src to 'self' (or an explicit list of the few endpoints you genuinely need), and any code path that tries to ship data to another origin — yours, a third party's, an injected script's — is stopped by the browser. A realistic policy:

connect-src 'self';
font-src 'self';
script-src 'self' 'wasm-unsafe-eval';
img-src 'self' data:;

Note 'wasm-unsafe-eval' rather than the broader 'unsafe-eval' — modern browsers support the narrower directive for instantiating WASM, so there's no reason to grant full eval.

With that in place, the Network panel check from Step 1 stops being "trust me, the list is short" and becomes "the browser will refuse to send anything I didn't whitelist, and here's the empty list to confirm it."

Step 3 (optional): Content-Length as a sanity check

If you want a quick gut-check rather than reasoning about the allowlist, clear the Network panel before triggering processing, then sum the Size column afterward. If the total is nowhere near the original file size, no file content went out. This also catches chunked-transfer or WebSocket approaches that a naive "look for a POST" scan might miss. It's a weaker check than the CSP guarantee, but it's fast and visual.

A Service Worker doesn't replace CSP

A Service Worker can intercept fetches and is useful for offline caching, but it's not the egress boundary — it's first-party code that can be bypassed or simply not cover a code path, and it does nothing about requests that don't route through it. CSP connect-src is enforced by the browser regardless of your application code. Use a Service Worker for caching if you want; rely on CSP for the "can't exfiltrate" guarantee.

What this looks like in practice

I built a PDF tool this way (moguanpdf.com, my own project — mentioning it only because it's a live example you can poke at). The classic tools (compress, merge, split, OCR, watermark, encrypt/decrypt, etc.) run entirely in-browser via WASM + pdf.js. Open DevTools → Network while processing a file and you'll see only .wasm, .js, and .css loads, no POST, no analytics. The one server-side exception is the AI features (summarize/translate/Q&A), which send extracted text rather than the file, and the UI says so. I'd encourage auditing it the same way you'd audit anyone else's — that's the whole point.

The broader point

If your users handle contracts, medical records, or financial documents, "open DevTools and follow these steps, and here's the CSP that guarantees it" is a stronger statement than any privacy policy. The Network panel shows users an empty list; connect-src 'self' is the reason the list stays empty. A tool that can't survive that audit probably shouldn't be making the claim.