DEV Community: Derrick Zhou

We re-priced six weeks of our own AI coding-agent usage. The "obvious" saving was 5.5x too big.

Derrick Zhou — Fri, 16 Oct 2026 16:17:37 +0000

Over 46 days (35 of them active), one person's coding agent made 61,955 requests. There was no invoice for this exercise - a real client audit starts by reconciling to one - so we did what you do without one: we re-priced every request at the vendor's public, dated price sheet (retrieved 2026-10-16) and asked where the money would go. Every dollar figure below is API-equivalent, not what anyone was billed.

The total came to $7,882. Three things in it surprised us.

1. Almost all of it is re-reading

66% of the cost was cache reads, and 99% of input-side tokens were cache hits. Output - the thing people optimise prompts for - was 12%. Spend is driven by how long the context is x how many turns run on it, and one project accounted for 63% of it. The lever is context length and session hygiene, not a cleverer prompt.

Cost category	Share
Cache reads (re-reading the existing context every turn)	66%
1-hour cache writes	20%
Output (incl. thinking)	12%
5-minute cache writes	2%
Fresh input	~0%

2. The headline saving was 5.5x too big

Newer model versions are cheaper per token. If you re-price every request that ran on an older version at the newer version's rates, you "save" $1,625 (20.6%). But most of those requests were made before the newer version existed. Counting only requests made after it was available: $293 (3.7%). A saving you couldn't have taken at the time isn't a saving.

3. The expensive-looking setting was the right one

85% of cache-write tokens used the 1-hour prompt cache, which costs more to write than the 5-minute cache. We tested the opposite: if every cache write had used the 5-minute cache, anything idle for more than five minutes would have to be re-written at write prices. Only 2.5% of cache-read tokens came after such a gap, but those requests carried very large contexts. Net result: the 5-minute cache would have cost $1,781 more (+22.6%). Keep the 1-hour cache. (And moving subagent work to a cheaper model saved $62 - not worth the quality risk.)

What this is, and isn't

It is a re-pricing from token counters, not realised savings. We did not evaluate output quality. Subagent streams were merged when measuring idle gaps, so those gaps look shorter than they were. The aggregated CSVs in the repo let you check the totals, and the scripts reproduce them from your own usage logs.

Run it on your own logs

The scripts are open source (MIT), deterministic, and make no LLM or network calls:

https://github.com/zbl1998-sdjn/llm-spend-audit-toolkit

extract per-request usage (token counters only) from your coding-agent logs
price it by category from a dated public price sheet
test "move to the newer model" with an available-at-the-time check
test the 5-minute vs 1-hour cache counterfactual

How we'd do this for your bill

Export-only. Billing/usage exports - no API keys, no prompts, no production access.
Deterministic analysis - scripts on your numbers, not a model reading your data.
Reconcile first: recomputed spend must match your invoice within +/-3% before any saving is counted.
Only conservative, de-duplicated, available-at-the-time findings - a lower bound, with the formula next to each number.

If you spend $3,000+/month on LLM APIs and want a second pair of eyes: hello@currawongweb.com.

Disclosure: the analysis scripts and this write-up were produced with AI assistance (Claude Code).

Measuring China's Company Registry from the Outside: A Technical Writeup

Derrick Zhou — Mon, 07 Sep 2026 05:55:09 +0000

How we designed paired-control experiments to measure government registry accessibility — and what the data shows.

If you've ever built a tool that queries a government database, you know the pain: no API, no docs, no SLA. Now imagine that database is China's national company registry, serves 160 million business records, and actively distinguishes between human browsers and everything else.

We run Currawong Web, a supplier verification service. Over the past few months we ran controlled experiments measuring what happens when you try to access Chinese government registries from outside China. We published 20 datasets on Harvard Dataverse — all CC-licensed, all reproducible. Here's the technical story.

The problem: a registry that fights back

China's national company registry (国家企业信用信息公示系统, or NECIPS) holds the canonical registration data for every company in the country. It's the source of truth for business licence details, legal representative, registered capital, and operational status.

It also serves a JavaScript challenge to every visitor.

This isn't a simple cookie check. The challenge evaluates your client environment — we observed different outcomes depending on browser fingerprint characteristics even from the same IP address. The system appears to use these signals to decide whether to serve data or return an empty response.

Experiment design

We wanted to measure this systematically, not just anecdote our way through it. So we designed a paired-control experiment:

Variables:

Client profile matrix: 5 distinct browser fingerprint configurations, ranging from a vanilla Chrome profile to headless configurations
Entry point matrix: direct URL, search-engine referral, and portal navigation paths
Network location: 2 mainland China networks + 1 overseas comparison point

Protocol:

3 rounds per combination
Same target company in each round
Record: HTTP status, JS challenge presence, data payload presence, time to response
Control: a known-accessible domestic business portal queried in the same session

This gave us a structured matrix of observations rather than a single pass/fail answer.

What the JS challenge actually does

We're deliberately not publishing bypass methods — that would undermine a legitimate anti-scraping system. But the technical observation is worth documenting:

Initial page load returns a minimal HTML shell with an inline script
The script performs environment checks — we observed it probing properties that differ between headless and headed browsers
On passing, a cookie is set and the page reloads with actual content
On failing, the page either loops or returns empty content — no error message, no HTTP error code

The subtlety is that this isn't binary. Some client profiles pass the challenge but receive degraded results. The registry appears to have multiple tiers of trust, not just allow/block.

Results: what works and what doesn't

From our 106-company English-name lookup dataset:

End-to-end success rate was low. Most failures occurred before the verification step — at the name-matching stage, not the access stage.
Network location matters, but less than client profile. A well-configured browser from overseas performed better than a poorly configured one from inside China.
Certificate registries vary wildly. We tested 8 official sources (CCC, CQC, CFDA, and others) with 240 observations. Some answer reliably from any location. Others are effectively unreachable without a China-side session.

The registration-change problem

One dataset tracked 264 manufacturers classified as national "Little Giant" firms (专精特新"小巨人"). We compared registration snapshots over time and found that key fields — operational status, registered capital, business scope — shift more frequently than most due-diligence processes assume.

A supplier check from 6 months ago may already be outdated. This isn't a data-quality issue — it's a feature of a dynamic registry system that reflects real corporate changes. The implication for anyone building verification tooling is that you need a freshness model, not a cache.

Alibaba vs. 1688: identity field comparison

We also compared supplier identity fields between Alibaba.com (international) and 1688.com (domestic) for 94 companies present on both platforms. The registered company names, addresses, and representative details don't always match — not because of fraud, but because of legitimate differences in how companies present themselves for international vs. domestic trade.

This matters for entity resolution. If your verification system tries to match a supplier's Alibaba profile against the government registry using the English trade name, you'll get a different result than matching via the Chinese registered name on 1688.

Lessons for builders

If you're building tools that interact with government data sources — in any country — a few patterns from this work apply:

Measure access, don't assume it. We started with the assumption that the registry was accessible. The data showed a more nuanced picture.
Design for failure tiers, not binary up/down. A system that returns empty content with HTTP 200 is harder to handle than one that returns 403.
Client fingerprint matters more than you think. We saw different outcomes from the same network with different browser configurations.
Build a freshness model. Government records change. Your verification is a snapshot, not a permanent fact.
Separate name-matching from access. Our biggest source of failure wasn't "can't reach the registry" — it was "can't find the company by its English name."

Data availability

All 20 datasets are on Harvard Dataverse with DOIs and CC licences. Download them, reproduce the experiments, challenge the methodology. That's the point.

Currawong Web research datasets on Harvard Dataverse
currawongweb.com — our supplier verification service

Derrick Zhou builds supplier verification tools at Currawong Web. Previously worked in cross-border trade operations.

How China's company registration code uses ISO 7064 check digits (and why it matters for importers)

Derrick Zhou — Fri, 04 Sep 2026 04:31:33 +0000

If you've ever sourced products from China, you've probably seen an 18-character code on your supplier's business licence. It looks something like this:

91440300MA5FJK2W30

This is the Unified Social Credit Identifier (USCI) — China's equivalent of a company registration number. And buried in its last character is a check digit based on ISO 7064 Mod 31-3.

What the code tells you

The 18 characters encode specific information:

Position 1: Registration authority type
Position 2: Organization category
Positions 3-9: Regional code (maps to province/city/district)
Positions 10-17: Organization identifier
Position 18: Check digit (ISO 7064 Mod 31-3)

The check digit math

The validation uses a weighted sum mod 31, with weights cycling through powers of 3. Here's a JavaScript implementation:

function validateUSCI(code) {
  const CHARS = '0123456789ABCDEFGHJKLMNPQRTUWXY';
  const WEIGHTS = [1,3,9,27,19,26,16,17,20,29,25,13,8,24,10,30,28];

  let sum = 0;
  for (let i = 0; i < 17; i++) {
    sum += CHARS.indexOf(code[i]) * WEIGHTS[i];
  }
  const remainder = sum % 31;
  const expected = remainder === 0 ? '0' : CHARS[31 - remainder];
  return expected === code[17];
}

Note: USCI uses a custom character set — no I, O, S, V, Z (to avoid visual confusion with 1, 0, 5, U, 2).

How well does it work?

I ran an exhaustive test: for every position in every sample code, I substituted every possible character and checked whether the check digit caught the error.

Result: 100% detection of single-character substitutions across 2.9 million simulated errors.

For comparison, the US VIN (Vehicle Identification Number) check digit only catches 92.5% of single-character errors.

The full dataset is on Zenodo: https://zenodo.org/records/15589531

Why this matters

If a supplier sends you a business licence with a typo in the registration code — or a completely fabricated code — the check digit catches it instantly, before you spend time on a manual lookup.

Some other findings from our research:

42.5% of NHTSA-registered Chinese manufacturers can't be found by English name alone in China's registry
25.4% of China's "little giant" manufacturers don't have import/export in their registered business scope
53.4% of those manufacturers have changed their company name at least once

I built a free tool that does this validation plus a manual cross-reference against official Chinese registry data:

https://currawongweb.com/verify/

The research papers and datasets are all open access. Happy to answer questions about the methodology.