DEV Community: hc_xshh

Measuring error in support AI, and what accuracy hides

hc_xshh — Fri, 09 Oct 2026 07:01:48 +0000

The way I test a support or ticketing system is against a task book, not a demo. The number people
ask for afterwards is accuracy, and I have stopped handing that over on its own: on every realistic
test set I have built, the average was the least informative thing in the results file.

What follows is the method I use now, plus a run on public data so the numbers can be checked.

Five failure modes, five different bills

A support model fails in at least five ways, and they do not cost the same.

Fabrication. The reply asserts something absent from the policy or the record: a fee that does
not exist, a wrong refund window, an invented delivery date. This is what people call
hallucination. The taxonomy I lean on, OlaBench, splits it into four sub-types — factual
hallucination, misuse of retrieved results, relevance hallucination, and logical inconsistency
(OlaBench, arXiv:2510.22143v3, §3.1; v1 25 Oct 2025, v3 25
May 2026, retrieved 9 Oct 2026). A sentence that reads well and is false costs money, and the cost
usually arrives months later.

Missed detection. The ticket contains a legal threat, a regulator's name, a safety issue or a
fraud signal, and the system files it as routine. Nothing false was said. The failure is that no
human ever reads it. On a scoring sheet this often counts as a correct classification, because the
model did pick a queue that exists.

Misrouting. The reply is reasonable and the queue is wrong, so a differently-skilled team
applies its own policy. The measurable cost is time to resolution and repeat contact.

Out-of-scope answers. The system answers a question it was never built for — tax, legal
advice, another provider's product. The content may be accurate. The exposure is regulatory.

Refusal. The system declines, loops, or hands off. There is no answer, so there is no error to
score. This one gets tracked as a transfer or containment rate and drops out of the error count
entirely.

Failure	What is wrong	Where the cost lands	Commonly reported as
Fabrication	the content	refunds, goodwill, disputes	hallucination rate
Missed detection	nothing	escalation, legal, safety	almost nothing
Misrouting	the destination	time to resolution, repeats	accuracy
Out of scope	the remit	compliance	rarely measured
Refusal	nothing	churn, containment	transfer rate

One accuracy figure blends these five at whatever ratio the sample happens to contain, and that
ratio is set by whoever picked the sample.

What I ran

I needed a routing task with a ground-truth label and text a model would really see. Public
complaint data has both.

The US CFPB publishes its Consumer Complaint Database under CC0 (CFPB Consumer Complaint
Database, retrieved 9 Oct
2026); the search API's own metadata reports 18,274,023 records, license CC0, last updated
2026-10-08 (API metadata,
retrieved 9 Oct 2026).

The JSON search endpoint returns 15 fields and no narrative (field
reference, retrieved 9 Oct 2026). That is new: the
September 2026 release removed complaint narratives from the database (CFPB release
notes, Release 24, September 2026). So I took
the text from a Hugging Face mirror instead, BEE-spoke-data/consumer-finance-complaints (dataset
card, CC0, mirror last
modified 29 Dec 2025); its has-text config holds 1,689,573 rows (split
sizes,
retrieved 9 Oct 2026).

Task: read the narrative only, predict the product queue. Ground truth: the product label the CFPB
publishes. I drew 3,894 complaints from it. The oldest is dated 2015-03-20, the newest
2024-01-04.

The label set changed under the data

The raw product field holds 17 distinct strings in this sample, and they are not 17 products. The
date ranges are what give it away.

Product string as published	Rows	Received, first → last in this sample
Credit reporting, credit repair services, or other personal consumer reports	1,892	2017-04-24 → 2023-08-24
Debt collection	547	2015-03-20 → 2023-12-18
Credit card or prepaid card	267	2017-04-24 → 2023-08-21
Mortgage	248	2015-04-21 → 2023-11-02
Credit reporting or other personal consumer reports	245	2023-08-26 → 2024-01-04
Checking or savings account	195	2017-04-24 → 2023-11-21
Credit reporting	92	2015-04-17 → 2017-04-09
Student loan	85	2015-10-06 → 2023-11-13
Money transfer, virtual currency, or money service	79	2017-08-08 → 2023-11-13
Vehicle loan or lease	75	2017-04-24 → 2023-11-01
Credit card	68	2015-04-06 → 2023-12-22
Payday loan, title loan, or personal loan	41	2017-04-24 → 2023-06-20
Bank account or service	34	2015-04-04 → 2017-01-31
Consumer Loan	19	2015-03-25 → 2017-02-03
Payday loan	3	2015-10-08 → 2017-02-24
Money transfers	2	2015-07-17 → 2015-12-05
Payday loan, title loan, personal loan, or advance loan	2	2023-09-20 → 2023-10-06

Read the dates down the table. Bank account or service last appears here on 2017-01-31, and
Checking or savings account first appears on 2017-04-24. Three more strings end in 2017 and their
successors start the same year. The three credit-reporting strings sit end to end: 2015 to 2017,
2017 to 2023, 2023 into 2024. Same category, renamed.

I collapsed the 17 strings into 9 categories before scoring anything. The mapping is in the script,
applied in one place rather than inferred per row. Without that step an accuracy compares a 2016
row and a 2023 row whose label sets do not line up, and the model gets credit or blame for the
taxonomy.

The live database disagrees with the mirror about which names are current. Aggregated over
complaints received in 2026, the CFPB API returns 11 product strings, with Credit card and
Prepaid card listed separately and no Credit card or prepaid card at all (product aggregation,
complaints received 2026-01-01
onward,
retrieved 9 Oct 2026). I did not reconcile the two taxonomies.

Three ways one accuracy figure misleads

Imbalance. After collapsing, the sample looks like this:

Collapsed category	Rows	Share
Credit reporting	2,229	57.2%
Debt collection	547	14.0%
Credit card or prepaid card	335	8.6%
Mortgage	248	6.4%
Checking or savings account	229	5.9%
Student loan	85	2.2%
Money transfer or virtual currency	81	2.1%
Vehicle loan or lease	75	1.9%
Personal / payday / title loan	65	1.7%

A predictor that answers "credit reporting" for every ticket scores 0.572 here. That is a
constant, and it sits close enough to a real model's score to be mistaken for one.

Sample selection. Same data, same model, two splits:

Split	Test n	Accuracy	Macro F1	Credit-reporting share of test set
Random 60/40	1,558	0.756	0.428	57.1%
Chronological, split at 2022-04-21	1,560	0.832	0.377	74.0%

The chronological run scores 7.6 points higher while getting worse on most categories. The test
set became more concentrated in the biggest class, and the dominant-class predictor rides that
concentration up. Anyone reporting the 0.832 as an improvement after retraining would be reading
their own sampling as progress.

Coverage. Sort the test set by the model's confidence and score only the top slice:

Coverage	Tickets scored	Accuracy on that slice
100%	1,558	0.756
75%	1,168	0.854
50%	779	0.904
25%	389	0.900
10%	155	0.897

The 0.904 at half coverage is a real number computed on held-out data, and published alone it
misdescribes the system by 15 points. Note where it stops moving: from 50% coverage down to 10%,
accuracy drifts from 0.904 to 0.897, so the model's confidence and its correctness come apart on
the tail. That tail is where the misroutes are.

Underneath the average, the per-category picture on the random split:

Category	Test n	Recall	Precision
Credit reporting	889	0.879	0.886
Debt collection	225	0.631	0.637
Credit card or prepaid card	129	0.760	0.430
Mortgage	114	0.860	0.737
Checking or savings account	93	0.548	0.607
Money transfer or virtual currency	32	0.000	0.000
Student loan	29	0.276	0.889
Vehicle loan or lease	29	0.000	0.000
Personal / payday / title loan	18	0.000	0.000

Three categories are never once predicted correctly. Accuracy is 0.756. Macro F1 is 0.428. The
distance between those two is the honest headline for this model.

Pulling the high-risk errors out of the average

The useful published idea here is OlaBench's risk axis, Critical Business Risk Rate. It counts only
responses that inappropriately assert one of four things, each a high-stakes failure that may
trigger compliance exposure, user disputes or reputational damage: admitting platform liability
(618 test cases), misidentifying the ICS role (228), overcommitting (138), and disparaging
individuals or merchants (16) (OlaBench,
arXiv:2510.22143v3, §3.1 and Table 1; 25 May 2026, retrieved 9
Oct 2026). It is reported as its own number, beside the hallucination rate.

The shape of that is what to copy: choose failures whose consequences differ in kind, count them
separately, publish both, and never average them.

For the routing test I defined three tiers, and I chose them:

critical — a complaint about funds or account access (checking or savings, money transfer) lands in the reporting queue
material — a credit or loan dispute lands in a different loan or reporting family
routine — a misroute inside the same family

Tier	Random split	Chronological split
Critical	7 / 1,558 = 0.4%	11 / 1,560 = 0.7%
Material	43 / 1,558 = 2.8%	28 / 1,560 = 1.8%
Routine	330 / 1,558 = 21.2%	223 / 1,560 = 14.3%

The two splits swap places depending on which tier you read: the one with the prettier accuracy
hides a critical error rate almost twice as high.

Published work also shows how far the same named metric can move when the population changes. The
OlaBench paper reports a critical business risk rate of 8.7% for its OlaMind-Stage-2 model on the
benchmark, and a critical business risk rate below 0.05% in daily manual annotation of live
dialogues after launch (OlaBench, arXiv:2510.22143v3, §5.2 and
Table 3; 25 May 2026, retrieved 9 Oct 2026). Both are the same metric, measured on different
populations with different annotators. Quoting one without the other is a choice.

How these numbers were produced

Data. 3,894 complaints from a CC0 mirror of the CFPB Consumer Complaint Database (config has-text, 1,689,573 rows). The draw is 40 pages of 100 consecutive rows at random offsets in the split, deduplicated by complaint ID, seed 20261009. Rows with a narrative under 80 characters were dropped. It is a clustered draw, not an independent one.
Label hygiene. 17 published product strings collapsed to 9 categories using the date ranges in the table above. The mapping is written out in the script, not inferred per row.
Model. Multinomial naive Bayes over word unigrams and bigrams, Laplace smoothing α = 1, features seen at least twice in training. Python standard library only.
Splits. Random 60/40 with seed 7; chronological split at the 60th percentile of the received-date order, which lands on 2022-04-21.
Selective accuracy. Test rows sorted by the model's maximum posterior probability, top k scored.
Every number in the tables above is printed by that one script over that sample.
Deliberate choice. No language model appears in this pipeline, including the scoring. A measurement instrument that is itself a model carries its own error, and OlaBench publishes the size of its own: its judge agrees with human annotators at 91.7% on risk identification and 82.6% on hallucination detection, over 5,000 human-annotated instances (OlaBench, arXiv:2510.22143v3, §3.3 and Table 2; 25 May 2026, retrieved 9 Oct 2026). A judge that disagrees with people 8% of the time on the risk axis puts a floor under everything else you can measure with it.

What I could not check

Whether the mirror's product strings match the live database's current taxonomy. The mirror's rows use names the live API no longer returns for complaints received in 2026. I collapsed by date range and did not reconcile the two.
Whether the mirror is complete. Its files are timestamped December 2025 and the newest complaint in my 3,894-row sample is dated 2024-01-04. I did not verify whether later records exist in it.
Whether complaints published with a narrative are representative of all complaints. Narratives appeared only with consent, so every number above sits on that consenting subset.
Whether this sample's class mix reflects the population. Credit reporting is 57.2% of the sample and about 82% of the live database: 14,978,722 of 18,274,023 records carry one of the three credit-reporting strings (product aggregation, retrieved 9 Oct 2026). Most of the gap is the mirror's date cap.
How noisy the product label is. It is chosen by the consumer at submission, not assigned by an expert, and I treated it as ground truth because companies route on it. If it is noisy, my error rates are a floor, not a ceiling.
Whether a published tiering exists for complaint-routing consequences. I could not find one, so the three tiers are mine. The OlaBench categories are a different kind of thing: they score what a reply asserts about liability and commitment, and they do not classify misroutes.
Whether error rates vary with company size, state, or complaint age. A stratified rate is the next thing to compute.
The naive Bayes model is a floor. A trained transformer would score higher on the same task. The run was to see the shape of the error distribution, and a better model changes the level without changing the shape.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.

The Chinese open-weights release timeline, dated

hc_xshh — Fri, 09 Oct 2026 07:01:16 +0000

This is a list of dates, not an argument. Every row is a model whose weights were
published for anyone to download, with a date I could trace back to the organization that
published it, a parameter count as stated by that organization, and a link.

Most timelines of this kind are written from memory or from coverage, which is why they drift.
I built this one from vendor pages, papers and Hugging Face's API. This revision leaves the table
at 67 rows: seven are new, one of them because an entry I dropped in the first pass turns out to
be open-weights after all. The dropped list at the end has eleven entries, each with a reason.

How to read this timeline

Open weights only. A release is in the table only if the organization published
downloadable weights. API-only and hosted-only models are out, including flagship ones:
Qwen3-Max, the served ERNIE models, Kimi's hosted variants, DeepSeek's API-only models.

A date I could trace. The Date column has two kinds of value. A plain date is the date on
the organization's own dated page — a research blog post, a news post, a release page, an
accepted paper. A date marked † is the Hugging Face repository creation timestamp in UTC,
read from the Hugging Face API on 2026-10-09, used when the vendor had no dated page I could
read. The two can differ by a few days, and that is usually preparation rather than a
different release: DeepSeek-V3's weights repository was created 2024-12-25 12:52 UTC and the
announcement is dated 2024-12-26.

Parameter counts come from the vendor, or they are blank. Total parameters with activated
parameters for mixture-of-experts models, as stated on the announcement, the model card, or
the repository holding the same weights. A family that ships many sizes gets a range. Where
none of the vendor's pages for that release states a count, the cell is — rather than a
number carried over from a sibling model, even when the lineage makes the number obvious.

One link per row, to the vendor or the weight repository. No aggregator links, no
news coverage. That makes most rows single-source by construction: each cites the vendor's own
statement about its own release, and every † row is single-source by definition.

Scope. Language models and the flagship multimodal lines that carry the same brand and
weights: Qwen3-VL, Qwen3-Omni, MiniMax-M3. Pure image, video and speech models are out of scope.

When the vendor's page is client-rendered

Two of the labs whose releases I date most often publish announcements as a page that ships no
text to a plain HTTP request. z.ai's blog returns a 598-byte HTML shell that loads a JavaScript
bundle; qwen.ai's blog returns a shell that fetches its content after load. Both render fine in
a browser, which is what a reader clicking the link sees.

For z.ai I did read something: the date string sits inside the page's own bundle, so the bundle
is where I checked GLM-4.5 (2025-07-28),
GLM-4.6 (2025-09-30), GLM-4.7
(2025-12-22) and GLM-5 (2026-02-12). That is weaker evidence than a
rendered page, and it is why GLM-5.2 stays out: its bundle contains
2026-06-16 and no other date, and a date visible only inside a build artifact is not one I will
print as sourced.

Qwen's older blog carries the full text and a date; the newer qwen.ai copies do not. So the
three Qwen3-* rows dated from qwen.ai in the first pass now cite the weight repository and
carry a †.

2023

Q1–Q2

Model	Date	Parameters	Source
ChatGLM-6B	2023-03-13 `†`	6.2B	THUDM/chatglm-6b
Baichuan-7B	2023-06-13 `†`	7B	baichuan-inc/Baichuan-7B
ChatGLM2-6B	2023-06-24 `†`	`—`	THUDM/chatglm2-6b

Q3–Q4

Model	Date	Parameters	Source
Qwen-7B	2023-08-03 `†`	7B	Qwen/Qwen-7B-Chat
Baichuan 2	2023-09-19	7B, 13B	arXiv:2309.10305
ChatGLM3-6B	2023-10-25 `†`	`—`	THUDM/chatglm3-6b
Yi-34B	2023-11-01 `†`	34B	01-ai/Yi-34B
DeepSeek Coder	2023-11-01 `†`	1.3B–33B	deepseek-ai/deepseek-coder-33b-instruct
DeepSeek LLM	2023-11-29 `†`	7B, 67B	deepseek-ai/DeepSeek-LLM-67B-Chat

Baichuan 2 is the only 2023 row dated by a paper: arXiv:2309.10305 is dated 2023-09-19,
while its weight repositories appear earlier, on 2023-08-30 †, so the paper is the single
source for that date. The two ChatGLM cells are blank because their cards do not state a count:
6.2 billion is on the ChatGLM-6B card and not on the cards of its two successors, and copying
it across is the habit that makes timelines of this kind drift.

2024

Q1

Model	Date	Parameters	Source
Qwen1.5	2024-02-04	0.5B–110B	Qwen blog

Qwen1.5 was in the dropped list in the first pass, because I looked for it on the new blog and
found nothing readable. The old blog still carries the post, dated 2024-02-04, listing six
sizes plus 110B.

Q2–Q3

Model	Date	Parameters	Source
DeepSeek-V2	2024-05-07	236B total, 21B active	arXiv:2405.04434
GLM-4-9B	2024-06-04 `†`	9B	zai-org/GLM-4-9B-Chat
Qwen2	2024-06-07	0.5B–72B	Qwen blog
Qwen2-VL	2024-08-29	2B, 7B, 72B	Qwen blog
DeepSeek-V2.5	2024-09-05 `†`	`—`	deepseek-ai/DeepSeek-V2.5
Qwen2.5	2024-09-19	0.5B–72B	Qwen blog

Q4

Model	Date	Parameters	Source
Hunyuan-Large	2024-10-22 `†`	389B total, 52B active	tencent/Hunyuan-Large
Qwen2.5-Coder	2024-11-06 `†`	0.5B–32B	Qwen/Qwen2.5-Coder-32B-Instruct
DeepSeek-V2.5-1210	2024-12-10	`—`	DeepSeek changelog
DeepSeek-V3	2024-12-26	671B total, 37B active	DeepSeek news

The DeepSeek point releases inside a model line are dated on DeepSeek's own changelog, one page
per release. Hunyuan-Large's 389B/52B comes from
arXiv:2411.02265, submitted 2024-11-04, three weeks after
the weights appeared.

2025

Q1

Model	Date	Parameters	Source
MiniMax-Text-01	2025-01-14	456B total, 45.9B active	arXiv:2501.08313
DeepSeek-R1	2025-01-20	671B total, 37B active	DeepSeek news
Qwen2.5-VL	2025-01-27 `†`	3B, 7B, 72B	Qwen/Qwen2.5-VL-72B-Instruct
QwQ-32B	2025-03-06	32B	Qwen blog
DeepSeek-V3-0324	2025-03-25	671B total, 37B active	DeepSeek changelog

The two DeepSeek updates here do not restate a parameter count on their own changelog pages;
the cells carry the count from the repositories that hold those weights, which are the V3 and
R1 repositories listed above.

Q2

Model	Date	Parameters	Source
Qwen3	2025-04-29	0.6B–235B	Qwen blog
DeepSeek-R1-0528	2025-05-28	671B total, 37B active	DeepSeek changelog
MiniCPM4-8B	2025-06-05 `†`	8B	openbmb/MiniCPM4-8B
MiniMax-M1	2025-06-16	456B total, 45.9B active	arXiv:2506.13585
Hunyuan-A13B	2025-06-27	80B total, 13B active	Tencent-Hunyuan/Hunyuan-A13B
ERNIE 4.5	2025-06-30	0.3B–300B; flagship 300B/47B	ERNIE blog

Q3

Model	Date	Parameters	Source
Kimi K2	2025-07-11 `†`	1T total, 32B active	moonshotai/Kimi-K2-Instruct
Qwen3-Coder	2025-07-22	480B total, 35B active	Qwen blog
GLM-4.5	2025-07-28	355B total, 32B active	z.ai blog
Step-3	2025-07-31	321B total, 38B active	StepFun research
Seed-OSS-36B	2025-08-21	36B	ByteDance Seed blog
DeepSeek-V3.1	2025-08-21 `†`	`—`	deepseek-ai/DeepSeek-V3.1
LongCat-Flash-Chat	2025-08-29 `†`	560B total, 18.6B–31.3B active	meituan-longcat/LongCat-Flash-Chat
Qwen3-Next-80B-A3B	2025-09-09 `†`	80B total, 3B active	Qwen/Qwen3-Next-80B-A3B-Instruct
Ling-flash-2.0	2025-09-17 `†`	100B total, 6.1B active	inclusionAI/Ling-flash-2.0
Qwen3-Omni-30B-A3B	2025-09-20 `†`	30B total, 3B active	Qwen/Qwen3-Omni-30B-A3B-Instruct
Qwen3-VL	2025-09-22 `†`	235B total, 22B active	Qwen/Qwen3-VL-235B-A22B-Instruct
DeepSeek-V3.2-Exp	2025-09-29	`—`	DeepSeek news
GLM-4.6	2025-09-30	`—`	z.ai blog

Q4

Model	Date	Parameters	Source
Ling-1T	2025-10-02 `†`	1T total, 50B active	inclusionAI/Ling-1T
DeepSeek-OCR	2025-10-17 `†`	`—`	deepseek-ai/DeepSeek-OCR
LongCat-Flash-Omni	2025-10-23 `†`	560B total, 27B active	meituan-longcat/LongCat-Flash-Omni
MiniMax-M2	2025-10-27	230B total, 10B active	MiniMax blog
Kimi K2 Thinking	2025-11-04 `†`	`—`	moonshotai/Kimi-K2-Thinking
DeepSeek-V3.2	2025-12-01	`—`	DeepSeek news
GLM-4.7	2025-12-22	`—`	z.ai blog

2026

Q1

Model	Date	Parameters	Source
GLM-4.7-Flash	2026-01-19 `†`	30B total, 3B active	zai-org/GLM-4.7-Flash
Step-3.5-Flash	2026-02-01 `†`	196B total, 11B active	stepfun-ai/Step-3.5-Flash
MiniMax-M2.5	2026-02-12	`—`	MiniMax news
GLM-5	2026-02-12	744B total, 40B active	z.ai blog
Qwen3.5-397B-A17B	2026-02-16	397B total, 17B active	Alibaba press release

Q2

Model	Date	Parameters	Source
MiniMax-M2.7	2026-04-09 `†`	`—`	MiniMaxAI/MiniMax-M2.7
Kimi K2.6	2026-04-14 `†`	1T total, 32B active	moonshotai/Kimi-K2.6
DeepSeek-V4 (Pro and Flash)	2026-04-24	Pro 1.6T total / 49B active; Flash 284B total / 13B active	DeepSeek news
Step 3.7 Flash	2026-05-23 `†`	198B total, 11B active	stepfun-ai/Step-3.7-Flash
MiniMax-M3	2026-06-01	~428B total, ~23B active	MiniMax blog

The DeepSeek-V4 row now carries both counts; the Flash model's 284B total is stated on the same
announcement page as the Pro figures. Step 3.7 Flash moved to a † date: its GitHub repository
has no releases, and the page I first cited carries a creation timestamp rather than a release
date.

Q3

Model	Date	Parameters	Source
LongCat-2.0	2026-07-05 `†`	1.6T total, ~48B active	meituan-longcat/LongCat-2.0
Hunyuan Hy3	2026-07-06	295B total, 21B active	Tencent newsroom
Qwen3.8	2026-08-05 `†`	27B; 2.4T total / 95B active	Qwen/Qwen3.8-2.4T-A95B
DeepSeek-V4-Pro GA	2026-08-13	1.6T total, 49B active	DeepSeek changelog
DeepSeek-V4-Flash-Vision-Exp	2026-08-21	`—`	DeepSeek changelog
DeepSeek-V4.1-Flash	2026-09-10	552B total; 8B active for input, 16B for output	DeepSeek changelog

Hy3 is the entry whose status changed in this revision. In the first pass I dropped it because
the page I found did not say whether weights were published. It does: Hy3 is open-sourced under
Apache 2.0 with weights on Hugging Face, and Tencent's newsroom names the parameter counts. The
V4-Pro GA row repeats the count from the April preview announcement, because the GA page does
not restate it. The Qwen3.8 row is dated by the repository of the 27B model, the first of the
line to appear; the flagship 2.4T-A95B repository was created three days later, and Qwen's own
announcement page is one of the client-rendered ones described above.

Two rows elsewhere disagree with third-party timelines for the same reason: LongCat-2.0's
repository was created 2026-07-05 while secondary coverage puts its launch at the end of June,
and DeepSeek-V4-Flash's repository was created 2026-04-22, two days before the announcement
page.

What changed in this revision

Seven rows were added and three cells changed, listed because the edit history is the point of
a table like this:

Qwen1.5 promoted into 2024 Q1 (2024-02-04), after finding the dated post on the old Qwen blog.
Hunyuan Hy3 promoted into 2026 Q3 (2026-07-06). It was dropped in error.
Four DeepSeek point releases added: V2.5-1210 (2024-12-10), V3-0324 (2025-03-25), R1-0528 (2025-05-28) and V4-Pro GA (2026-08-13). All four are dated on DeepSeek's own changelog, the same source as V3.2 and V3.2-Exp.
Qwen3.8 added (2026-08-05 †), which the first pass omitted entirely.
Two ChatGLM parameter cells blanked. The ChatGLM2-6B and ChatGLM3-6B cards do not state a count, so the cells are now —.
DeepSeek-V4-Flash gained its total. The row said "Flash 13B active" and dropped the 284B total, which the same page states.

Three rows changed source or date type for the same structural reason: the Qwen3-Next,
Qwen3-Omni and Step 3.7 Flash rows now cite a weight repository with a †, because the pages
cited in the first pass were either unreadable to a plain request or carried no release date.

How this table gets updated

The table is edited in place. Every quarter I re-read the vendor pages for the labs already
listed, then check Hugging Face for new repositories under those organizations. A release
enters the table when it has a date and a link; until then it sits in the dropped list, with
the reason.

Two rules keep it stable: I do not replace a † date with a later one unless the vendor
publishes its own dated page, and I do not remove a superseded row.

The current table has 67 entries. Twenty-three of them fall in the twelve months from October
2025 to October 2026. That is a count of this table and nothing more; it is not a claim about
the field, because the table only holds releases I could date.

What I could not check

Eleven candidates were dropped, for these reasons:

Yi-1.5 (May 2024) — the weight repository (01-ai/Yi-1.5-34B) was created 2024-05-11 †, and I could not date the announcement itself.
InternLM2 and InternLM2.5 — the weight repositories (internlm/internlm2-7b, internlm/internlm2_5-7b-chat) look like renamed predecessors, so the creation timestamp does not mark the release.
MiniCPM 1 and 2 — same problem; the repository (openbmb/MiniCPM-2B-sft-bf16) is now a monorepo for a whole series.
Baichuan 3 and 4 — I could not find weight artifacts at all.
ERNIE 5.0 and ERNIE 5.1 — Baidu's blog dates them 2026-02-06 and 2026-05-09 (ERNIE 5.0, ERNIE 5.1) and describes ERNIE 5.0 as a 2.4-trillion-parameter model, but I found no open-weight repository for either.
Kimi K3 — the model card (moonshotai/Kimi-K3) carries the full architecture table (2.8T total, 104B activated) and a license, but no release date. The repository timestamp is 2026-06-13 and secondary coverage says mid-July. I could not reconcile that.
Kimi K2.5 — same shape of problem: the weight repository timestamp (moonshotai/Kimi-K2.5) is 2026-01-01 while the launch is reported at the end of January.
GLM-5.2 — the post is client-rendered and the only date string in its bundle is 2026-06-16. I am not willing to print that as the release date.
DeepSeek-V3.1-Terminus — a mid-cycle rename with a 2025-09-22 † repository (deepseek-ai/DeepSeek-V3.1-Terminus); including it would have double-counted the V3.1 line.
Qwen-Image-2.1 — a dated weight repository (Qwen/Qwen-Image-2.1, 2026-09-14 †) but an image model, outside this table's scope by the rule stated at the top.
The Step-Audio line — the same, for speech. The repositories exist (stepfun-ai/Step-Audio-R1.1) and I did not date them, because they would need their own table with its own scope.

Three other limits on this table:

The † timestamps are preparation times, not launch times. A repository can be created days before the announcement, and from outside I cannot see whether weights were uploaded at once or in pieces. Where the gap is large I noted it above the table.
The dates are the vendor's own. No release date here has been confirmed by a second source, and one link per release is deliberate: a vendor correcting itself is the signal worth keeping, and coverage repeating the vendor is not a second source.
License differences are not reflected. Apache-2.0, MIT and the vendor-specific licenses Kimi, MiniMax and LongCat ship under are not the same permission. Each row links to the page that states its license, and for Hy3 that page states Apache 2.0.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.

Why there is no Western mini program

hc_xshh — Fri, 09 Oct 2026 07:00:37 +0000

The usual version of this question is about super apps, and it has been answered at length by people with better data than mine; mine is narrower. A mini program is a small bundle of code that runs inside somebody else's application, and the question is which parts of that arrangement exist in what Apple and Google ship.

I read the vendors' own documentation for WeChat Mini Programs, Apple App Clips, Google Play Instant and Progressive Web Apps, and compared them on five dimensions: install and size, identity, payment, entry point, distribution and review.

One mechanism carries most of the answer. A mini program brings neither its own user account nor its own checkout. It borrows both from the application hosting it.

The five dimensions, side by side

	WeChat Mini Program	Progressive web app	Native app (iOS/Android)	App Clip (iOS)
Install and size	Runs inside WeChat. Main package 2 MB maximum, all packages together 30 MB (20 MB for programs developed by a third-party provider) (WeChat subpackages, read 2026-10-09)	No package at all. Chrome offers install after HTTPS plus a manifest carrying a name, 192 px and 512 px icons, `start_url` and a display mode (web.dev install criteria, read 2026-10-09)	Full binary from the store. Apple states the App Store limits the size of apps installable over a mobile connection and gives no number on that page (Apple, read 2026-10-09); Google states a compressed download limit of 200 MB for apps published as app bundles (Google, read 2026-10-09)	10 MB uncompressed on iOS 15 and earlier, 15 MB on iOS 16 and earlier, 100 MB on iOS 17 or later under conditions (Apple, read 2026-10-09)
Identity	`openid` per mini program, `unionid` shared across every app under one Open Platform account. Both come from `wx.login` plus `code2Session`, which WeChat documents as returning the UnionID "without user authorization" (login, UnionID, read 2026-10-09)	Each origin keeps its own account. The browser hands nothing to a site silently	Account per app. Sign in with Apple where the app offers it, as an explicit step by the user (Apple, read 2026-10-09)	Sign in with Apple, the keychain and CloudKit, shared with the parent app (Apple, read 2026-10-09)
Payment	WeChat Pay. A merchant number is bound to the mini program's AppID, at most 50 AppIDs per merchant number (WeChat Pay, page updated 2025-07-02). Virtual goods must go through the mini program virtual-payment channel, where "the platform charges a technical service fee" (WeChat, read 2026-10-09)	Card and wallet APIs called by the merchant, on the merchant's own acquiring contract	In-app purchase is required to unlock features. Apple's guidelines name QR codes among the mechanisms that may not be used instead (Apple, read 2026-10-09)	Apple's in-app purchase. Hosts in the Mini Apps Partner Program "earn 85% of qualifying In-App Purchase sales within qualifying mini apps" (Apple, read 2026-10-09)
Entry	Documented entry paths carry IDs: 1011 scan a QR code, 1012 long-press an image, 1013 pick a code from the album, 1023 the Android home-screen icon, 1005 and 1006 search boxes, 1026 the nearby list, 1183 search inside the PC WeChat mini program panel (WeChat scene values, read 2026-10-09)	A URL, a search result, or a home-screen shortcut the user adds by hand. On iOS there is no install prompt at all (web.dev, read 2026-10-09)	Store search and the home-screen icon	An App Clip Code, NFC tag or QR code at a physical location; Siri suggestions; Maps; Messages; a Smart App Banner on a website in Safari (Apple, read 2026-10-09)
Distribution and review	Published from the mini program console. Virtual payment requires a certified entity: an enterprise, institution or individual merchant (WeChat, read 2026-10-09)	Nothing is submitted. It is HTTPS plus a manifest	Store review against the App Review Guidelines	No listing of its own. It ships inside a full app, which the App Clip documentation says "must include the same functionality as the App Clip" (Apple, read 2026-10-09); Guideline 2.5.16(a) adds that all App Clip features must be in the main app binary and that "App Clips cannot contain advertising" (Apple, read 2026-10-09)

The Android equivalent is gone. "Starting December 2025, Instant Apps cannot be published through Google Play, and all Google Play services Instant APIs will no longer work" (Google Play Instant, last updated 2026-06-24).

Identity arrives before the first screen

The WeChat login flow is one call on the client and one on the server. wx.login returns a code, the server exchanges it through code2Session, and the reply carries an openid for that user in that mini program, a unionid and a session key (WeChat, read 2026-10-09).

The UnionID page says what this costs the user: the developer gets it "without user authorization" (WeChat, read 2026-10-09). No phone number, no password, no consent sheet. The openid is scoped to one mini program; the unionid is identical across every mobile app, website app, official account and mini program bound to the same Open Platform account, so a merchant with several surfaces sees one person.

Compare the alternatives. On the web, an origin cannot read an identifier out of the browser; it asks the user to sign in and then owns a credential to protect. On iOS, an App Clip can use Sign in with Apple and the keychain, which Apple's documentation points developers at sharing with the full app, but those are technologies an app opts into rather than an identifier handed over at launch.

That is why the first screen of a mini program is the product. Onboarding was paid for at install time, by the host.

Payment is a binding between two accounts

Paying inside a mini program does not mean the mini program holds money. WeChat Pay binds a merchant number to the mini program's AppID. One merchant number can bind at most 50 AppIDs, the binding starts on the merchant side and is confirmed from the mini program side, and once established cannot be unbound (WeChat Pay, page updated 2025-07-02). The rail and the code package are joined by an account relationship neither side can create alone.

Virtual goods get a second layer. The documentation is blunt: virtual currency, unlocked features, subscription content, paid services, tips and virtual gifts "require integration with Mini Program's virtual payment system for both purchase and payment", and the platform charges a technical service fee on the amount (WeChat, read 2026-10-09). Physical goods go through ordinary WeChat Pay; digital ones go through the host's channel, with the host's cut.

Apple's version of that cut is recent and documented. The Mini Apps Partner Program was announced on 13 November 2025 (Apple, 2025-11-13): host apps carrying mini apps can join, earn 85 percent of qualifying in-app purchase sales inside those mini apps, and must use Apple's in-app purchase system for them (Apple, read 2026-10-09). Admission is not automatic: a host needs the Advanced Commerce API and a manifest describing itself and its mini apps.

Apple's App Review Guidelines still require in-app purchase to unlock features or functionality, and the same sentence lists QR codes among the mechanisms that cannot substitute for it (Apple, read 2026-10-09). What changed, on 1 May 2025, is that Guidelines 3.1.1, 3.1.1(a), 3.1.3 and 3.1.3(a) were updated for the United States storefront after a court decision about buttons and external links (Apple, 2025-05-01).

The QR code is the offline switch

A WeChat developer does not have to choose between a printed code and a link shared in a chat. The official scene-value table lists both, with IDs: 1011 scanning a QR code, 1012 long-pressing an image, 1013 picking one from the album, 1023 the Android home-screen icon, 1005 and 1006 the two search boxes, 1026 the nearby list, 1183 search inside the PC WeChat mini program panel (WeChat, read 2026-10-09).

Two details make the printed code cheap. Codes come from an API, and WeChat states every generated mini program code is permanently valid. The "one item, one code" interface has no quantity limit and needs a smaller printed area than an ordinary URL code (WeChat, read 2026-10-09). A code already printed and pointing at a URL can be configured to open a chosen page inside a mini program (WeChat, read 2026-10-09). The person scans what is already on the table.

App Clips have the same physical invocations: an App Clip Code, an NFC tag, a QR code at a physical location (Apple, read 2026-10-09). Two constraints pull the other way.

The first constraint trades size against physical entry. The 100 MB ceiling for iOS 17 or later carries four conditions: the App Clip "only supports digital invocations" and not "physical invocations such as App Clip Codes, QR codes, or NFC tags" (Apple, read 2026-10-09), it is used where a reliable connection is likely, and it "doesn't support iOS 16 and earlier". The exception Apple names is a demo link from App Store Connect, which may use the 100 MB limit and still support App Clip Codes, NFC tags and QR codes. An App Clip with a counter code stays inside the smaller limit.

The second concerns persistence. Apple's Human Interface Guidelines say App Clips "remain on the device for a limited amount of time", and that only App Clip Codes produced in App Store Connect or with Apple's own code generator are approved for use (Apple, read 2026-10-09). A merchant cannot print its own.

Who reviews it, and who is answerable

Reviews differ in kind as well as in strictness. A PWA is submitted to nobody; Chrome installs it once its manifest and HTTPS satisfy the criteria (web.dev, read 2026-10-09). An App Clip cannot be submitted alone. It ships inside a full app that must already contain the same functionality, cannot carry advertising, and is reviewed as part of that app (Apple, read 2026-10-09). A mini program is submitted inside WeChat, and the entity requirement arrives with payment rather than with the code: to sell virtual items, the program must be a certified enterprise, institution or individual merchant (WeChat, read 2026-10-09).

The commercial consequence: in the App Store, a mini-app-like product reaches users through a host that already has an account relationship and a reviewed app behind it. In WeChat, the party needing the corporate identity, the certification and the merchant binding is the mini program author.

Where the four pieces sit

In WeChat, four things a mini program depends on sit with one owner: the identity system, the payment rail, the entry surface (camera, search, chat, home screen, desktop) and the distribution channel with its review. An author plugs into a host that has all four and pays for the parts it uses.

In the Apple and Google stacks those four are held by parties with different interests. The operating system vendor issues the platform account and runs the payment system; the browser owns the entry surface for web content; the stores own distribution and review; the rail for physical goods sits with the merchant's bank relationship.

No single party there can hand all four to a third party. Apple's answer in November 2025 was to supply the missing pieces itself and keep the commission: hosts get Apple's in-app purchase for mini apps and keep 85 percent of qualifying sales, in exchange for approval, a manifest and Apple's review.

The mechanism that makes mini programs work is therefore an ownership arrangement rather than a technology gap. Reproducing it outside WeChat means finding one party that holds the users, the identity, the payment rail and the entry surface, and getting it to open all four to third-party code at a price the third party will pay. In the West, the two parties that hold those pieces chose to be the host themselves.

How I checked this

Every figure and quote comes from documentation published by the vendor it describes: WeChat's mini program and WeChat Pay docs, Apple's developer documentation, guidelines and news items, Google's Android documentation, and web.dev.
All pages were fetched on 2026-10-09. Most carry no publication date, so a date beside a source is my reading date unless the page states its own: the WeChat Pay AppID binding page (updated 2025-07-02), the Google Play Instant page (last updated 2026-06-24), Apple's updated-guidelines news item (2025-05-01), Apple's Mini Apps Partner Program news item (2025-11-13) and Tencent's write-up of the 2022 WeChat Open Class (2022-01-07).
Size limits and scene-value IDs come from the pages that state them: WeChat's subpackage page for 2 MB and 30 MB, Apple's App Clip page for the 10/15/100 MB table, WeChat's scene-value table for the ID numbers.
Google Play Instant's page would not load in a plain HTTP client, so I read it through the Internet Archive and then through a rendering fetch that returned the live page.

What I could not check

The fee WeChat charges on virtual payments. The page says a fee is charged on the payment amount and gives no percentage.
The standard WeChat Pay rate for physical goods. I found no official rate page; what I reached describes partner fee schemes and refers to a merchant rate without the base number.
The extra steps for virtual payment on iOS. WeChat's virtual payment page says iOS "requires additional activation and adaptation procedures" and points at separate documentation; I could not load that page, so I do not know whether an Apple-side charge is involved.
Whether an App Clip can take payment for physical goods through Apple Pay. Not stated on the App Clip pages I read.
Any current count of mini programs or mini-program daily users. Tencent's release discloses Weixin monthly accounts and names Mini Games and Mini Shops, but carries no mini-program count. The most recent first-party figure I found: more than 450 million daily users at the end of 2021, from Tencent's write-up of the 2022 WeChat Open Class (Tencent, 2022-01-07). That figure is four years old.
What "certified Mini Program" requires in practice, beyond the entity types named on the virtual payment page, and how long WeChat's review takes.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.

From token prices to task prices: three jobs, seven APIs

hc_xshh — Fri, 09 Oct 2026 07:00:13 +0000

Every vendor publishes a price per million tokens. Almost none publishes what a job costs; the number that decides whether a feature ships is left as arithmetic homework.

I did that arithmetic for three jobs, from first-party price lists read on 2026-10-09. The token counts are assumptions, not measurements, and they are written out below. The money is the vendor's standard-tier list price, in USD.

The three jobs

Job 1, label 1,000 support messages. Each call sends a 400-token instruction block and a 120-token message, and asks for a 15-token answer. Billed per run: 520,000 input tokens, of which 400,000 are the instruction block sent 1,000 times, plus 15,000 output tokens.

Job 2, turn a 100,000-word draft into a structured summary. Google's token guide says a token is about 4 characters and 100 tokens about 60-80 English words, putting 100,000 words at 125,000-167,000 tokens (Google token counting guide, read 2026-10-09). I used 140,000:

One shot: 140,000 tokens in, a 3,000-token structured summary out.
Map-reduce: 14 chunk calls of about 10,000 tokens each, 700 tokens of notes per chunk, then a 9,800-token reduce call. Totals: 149,800 in, 12,800 out.

Job 3, one round of tool-assisted bug fixing. Eight turns against a 20,000-token repository: system prompt, tool schemas, three files. The prompt grows about 2,500 tokens per turn as tool results come back, from 20,000 to 37,500. Cumulative billed input is 230,000 tokens, of which 192,500 are a re-sent prefix a cache can serve; output is 6,000 tokens including reasoning.

How I read the price lists

Five first-party pages, all read on 2026-10-09; the Gemini API page builds its tables client-side, so I read it in a browser.

OpenAI API pricing — standard tier
Anthropic pricing
Gemini API pricing — paid tier, introductory rates through 2026-12-31
DeepSeek Models & Pricing — off-peak column
xAI pricing

The rules I applied:

Standard tier only, unless a row says batch: the real-time tier.
Cache reads are billed at the published cached-input rate. Cache writes are billed where a vendor publishes a write price. OpenAI and Anthropic do: $2.50 per million tokens for the two frontier models here, $0.125 for the two small ones, on Anthropic's 5-minute cache. Google, DeepSeek and xAI publish no write price, so I charged zero, which flatters those three in every cached row.
In the cached rows I charge a write for every input token that is not a cache read: 400 tokens in Job 1, 37,500 in Job 3.
Reasoning tokens are output tokens. OpenAI states they are billed as output tokens (OpenAI reasoning guide, read 2026-10-09). Gemini's output price is quoted "including thinking tokens" and DeepSeek's V4.1-Flash runs in thinking mode by default.
Tool and search fees sit outside the main table.
No prompt hits a long-context threshold; the prompt-length step that does apply, Anthropic's 100,000-token rule, is below.
No aggregator site was used for any price.

What each job costs

Task	Model	Estimated cost	Assumptions	Price source (read 2026-10-09)
Job 1, no cache	gpt-6.1-sol	$1.19	standard tier; 520k in / 15k out	OpenAI
Job 1, no cache	gpt-6-luna	$0.060	standard tier; 520k in / 15k out	OpenAI
Job 1, no cache	Claude Sonnet 5.5	$1.19	standard tier; 520k in / 15k out	Anthropic
Job 1, no cache	Claude Haiku 5.5	$0.060	standard tier; 520k in / 15k out	Anthropic
Job 1, no cache	Gemini 3.8 Flash	$0.45	standard tier, introductory rate; 520k in / 15k out	Google
Job 1, no cache	DeepSeek V4.1-Flash	$0.087	off-peak window; 520k in / 15k out	DeepSeek
Job 1, no cache	Grok 4.7	$1.13	standard tier; 520k in / 15k out	xAI
Job 1, instructions cached	gpt-6.1-sol	$0.43	400k of input served from cache; one 400-token write	OpenAI
Job 1, instructions cached	gpt-6-luna	$0.024	400k of input served from cache; one 400-token write	OpenAI
Job 1, instructions cached	Claude Sonnet 5.5	$0.43	400k cached, 5-minute TTL and write	Anthropic
Job 1, instructions cached	Claude Haiku 5.5	$0.024	400k cached, prompts under 100k, 5-minute TTL	Anthropic
Job 1, instructions cached	Gemini 3.8 Flash	$0.18	400k of input served from cache, storage excluded	Google
Job 1, instructions cached	DeepSeek V4.1-Flash	$0.028	off-peak; cache hits free of a write fee	DeepSeek
Job 1, instructions cached	Grok 4.7	$0.53	400k of input served from cache	xAI
Job 2, one shot	gpt-6.1-sol	$0.31	140k in / 3k out, one call	OpenAI
Job 2, one shot	gpt-6-luna	$0.016	140k in / 3k out, one call	OpenAI
Job 2, one shot	Claude Sonnet 5.5	$0.31	140k in / 3k out, one call	Anthropic
Job 2, one shot	Claude Haiku 5.5	$0.078	140k in / 3k out, above the 100k step	Anthropic
Job 2, one shot	Gemini 3.8 Flash	$0.12	140k in / 3k out, one call	Google
Job 2, one shot	DeepSeek V4.1-Flash	$0.023	off-peak; 140k in / 3k out	DeepSeek
Job 2, one shot	Grok 4.7	$0.30	140k in / 3k out, under the 200k threshold	xAI
Job 2, map-reduce	gpt-6.1-sol	$0.43	14 chunk calls + 1 reduce call; 149.8k in / 12.8k out	OpenAI
Job 2, map-reduce	gpt-6-luna	$0.021	14 chunk calls + 1 reduce call	OpenAI
Job 2, map-reduce	Claude Sonnet 5.5	$0.43	14 chunk calls + 1 reduce call	Anthropic
Job 2, map-reduce	Claude Haiku 5.5	$0.11	15 calls, each prompt under 100k	Anthropic
Job 2, map-reduce	Gemini 3.8 Flash	$0.16	14 chunk calls + 1 reduce call	Google
Job 2, map-reduce	DeepSeek V4.1-Flash	$0.030	off-peak window, 15 calls	DeepSeek
Job 2, map-reduce	Grok 4.7	$0.38	14 chunk calls + 1 reduce call	xAI
Job 3, agent loop	gpt-6.1-sol	$0.25	8 turns; 230k in (192.5k read, 37.5k written) / 6k out	OpenAI
Job 3, agent loop	gpt-6-luna	$0.013	8 turns; 230k in (192.5k read, 37.5k written) / 6k out	OpenAI
Job 3, agent loop	Claude Sonnet 5.5	$0.25	8 turns; 192.5k reads and 37.5k 5-minute writes / 6k out	Anthropic
Job 3, agent loop	Claude Haiku 5.5	$0.013	8 turns, every prompt under 100k	Anthropic
Job 3, agent loop	Gemini 3.8 Flash	$0.065	8 turns; 230k in (192.5k cached) / 6k out, storage excluded	Google
Job 3, agent loop	DeepSeek V4.1-Flash	$0.0098	off-peak window; 8 turns	DeepSeek
Job 3, agent loop	Grok 4.7	$0.21	8 turns; 230k in (192.5k cached) / 6k out	xAI

Two pairs of rows are identical on purpose. gpt-6.1-sol and Claude Sonnet 5.5 both list $2.00 per million input tokens, $10.00 output, $0.10 cached input and a $2.50 cache write (OpenAI pricing and Anthropic pricing, read 2026-10-09); gpt-6-luna and Claude Haiku 5.5 both list $0.10, $0.50, $0.01 and $0.125.

The same jobs with each vendor's biggest discount

Batch is the biggest published discount: 50% on OpenAI (pricing page, read 2026-10-09), on Anthropic ("a 50% discount on both input and output tokens", pricing page, read 2026-10-09) and on Google's paid tier ("Batch API (50% cost reduction)", pricing page, read 2026-10-09), where the Batch column halves the cached-input rate too. Not everywhere: xAI's batch section gives 20% to grok-4.3 and the grok-4.20 variants and says unlisted models have no batch discount, which leaves Grok 4.7 at full price (xAI pricing, read 2026-10-09). DeepSeek publishes no batch tier.

Model	Job 1, cached	Job 2, one shot	Job 3, loop	Batch discount	Price source (read 2026-10-09)
gpt-6.1-sol	$0.22	$0.16	$0.12	50%	OpenAI
gpt-6-luna	$0.012	$0.0078	$0.0067	50%	OpenAI
Claude Sonnet 5.5	$0.22	$0.16	$0.12	50%	Anthropic
Claude Haiku 5.5	$0.012	$0.039	$0.0067	50%	Anthropic
Gemini 3.8 Flash	$0.088	$0.058	$0.033	50%	Google
DeepSeek V4.1-Flash	$0.028	$0.023	$0.0098	none published	DeepSeek
Grok 4.7	$0.53	$0.30	$0.21	none	xAI

Claude Haiku 5.5's one-shot cell is the outlier: batch brings it to $0.039, still three times its cached Job 1 of $0.012, because a 140,000-token prompt sits above the 100,000-token step (Anthropic pricing, read 2026-10-09).

What the numbers say

Every figure here is arithmetic on the rows above, whose rates are linked (OpenAI, Anthropic, Google, DeepSeek, xAI, read 2026-10-09).

Output tokens decide the bill at the frontier tier. In cached Job 1 on gpt-6.1-sol, $0.15 of the $0.43 is output (35%) and $0.04 is cached instruction tokens (9%).

The spread inside one vendor is bigger than the spread between vendors. Cached Job 1 is $0.024 on gpt-6-luna and Haiku 5.5, $0.43 on gpt-6.1-sol and Sonnet 5.5, $0.53 on Grok 4.7: 22x from dearest to cheapest, 18x between the cheap pair and the frontier pair. At the same tier, the vendor changes nothing.

The agent loop is the cheapest job here. Job 3 is $0.25 on gpt-6.1-sol against $0.31 for the one-shot summary and $1.19 for Job 1. On the small models the order flips: Haiku 5.5 pays $0.078 for the one-shot summary against $0.013 for the loop, because 140,000 tokens crosses its threshold and 230,000 over eight turns does not.

Map-reduce costs more than one shot. On the two $2/$10 models it is $0.43 against $0.31, and the gap is all output tokens, 12,800 against 3,000. Chunking buys reliability and pays for it in output.

The absolute numbers are small. The main table spans $0.0098 to $1.19; batch pulls the floor to $0.0067. At this scale, a cost problem is usually a volume problem.

The variables that break the conversion

Thresholds re-price the whole request. Claude Haiku 5.5 charges $0.10 and $0.50 per million input and output tokens up to 100,000 prompt tokens, and $0.50 and $2.50 above it; the length counts cache reads and writes, and each request is priced on its own (Anthropic pricing, read 2026-10-09). Job 2's 140,000-token prompt pays the higher rate on everything: $0.078, against $0.016 under the cap. xAI applies long-context rates to all tokens in a request once the prompt passes 200,000, where Grok 4.7 costs $4.00 input, $1.00 cached input and $12.00 output instead of $2.00, $0.50 and $6.00 (xAI pricing, read 2026-10-09). Gemini 3.1 Pro Preview steps from $2.00 to $4.00 input per million above 200,000 tokens (Gemini Enterprise Agent Platform pricing, read 2026-10-09). OpenAI's line is 272,000 input tokens, published in a column tooltip; above it gpt-6.1-sol's input doubles to $4.00 and its output to $15.00 (OpenAI pricing, read 2026-10-09). All three jobs stay under every line; Job 2 is halfway to OpenAI's.

Tokenizer differences. Anthropic notes that Claude 4.7 and later use a tokenizer that "produces approximately 30% more tokens for the same text" (Anthropic pricing, read 2026-10-09). A comparison built on one words-per-token ratio, as mine is, is off by that much for Anthropic.

Time of day. DeepSeek's peak hours are 01:00-04:00 and 06:00-10:00 UTC, Monday to Friday, excluding Chinese public holidays; every other hour is off-peak at half price (DeepSeek Models & Pricing, read 2026-10-09). Job 1 uncached is $0.087 off-peak and $0.174 at peak. Off-peak is 133 of the week's 168 hours.

Cache economics differ in shape as well as in rate. Anthropic's cache hit is 10% of the input price on most models, 5% on Opus 5.5 and Sonnet 5.5, 2.5% on Fable 5.1 and Mythos 5.1; writes cost 1.25x for five minutes and 2x for an hour, so a 5-minute cache pays for itself after one read (Anthropic pricing, read 2026-10-09). DeepSeek's hit price is $0.003 per million against $0.15 for a miss (DeepSeek pricing, read 2026-10-09). Google charges no write fee but charges storage, $0.50 per million tokens per hour on Gemini 3.8 Flash through 2026-12-31 and $4.50 on Gemini 3.1 Pro (Gemini pricing and Gemini Enterprise Agent Platform pricing, read 2026-10-09); a cached 140,000-token document runs $0.07 an hour on Flash and $0.63 on Pro.

Platform fees sit outside the token meter. OpenAI bills $2.50 per 1,000 tool calls and $10 per 1,000 web searches, so Job 3's eight calls cost $0.02, and Anthropic's tool-use prompt adds 286 to 675 tokens (OpenAI pricing and Anthropic pricing, read 2026-10-09). xAI bills X search per item fetched: $5 per 1,000 posts, $10 per 1,000 profiles (xAI pricing, read 2026-10-09).

Latency and geography carry multipliers. OpenAI's Fast mode, renamed from Priority on 2026-07-30, is 2x, and data-residency endpoints add 10%; Gemini 3.8 Flash's Priority tier is $1.35 input against $0.75 standard (OpenAI pricing and Gemini pricing, read 2026-10-09). xAI's priority tier is 2x and its US regional endpoint 1.1x; Anthropic charges 1.1x for US-only inference; regional Bedrock and Google Cloud endpoints carry a 10% premium (xAI pricing and Anthropic pricing, read 2026-10-09).

The list price itself moves. Google quotes its Flash prices "through December 31, 2026" and doubles them on 2027-01-01: $0.75 to $1.50 input, $3.75 to $7.50 output, $0.075 to $0.15 cached input, $0.50 to $1.00 per million tokens per hour of cache storage (Gemini pricing, read 2026-10-09). Anthropic's $2/$10 for Claude Sonnet 5 was launched as introductory pricing through 2026-08-31 and is now standard, with the rise to $3/$15 cancelled (Anthropic pricing, read 2026-10-09). OpenAI's promotional pricing for GPT-5.6 Sol runs at least through 2026-11-21, on a model not in this table (OpenAI pricing, read 2026-10-09). Any per-task table is a snapshot with an expiry date.

What I could not check

I ran none of these three jobs. The token counts are stated assumptions, and a measured run would move every number here.
Cache-write pricing for Google, DeepSeek and xAI. I found no published write price for any of the three, so I charged zero. xAI's prompt-caching page lists a billing rate per token type with no write line; Google's context-caching price is a read rate plus hourly storage; DeepSeek's table has only a hit price and a miss price. If any of them does charge for writes, its cached rows are too low.
Whether the Haiku 5.5 threshold behaves as written at the boundary. The page counts cache reads and writes in a prompt's length, which would mean a cached 140,000-token document pays the higher rate. I did not test it.
Real token counts. I used Google's words-per-token ratio across every vendor; Anthropic's own note about a 30% tokenizer difference is a warning that this is approximate.
Volume, committed-use and negotiated enterprise pricing, free tiers and trial credits are outside this table. The price on the page is the list price.
Resale through cloud platforms. Anthropic bills Bedrock and Google Cloud in consumption units, and Gemini Enterprise Agent Platform prices are not the Gemini API prices: on 2026-10-09 the two pages disagreed on cache storage, $0.50 per million tokens per hour (Gemini pricing) against $1.00 for one model (Gemini Enterprise Agent Platform pricing). The route you buy through can change the number.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.

How an eval set is built, and why it rots

hc_xshh — Fri, 09 Oct 2026 07:00:02 +0000

An eval set is an instrument. It has a purpose, a scoring rule, a calibration record and an expiry date. Treating it as a file you download is where the trouble starts: the file already made those decisions without writing them down.

What follows is the build document I would want for a set I have to defend six months from now. Each rule is traceable to a public source or marked as my practice.

Where the samples come from

Four sources, each importing a different bias.

Source	What you get	The bias it imports	Documented where
A public benchmark, reused	Comparability with published numbers	Contamination; a task choice someone else made	Sainz et al., 2023-10-27
Public administrative data	A real distribution, a public licence, dated updates	A sample of who reports, not of who is affected	CFPB, read 2026-10-09
Synthetic generation	Volume you can afford, labels you control	Generator artifacts in the surface form	Gururangan et al., ACL 2018
Your own production traffic	Items that match what you ship	A convenience sample that drifts with the product	Lipton et al., ICML 2018

Reuse. LiveBench's authors state the problem in one sentence: test set contamination "can quickly render benchmarks obsolete" (LiveBench, v2 2025-04-18). Their answer was questions from recent competitions, arXiv papers and news, added monthly. LiveCodeBench did the same for code: 400 problems published between May 2023 and February 2024 (LiveCodeBench, arXiv v1 2024-03-12). A static benchmark decays without anyone editing it.

Administrative data. The CFPB complaint database is the best example I know. Its search API reported 18,274,023 records under a CC0 licence on 2026-10-09, with a last_updated of 2026-10-08 (CFPB complaint search API, read 2026-10-09). Complaints are published only after the company responds or after 15 days, whichever comes first, and complaints referred to other regulators, including depository institutions with less than $10 billion in assets, are not published (CFPB API docs, read 2026-10-09). The agency states that the database "is not a statistical sample of consumers' experiences in the marketplace" (CFPB database page, read 2026-10-09). A random draw samples the people who complained and whose complaints survived publication, not the people who were harmed.

Synthetic. Gururangan et al. showed that a text classifier reading only the hypothesis, with the premise deleted, reached about 67% on SNLI and 53% on MultiNLI (Annotation Artifacts in NLI Data, ACL 2018). The label was recoverable from phrasing because the crowd workers followed a template. Every generator has one. My test: delete the part of the input meant to carry the answer, score again, and compare with the majority-class rate. If accuracy stays well above it, the set is partly measuring its own generator. (my practice)

Production sampling. This is the source I trust least and use most. It produces items that match what the system sees, and its composition changes when the product does. Label shift is the named version of that failure: the marginal p(y) moves while p(x|y) does not, measurable without test labels using Black Box Shift Estimation (Lipton et al., ICML 2018).

What counts as correct

The match rule is a parameter, and the same predictions score differently under each choice. Four conventions:

Convention	The rule, as the source writes it	Source
Exact match against any reference	Counts predictions that match any one ground truth answer exactly; punctuation and articles ignored	SQuAD, arXiv v3 2016-10-11
Partial credit against the best reference	F1 over bags of tokens, "the maximum F1 over all of the ground truth answers", then averaged	SQuAD, arXiv v3 2016-10-11
A threshold on localisation	IoU thresholds `[.5:.05:.95]`, 10 of them; 101 recall thresholds; `maxDets` of 1, 10 and 100	cocoapi `cocoeval.py`, read 2026-10-09
A graded rubric with an exclusion flag	0–3 for how well specified the issue is; 0–3 for whether the tests are scoped to it; a separate 0/1 question for any other reason the sample should not be used; a 1–5 confidence rating	SWE-bench annotation instructions, undated

Three things this table taught me.

Say who the ceiling belongs to. In SQuAD the human number comes from the data: the second annotator's answer is treated as the prediction, the rest as ground truth, and humans score 77.0 exact match and 86.8 F1 on the test set (SQuAD, arXiv v3 2016-10-11). A ceiling quoted without its rule says as much about the rule as about the task.

One published number can hide ten thresholds. COCO's headline detection score averages over ten IoU thresholds, three detection budgets and a recall grid. A single figure without a named threshold is a claim nobody can re-check. Pick the threshold, publish it, keep it fixed across versions.

The exclusion question is the part people skip. SWE-bench Verified is 500 samples "verified to be non-problematic by our human annotators", drawn from 1,699 randomly sampled items that 93 Python developers annotated, with the full annotation set and the rubric released alongside (OpenAI, updated 2025-02-24). The rubric's last section asks, 0/1, whether there is any other reason not to use the sample. My handling of it, (my practice):

A closed list of exclusion reason codes, decided before annotation starts.
Two raters must agree before an item is dropped; one rater's "unclear" is not an exemption.
The dropped item stays in the file with its reason code, so the exemption stays auditable.
The exemption rate is reported next to every result; if it moves between releases, the set changed even when the questions did not.

Ground truth built by pooling is biased by construction. Test collections are built by judging only a sample of documents. When the pool is small relative to the collection, the judgment set "can be biased in that they favor relevant documents that contain topic title words", a bias that depends on collection size and not on the number of relevant documents (Buckley et al., NIST, 2007-07-17). In a modern eval, if your labels come from checking only what your current systems returned, the label set favours items phrased the way those systems phrase things. My rule: draw a random slice from outside the candidate pool. (my practice)

Whether the raters agree

Agreement is a property of the pair and the setup.

Krippendorff's alpha is 1 − Do/De, and it accepts any number of coders and missing entries (Krippendorff, 2011-01-25). For two raters, Cohen's kappa, with Landis and Koch's 1977 bands (reproduced in an AHRQ report, 2010).

Here is why the setup has to travel with the number. First-turn results on MT-bench, in the paper's two setups: S1 counts ties and inconsistent votes, S2 excludes ties (MT-Bench, v4 2023-12-24):

Pair (first turn)	S1, R = 33%	S2, R = 50%	Source
GPT-4 pairwise vs human expert	66% (n = 1,343)	85% (n = 859)	MT-Bench, v4 2023-12-24
GPT-4 single-answer vs human expert	60% (n = 1,280)	85% (n = 739)	MT-Bench, v4 2023-12-24
Human vs human	63% (n = 721)	81% (n = 479)	MT-Bench, v4 2023-12-24

The headline everyone quotes is 85% against 81% for human agreement (MT-Bench, v4 2023-12-24). The same table holds 66% for the same judge under the other tie rule. An agreement figure quoted without its setup is not comparable to anything.

Measure agreement per stratum, not pooled. ChaosNLI collected 464,500 annotations, 100 per example, over 3,113 SNLI and MNLI examples and 1,532 ANLI examples (Nie et al., 2020-10-08). Models are near-perfect where humans agree and "can barely beat a random guess" where they do not, and those low-agreement items are most of the errors. A pooled score mixes two measurement regimes whose mixing ratio changes as models improve.

Sizing. For an agreement study, start from the kappa minimum-sample-size tables (Bujang and Baharum, EBPH 14(2), 2017). For comparing two systems, use a power analysis: Miller gives the MDE formula and shows that raising answers per question from 1 to 10 moved the MDE from 13.2% to 7.5%; in his illustrative table, HumanEval's 164 questions at a fictional 83.6% carry a standard error of 3.2% (Miller, 2024-11-01). If items arrive in groups, such as the same document or template, compute clustered standard errors (Miller, 2024-11-01, Table 4); on DROP they were 1.34 against 0.44 naive.

My rule: size the calibration slice for the agreement interval I need, the scoring slice for the effect I want to detect, and refuse to report a gap below the MDE. (my practice)

Why the set rots

Decay	Symptom	What I do
Contamination	One set improves while unrelated sets do not	Keep item dates and prompt hashes; treat a stale set as historical
Label shift	Scores move while the system did not	Estimate the label mix and re-weight or re-cut the slice
Taxonomy and rubric drift	The same question means something different	Version the labels; freeze the rubric text per set version
Saturation	Every system sits near the ceiling	Retire the set and say when

Contamination's extent "is unknown, as it is not straightforward to measure", and where it exists it overestimates performance (Sainz et al., 2023-10-27). I cannot audit training corpora, so I keep the dates and admit the exposure window.

Saturation is not a failure of the set: GLUE's performance passed the level of non-expert humans, which is what prompted SuperGLUE (Wang et al., 2019-05-02). Benchmark choice is fragile on its own: swapping tasks can reorder methods even when the methods do not change (Dehghani et al., 2021-07-14). Both are reasons to keep more than one set.

Taxonomy drift has a public paper trail. The CFPB's September 2026 release notes record that "consumers' complaint narratives ... have been removed from the database"; the June 2026 release removed "Consumer disputed" and "Consumer consent provided" from exports, long after those filters went away; the May 2023 release re-based the ZIP code field on 2019 census estimates (CFPB release notes, read 2026-10-09). A set built on those narratives became unmaintainable one month ago. The same page explains the general rule: the database shows "the consumer's original products, sub-products, issues, and sub-issues selections consistent with the options available on the form at the time the consumer submitted the complaint" (CFPB database page, read 2026-10-09). Labels frozen at submission, against a taxonomy that keeps moving.

Keeping it maintainable

(my practice, with borrowed pieces named)

Version the set. Additions and exclusions get a version bump and a changelog line; never edit an item silently.
Two slices. A frozen slice for comparability, a rolling window for freshness. LiveCodeBench and LiveBench are public versions of the same idea.
Write the metadata down. A datasheet (Gebru et al., 2018, CACM 2021) or a Croissant record (2024-03-28), so the next person need not infer the collection process.
A desensitisation rule that is checkable. The CFPB's ZIP rule is a good template: publish the 5-digit ZIP unless the census area has under 20,000 people, then 3 digits only if the wider area has more than 20,000, otherwise nothing (CFPB field reference, read 2026-10-09). A rule stated as a threshold can be re-run; "we removed personal information" cannot.
Watch the exemption rate. It is the leading indicator that the rubric stopped fitting the data.
State the blind spot in one line. SQuAD's metrics ignore punctuation and articles; COCO's headline averages ten thresholds. Both are fine as long as the limitation is on the label.
Plan the retirement. When a set saturates or its taxonomy moves, freeze it, date it, and build the next one from the same seed items.

What I could not check

How many SWE-bench samples were dropped to leave 500. The announcement gives the annotated total (1,699) and the rubric, not the drop count (OpenAI, updated 2025-02-24).
Whether any specific model saw any specific benchmark item. Sainz et al. state the extent is unknown; I have no method that resolves this, so I do not claim cleanliness.
The CFPB's narrative scrubbing standard. The field is gone and the current field reference no longer documents it; I could not reach a dated scrubbing specification.
The CFPB's historical consumer_consent_provided semantics. The export field and its filter are gone; I found the removal dates, not the values.
Krippendorff's own minimum sample size for alpha. I have the kappa tables from Bujang and Baharum; I found no equivalent table for alpha.
The Landis and Koch bands at first hand. I read a reproduction of the 1977 table in a 2010 AHRQ report, not the original.
LiveCodeBench's current item count. The 400 figure comes from the March 2024 paper; the platform's live count may differ.
The OpenAI SWE-bench Verified page at first hand. The live page served an automated-client challenge when I read it; the same version is readable in an Internet Archive copy, and the annotation instruction PDF is undated.
The CFPB record count above is a live API value and changes daily. It was 18,274,023 when I read it on 2026-10-09.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.

DeepSeek filled in the Ascend column: six repos, one technical report, and my machine with no NPU

hc_xshh — Wed, 30 Sep 2026 08:35:30 +0000

DeepSeek released a batch of things over the last two days: six repositories plus one technical report in Chinese, all around Huawei's Ascend. I cloned all six, read them, and tried them on my own machine.

This post covers three things: what was actually released, whether those impressive-looking numbers hold up, and exactly where my machine gave up.

The short version

Six components were open sourced this time, and every one of them has a CUDA counterpart: a language for writing kernels, matrix multiply, multi-card communication, a general kernel library, an attention kernel, and a TopK kernel. Together that's filling in a column, not shipping a new model.
The numbers are strong: dense matrix multiply at 99.8% of the hardware limit, sparse attention prefill at 95%, multi-card communication at 90–95% of physical bandwidth. But every one of these was measured on PoC hardware Huawei provided to DeepSeek. The commercial version is planned for mid-October. No third party can reproduce them today.
The most valuable thing in this release isn't the announcement — it's the Chinese technical report published alongside it. It lays out the trade-offs of writing a sparse attention kernel on Ascend step by step: why one AI Core handles 64 heads, why you must pair each CUBE with two vector cores, and why one layout conversion has to detour through UB. I've copied the parts I found most revealing below.
What I could verify locally: all six repos cloned, I read and counted the code, and I could not run a single kernel. The build dies at line 7 of setup.py. That section is below too — it's measured, not paraphrased.

(Component-by-component comparison. The rightmost column is the size of the Ascend-specific part, which I counted from the source.)

1. Getting this layer straight first

Between a large model and the silicon sits a software layer: it tells the chip how to compute (kernels) and how to move data between cards (communication libraries). NVIDIA's version of that layer is CUDA; Huawei's is CANN. Anyone can write the model on top, but this layer has to be rewritten in the chip vendor's own language.

When DeepSeek V4 launched in April, Huawei got there first with Ascend support — but that delivery was about making it run. The pieces that matter most for performance were still open sourced only in their CUDA form. One media analysis at the time put it this way: moving from CUDA to CANN involves rewriting kernels at scale, restructuring the training pipeline, and re-tuning accuracy and performance — not less work than training the model itself. (Source: 21st Century Business Herald, 2026-04-24, in Chinese.)

That is exactly what this release is. Which is why the sentence in the announcement — "all components correspond one-to-one with the previously open-sourced NVIDIA-platform components" — is the most substantive line in it.

2. The six components, one by one

TileLang's Ascend 950 backend. TileLang is a language for writing high-performance kernels in Python, led by a team at Peking University and used for most of the kernels in DeepSeek V4's training. This time it landed in the main repository, not as a bolt-on adapter: PR #3308, "Introduce Ascend 950 backend", merged on 30 September and shipped with v0.1.15. The official support matrix lists Ascend 950 as Supported, built from source with USE_ASCEND=ON USE_CUDA=OFF, requiring CANN, the bisheng compiler and torch_npu on the machine, with torch.npu.is_available() returning True.

DeepGEMM-Ascend (matrix multiply). Same package name and same API as the NVIDIA version, so existing code keeps working. The repo was created on 29 September.

DeepEP-Ascend (multi-card communication). MoE dispatch and combine — sending tokens to the right expert and collecting them back. The kernels are all header-only .hpp files sitting on Huawei's HCCL/HCOMM, UBMEM and URMA. It's also the only Ascend repo in this batch that was built from scratch.

TileKernels v2.0.0 (general kernel library). The small but frequently used kernels: MoE routing, quantization, Engram, hyper-connections. The README's own words: "added an Ascend backend, selected automatically at runtime; the same Python API runs on both NVIDIA GPUs and Huawei NPUs."

FlashMLA (attention). Sparse attention prefill and decode.

DeepSelect (TopK). The step that picks compressed blocks in sparse attention, plus the TopK the sampler needs. The authors claim 2–20× faster than native torch.topk.

3. The numbers are strong — read them together with their sources

(Performance figures and where they come from. Bar length = the fraction of that hardware's theoretical limit; further right means closer to the ceiling.)

The key readings:

Dense matrix multiply at 99.8% of the hardware limit (BF16, FP8 and FP4 all land around there). FP4 measured 1701 TFLOPS on a 4096×7168×16384 shape against a 1730 TFLOPS hardware limit, on Ascend 950DT with CANN 9.2.0.
Sparse attention prefill at 410 TFLOPS, 95% of the theoretical limit; decode at 360 TFLOPS, 83%.
MoE communication: at EP8, dispatch 373–375 GB/s and combine 345–347 GB/s; within 32 cards it reaches 90–95% of physical bandwidth. At EP128 dispatch drops to 313–320 and combine to 272–278, with the vendor saying combine is still being optimized.

The sourcing point has to be stated plainly: DeepEP-Ascend's own README says these numbers were measured on a PoC HDK that Huawei provided to DeepSeek, with additional manual configuration that is not part of any public release. Huawei's commercial HDK for Atlas 850E is planned for mid-October. A third party cannot get the same hardware and configuration right now, so this set of numbers should be read as a vendor claim, not as a reproducible public benchmark.

Two pieces of hardware background, both from official statements: the Atlas 950 supernode supports 8192 950DT chips across 160 cabinets (128 compute, 32 interconnect), with an FP8 rating of 8 EFLOPS and FP4 up to 16 EFLOPS, and interconnect bandwidth of 16 PB/s — Huawei's own line being that this single product's total interconnect bandwidth is more than ten times the peak bandwidth of today's entire global internet. Availability is Q4 2026. A single Ascend 950DT is planned at 144 GB of memory, 4 TB/s of memory bandwidth and 2 TB/s of interconnect bandwidth.

That is the basis for the fine print on DeepSeek's side: the pricing cadence of V4-Pro is tied to the shipping schedule of the Ascend 950 supernode.

Further out, there are moves in progress: Bloomberg reported on 4 September (relayed by Guancha) that DeepSeek plans to deploy at least 160,000 Ascend 950DT chips for inference in an Inner Mongolia data center, with a gigawatt-scale power plan and full delivery possibly taking more than a year. Huawei announced the Ascend 960 supernode at its 17 September Connect conference — 4096 cards, replacing 48,000 800G optical modules with 5,500 in-house optical engines. Both of these are third-party reporting or vendor announcements; I have no independent verification to offer.

4. That Chinese technical report is the part worth reading

FlashMLA shipped with a paper called 《Ascend Sparse Attention Forward 算法与优化技术简析》("A brief analysis of the Ascend sparse attention forward algorithm and optimization"), in Chinese, released today and sitting in the repo. It lays out line by line why the kernel is written the way it is. A few of the parts that stuck with me:

One AI Core handling 64 query heads is not arbitrary. The report puts the compute-to-memory ratio on the table: with CUBE saturated (4096 multiply-adds per cycle), L2 total bandwidth of 5 TB/s, 32 cores and 1.65 GHz, the head count has to be 64 or more before compute becomes the bottleneck. At the same time, 128 heads would overflow L0C (a 128×512 float32 output is 256 KB), forcing the accumulator onto the vector core, which is extremely hard to write; empirically M=64 is already enough to saturate CUBE.

Every CUBE needs two vector cores; one is not enough. All three reasons are hard constraints: a single vector core can have at most 16 MTE2 copy requests in flight; decode has to read FP8 or FP4 KV and dequantize to bf16, and one vector core can't dequantize fast enough to keep up with CUBE; and FixPipe writes out at only 128 bytes per cycle per core, which by the formula forces B_TOPK above 73 — in practice they use 96 or 128. Taken together, the second vector core is not redundancy.

A purely arithmetic optimization saves a large round of data movement. The conventional online softmax approach may need to rescale the accumulated output against a new maximum every iteration. Their approach sets a threshold of 6 for "does this need rescaling" and skips the rescale when it isn't triggered — a trick they call skip-scale. The payoff is bigger on an NPU than a GPU, because on an NPU scale-O has to touch three units: FixPipe, UB and SIMD. The hard part is that the signal is produced by the vector core while the consumers are the CUBE and the vector core, which they solved with an SS buffer plus a cross-core flag.

The KV layout conversion goes the long way around because of a memory access pitfall. CUBE wants NZ layout while KV sits in memory as ND. The normal approach is to convert in flight during the copy, but they fetch KV sparsely token by token, which rules that out. They tried copying tokens as 32-byte blocks directly, and found that the BIU inside the AI Core only coalesces accesses when both source and destination are contiguous — "source contiguous only" doesn't coalesce, L2 bandwidth utilization drops, and the bottleneck becomes L2 bandwidth itself. In the end the path is: memory to UB, SIMD vector instructions to convert into NZ, then into L1.

The report also covers gather2 (fusing two token copies into one to work around the MTE2 queue depth of 16), L1 dual-bank balancing (splitting each tensor into two, one per bank), and the fact that icache is only 32K (CUBE), 16K (VECTOR) and 8K (SIMD VF) — which is why they use hardware loop instructions instead of unrolled loops. None of these details appears in the announcement.

One companion piece worth reading: Huawei's Ascend community has a long tutorial on TileLang from beginner to expert (published 2026-05-08) that lists the expert-mode conversion as six steps — split the requested cache by architecture into UB, L1 and L0C; insert workspace (because UB and L1/L0C cannot be copied between directly, so data used in both places has to exist twice); separate CV cores; synchronize across cores; have the two vector cores each handle half the data; and finally deal with the hardware special case that L0C cannot be written to directly. One of their measurements: hand-written FlashAttention at 44.9 microseconds, 22.28 microseconds after manually pipelining it.

5. How third parties see it

The most systematic external tracking comes from SemiAnalysis's InferenceX. They've been recording DeepSeek V4 1.6T inference performance across hardware from Day 0 through Day 43, with a dedicated section analyzing inference on Ascend 950DT — how compute and communication overlap, and which compute streams Huawei used. One of their own observations is worth keeping: on the CUDA side, vLLM and SGLang were usable the day the model shipped, while ROCm wasn't usable on day one and only caught up on day 26, with an improvement of more than 100×. The ecosystem maturity gap is the genuinely hard part of this road. The same piece also notes that V4's fused MegaMoE kernel carries a theoretical 1.92× speedup over a naive implementation — working backwards, a naive implementation spends close to half its time in dispatch and combine.

Two industry figures as reference points: IDC's data has NVIDIA's share of China's AI accelerator market falling from 95% two years ago to 55% in 2025, with domestic chips passing 41% for the first time — Ascend alone shipping 812,000 cards. China Mobile's April AI supernode tender this year was for 6,208 cards at roughly 2.06 billion RMB, requiring CANN-ecosystem solutions across the board. Both are third-party figures; I'd re-check them before using them.

6. How far I got on my own machine

(After cloning the six repos locally, where the chain breaks. Green is what worked; red is what this machine doesn't have.)

The environment first: Python 3.11.15; /usr/local/Ascend does not exist; import torch_npu raises ModuleNotFoundError; which bisheng ccec finds nothing; there is no nvidia-smi command; and lspci shows zero NVIDIA, Ascend or Huawei devices. This is a pure CPU machine.

Then I actually tried to build DeepGEMM-Ascend. The system python3 doesn't even have setuptools, so it stopped at line 5. I made a clean venv, installed the dependencies, and the second attempt got to line 7:

import torch
ModuleNotFoundError: No module named 'torch'

The Ascend part only starts at line 28: ASCEND_HOME defaults to /usr/local/Ascend/ascend-toolkit/latest, then it imports torch_npu and links against ascendcl, hccl_fwk, torch_npu, opapi and dl. DeepEP-Ascend's CMakeLists is even more direct — under ${ASCEND_HOME_PATH}/aarch64-linux/ alone there are dozens of header directories, plus the clang/15.0.5 headers from the bisheng compiler.

The conclusion is that I never even reached the doorstep. Reproducing any of this yourself starts with owning an Ascend machine with CANN installed.

7. What's in the code but not in the announcement

(Distribution of Ascend-specific kernels in TileKernels. The quant directory is the largest: 12 files, 3,491 lines.)

TileKernels writes two implementations for each kernel. Take SwiGLU: the directory contains both swiglu_forward_kernel.py and swiglu_forward_asc.py. The Ascend one starts with import tilelang.ascend.language as T and from tilelang.ascend.language import simd as S, and its pipeline synchronization is hand-written:

T.ascend_set_flag('MTE3_MTE2', 0)
T.ascend_wait_flag('MTE2_V', input_slot)

The README's "backend selected automatically at runtime" is true, and the mechanism is an is_ascend() check in tile_kernels/config.py; the package can carry both backends in one environment. But a backend is not automatic translation — the Ascend implementation is written by hand. I counted the Ascend-specific files: quant 12 files / 3,491 lines, mhc 9 / 2,375, engram 6 / 969, moe 4 / 652, plus one each in transform and rand — 33 files, 7,729 lines in total.

Constraints scattered through asserts. A few: per-token quantization only supports groups of 32 channels; the E4M3 scale factor is CUDA-only; SwiGLU only supports sf_block=(1, 32); hyper-connections only support 4 streams; randn doesn't support graph capture on NPU because replay would reuse the same random seed; and norm's hidden dimension must be divisible by 128. The announcement's line that "every TileLang kernel has a corresponding high-performance implementation" holds — the price is that list of shapes and preconditions.

FlashMLA's Ascend kernel covers only 6 combinations. Under csrc/ascend_kernels/prefill/sparse there are 4 headers plus 6 script-generated instantiation files: V4.1, h64, prefill and decode, with and without sink, fp8 and fp4. Change the shape and you regenerate. This is not a general-purpose library.

There is no kernel file in DeepEP-Ascend with "ascend" in its name. Its kernels are organized by function under csrc/kernels/ep, comm, bucket, pp and engram — all .hpp, 47 files, 6,335 lines in total.

The same batch of commits carries a breaking change. FlashMLA removed Hopper support and V3, V3.2 and V4.0 in this release, changed the KV cache format, and requires switching back to the 15 September commit if you need older models or formats. The Ascend kernels here only serve V4.1. This version of the attention library moves with V4.1.

8. What this post doesn't do

I reproduced none of the performance numbers — I have no Ascend card. I did no independent verification of second-hand items like "160,000 chips" or the supernode timelines; each is marked with its source in the text. When the commercial HDK lands in mid-October, there will be a version a third party can actually check, and I'll come back and fill this in then.

References

DeepSeek's announcement, "DeepSeek open-sources Ascend foundation components" (in Chinese): https://mp.weixin.qq.com/s/X41mKH4Ds-VXUAnK6M8Eww
FlashMLA Ascend technical report (Chinese): https://github.com/deepseek-ai/FlashMLA/blob/20260930-ascend-open-source/docs/20260930-ascend-prefill-deep-dive-zh.md
DeepGEMM-Ascend, DeepEP-Ascend, TileKernels, FlashMLA, DeepSelect: the same-named repositories under github.com/deepseek-ai
TileLang main repo PR #3308: https://github.com/tile-ai/tilelang/pull/3308
TileLang Ascend backend docs: https://github.com/tile-ai/tilelang/blob/main/tilelang/ascend/README.md
Huawei, "Ascend 960 supernode launch" (2026-09-17): https://www.huawei.com/cn/news/2026/9/hc-ascend960-supernode
Huawei supernode interconnect keynote transcript (2025-09, Atlas 950 specs): https://www.huawei.com/cn/news/2025/9/hc-xu-keynote-speech
Ascend community, "TileLang AscendNPU IR from beginner to expert" (2026-05-08): https://www.hiascend.com/developer/techArticles/20260506-1
Cailian Press, "Huawei's Atlas 950 hardware to appear at WAIC" (2026-07-07): https://www.cls.cn/detail/2418935
Guancha, "DeepSeek reportedly to buy 160,000 Huawei Ascend 950DT chips" (2026-09-05): https://www.guancha.cn/economy/2026_09_05_830131.shtml
Economic Observer, "Huawei computing power opens its chain" (2026-05-01): http://www.eeo.com.cn/2026/0501/860610.shtml
SemiAnalysis InferenceX, "DeepSeekV4 1.6T Day 0 to Day 43": https://inferencex.semianalysis.com/blog/deepseekv4-16t-day-0-to-day-43-performance

Every number, error message and source in this post is in the list above; nothing here is repeated from somewhere else. I write one of these deep dives a week, published first in my own community in Chinese — this is the cleaned-up public version.

I also keep a small paid community where I write these engineering logs up in full, one deep dive a week. Its content is in Chinese — I mention it in case you read Chinese: AI落地实录 (¥25/year with the current new-member coupon, ¥50 list price).

Disclosure: this English version was translated and edited with an AI assistant from my own write-up. Every figure, error message and file count comes from my own runs or the linked primary sources — which is exactly why the parts I could not verify myself are marked as vendor claims.

Originally written in Chinese for my own notes; this English version is a translation.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.

Collecting trending feeds from 20 platforms: only 8 had a usable API, and one silently failed for 12 days

hc_xshh — Mon, 28 Sep 2026 09:43:49 +0000

I keep trending feeds for 20 platforms, fetched, translated, built and deployed automatically every night. This post is about the data sources themselves: how I sorted them, which paths look official but don't work, and the three traps I hit — including one that silently failed for 12 straight days.

The short version

Of 20 platforms, only 8 have an API I can call directly. The other 12 either need RSS or a workaround.

The most deceptive status a collection script can report is "success". When a single platform breaks, the job still succeeds, and the page keeps rendering yesterday's numbers.

Every path here was found by trial and error. This morning's run started at 04:30:18, all 20 platforms returned data, 480 items total, and fetch + translate + build + deploy finished in 64 seconds.

What a full run looks like

This is today's run report, unedited:

== fetch     04:30:18 ==
OK  zhihu: 29 items
OK  bili: 30 items
OK  v2ex: 7 items
OK  hupu: 30 items
OK  maoyan: 30 items
OK  hn: 30 items
OK  lobsters: 25 items
OK  github: 30 items
OK  reddit: 25 items
OK  yt: 30 items
OK  kr36: 30 items
OK  tc: 20 items
OK  sspai: 10 items
OK  ifanr: 20 items
OK  ithome: 30 items
OK  solidot: 14 items
OK  verge: 10 items
OK  ars: 20 items
OK  cnbeta: 30 items
OK  arxiv: 30 items
TR  translating hn (30 titles)…
TR  translating github descriptions (28)…
SAVE zhihu.json: 29 items
done: 20/20 platforms collected (2026-09-28)
== summarize 04:31:15 ==
summarize: 19 platforms, 450 items total, 95 top entries fed to model
summarize OK: 10 focus items (3 merged across platforms) -> summary.json
== build     04:31:18 ==
== git       04:31:19 ==
DONE in 64s

In that one minute: 20 platforms returned 7 to 30 items each (480 total), 189 English headlines plus 28 English descriptions were translated, a model picked 10 front-page highlights from the top 5 of each platform (3 of today's were merges of the same story across sites), and the static site was built, committed, pushed and auto-deployed.

Note the done: 20/20. The script settles the books by number of successful platforms. The job only counts as failed when the same platform dies several times in a row.

Three categories of data source

Category 1: a real API (8 platforms)

Zhihu, Bilibili, V2EX, Hupu, Maoyan, Hacker News, Lobsters, GitHub.

They look like the easy ones. Every single one has a different temperament:

Zhihu's official CLI gives you 2 trending-list calls per day. Two runs and you're done. A third-party CLI that reuses cookies has no limit.
Bilibili, Hupu and Maoyan work from a Chinese IP directly — but adding a proxy breaks them. All three fall into the "the more official the channel, the less usable it is" bucket; I ended up on mobile-app and dashboard endpoints.
Hupu returns about ten items per call, so it takes 5 pages to reach 30. It also reports a weighted heat score, not a pure numeric ranking, so you take it as given.
Maoyan returns 403 without a desktop User-Agent and a Referer header.
V2EX has a fully public keyless endpoint that returns 7 to 10 items per call. That's the platform's ceiling, not a bug. Today it gave me 7.
HN and Lobsters are the simplest: one uses Algolia's search API, the other a plain hot-list JSON.
GitHub uses the Search API, querying repositories created in the last 7 days, sorted by stars.

Category 2: RSS only (10 platforms)

sspai, ifanr, ITHome, Solidot, cnBeta, The Verge, Ars Technica, TechCrunch, arXiv, Reddit.

These are the easiest to maintain: no API key, uniform format, one regex parses them all. The cost is that you get exactly what they choose to publish. Solidot gives about a dozen items a day, sspai and The Verge give 10 each, and Reddit gives titles and links only — no scores, no comment counts (more on that below).

Category 3: needs a workaround (2 platforms)

36Kr and YouTube. 36Kr's channel pages are pure client-side rendering, so a plain request returns an empty shell; you need a rendering service, and one of its tier parameters must be pushed to the maximum — at the default tier the response body is always empty. YouTube's official trending API returns an empty shell to datacenter IPs like mine, so I use a third-party aggregator page instead.

Trap 1: twelve days of silent failure

Reddit took the longest to fix, and cost me the most.

The result first: from September 1 to September 12, twelve days in a row, the Reddit column showed August 31 data. The page rendered fine. The job status was "success". I noticed nothing.

On each of those twelve days, this line sat in the report:

KEEP reddit.json: fetch failed, keeping previous data

It was in the report. The problem is it was buried among 20 lines of OK, and the job status was still success. My daily routine was to scan for red text, and KEEP read to me like "it kept the old data, that's stable."

What actually exposed it was a completely unrelated incident. On September 12 a build log had wrong file permissions, the script exited non-zero, and for the first time error output made it into the report — where I saw the real message:

ERR reddit: reddit: no thing blocks found (proxy changed?)

It wasn't monitoring that caught it. It was a permission error that happened to occur nearby.

The cause: Reddit's path had depended on a Google Translate proxy page, which switched to a 302 redirect in early September and died instantly. I moved to Reddit's official Atom RSS, and there are two things you must remember:

The URL must include geo_filter=GLOBAL. Without it you get content localized to your exit IP's country. My proxy exits in Germany, so without that parameter the whole page came back in German.
It must go through a proxy. Direct requests get nothing.

One thing I gave up on: that RSS carries no scores or comment counts. I tried three ways to get them back. The keyless .json endpoint returned 403 under all three approaches — direct, proxied, and with a Chrome TLS fingerprint spoof. A third-party archive returned 2015 posts; another moved to paid rate limiting. The only method that truly returned scores was reusing my own browser's login cookie, which returned 200 with real scores — but that's unapproved automated access, so I didn't use it.

So that column is now permanently official RSS, no scores. I wrote it into the project doc marked "settled, stop tinkering."

Trap 2: looks fine, actually missing half

arXiv fails in a very particular way.

First the API broke: the official endpoint returned a 14-byte response body reading Rate exceeded., proxied or not. The official RSS fixed it — 200, no key needed.

The real trouble came later, from a code audit. My RSS fetch pulled three categories at once (artificial intelligence, machine learning, natural language processing) in a loop — but there was an early return inside it. As soon as the first category hit 30 items, the function returned. The other two categories were never requested, and machine learning and LLM papers silently vanished from the feed.

What makes this hard to spot is that it does nothing to "normal operation": the job succeeds, the item count is a full 30, the page renders. You only find it by deliberately counting categories.

Today's 30 items: 6 each from AI, ML and NLP, plus 12 from robotics, security and databases (the RSS carries cross-listed categories, so they leak in).

Trap 3: "zero items" and "fetch failed" are different bugs

36Kr is the third category. It doesn't raise. It returns zero items.

The cause is in the render service's response body. Below a certain tier, it doesn't raise an error — it returns an empty result list plus a failure reason. My code grabbed the first result, threw an array-index-out-of-range exception, and the outer handler swallowed it into the "keep previous data" branch.

Same outcome as Reddit: the platform silently froze on yesterday. The only difference is the cause changed from a network problem to a parameter problem.

The day nothing updated

On September 15 the whole pipeline froze.

The entire report for that day was these few lines:

# Cron Job: daily-hub
**Run Time:** 2026-09-15 05:30:25
**Mode:** no_agent (script)
**Status:** script failed
Script timed out after 3600s: …/daily-hub-update.sh

249 bytes. Nothing else: no error, no progress, not even a "starting fetch". Output went through a pipe with block buffering, so when the process was killed, everything in the buffer was lost.

Nothing on the live site updated that day. I only found out the next morning, because the page still showed the previous day's date.

The guardrails I added afterwards are four:

exec </dev/null — any child process reading stdin gets EOF immediately, so nothing hangs silently
A timeout on every step: 20 minutes for fetch, 7 for summarize, 5 for build. If it's over, let it die rather than drag on.
python3 -u — buffering off, so when it gets killed you can at least see which line it reached
Every step appends one timestamped line to a log file, so afterwards you can see exactly where it stuck

Later audits found the same class of hazard twice more, so I added two budgets: 420 seconds total for the translation step, 300 seconds total for Reddit retries. The old backoff retry could sleep for ten minutes in the worst case — the same failure shape as September 15.

The tradeoffs I made

One platform failing doesn't block the other 19. The cost is that failures go silent, so I watch "how many platforms returned data today" instead of the job's success status.
When a fetch fails, keep the previous data and tag it as stale; the front end marks it. I don't overwrite readable content with empty data.
Translate 15 items per request. Send 30 and the model's output gets truncated, JSON parsing fails, and the whole batch is wasted.
For the front-page summary, the model may only return item indices. Headlines and links are backfilled by the script from the raw data, so the model never gets a chance to invent a link that doesn't exist.
I don't walk unapproved paths to get Reddit scores, and I don't queue up for developer-platform applications. The cost/benefit is bad.

If you want to copy this, three steps

First: put a timeout on every step, and add exec </dev/null at the top of the script. Five minutes of work that would have saved me a full day of lost data.

Second: write one progress line per step. Nothing fancy — a mark function that appends a timestamp and step name to a file. When things break, that line is your fastest lead.

Third: decide what happens after a single platform fails. Does the whole job fail, or do you keep old data and record how many platforms succeeded? I chose the latter, because one platform going down shouldn't waste the other 19.

Pitfalls from my own notes

Chinese platforms: don't use a proxy. Overseas platforms: you must. Both requirements coexist in the same script — it's not one global switch.
Different item counts per platform are normal. V2EX giving 7 and sspai giving 10 is the platform's ceiling, not a defect.
"Zero items returned" and "fetch failed" need separate handling. The former raises no exception; it just makes you think everything is fine.
Don't write build logs to the system temp directory. Once there was a stale file there owned by a different user; wrong permissions failed the whole job.
HOME inside a cron environment is not your home directory. Export it on the second line of the script, or every config and credential lookup fails.
The timestamp log file accumulates thousands of lines a month. Remember to prune it.

The script

40 lines. The comments mark which parts you need to change for your own environment.

#!/bin/bash
# Daily update: fetch -> translate -> build -> commit & push
# Every step has a timeout fallback + exec </dev/null: a hung step must not take the job down.
# Lesson: one silently hung step -> whole script hit the job limit and got killed, a full day of data lost
# (output went through a pipe, line buffering swallowed by block buffering, not one word in the report).
exec </dev/null                # any child reading stdin gets EOF immediately, so nothing hangs silently
export HOME=/home/youruser      # inside cron this is often /root; set it explicitly
cd /path/to/your/repo || { echo "REPO NOT FOUND"; exit 1; }

STEPS_LOG="$HOME/.logs/steps.log"
mkdir -p "$(dirname "$STEPS_LOG")"
mark() { echo "== $1 =="; printf '%s %s\n' "$(TZ=Asia/Shanghai date '+%F %T')" "$1" >> "$STEPS_LOG"; }

start=$(date +%s)

mark "fetch $(TZ=Asia/Shanghai date +%H:%M:%S)"
timeout -k 30 1200 python3 -u scripts/fetch.py || {
  rc=$?; echo "FETCH FAILED (rc=$rc; 124=step timeout)"; exit 1; }

mark "summarize $(TZ=Asia/Shanghai date +%H:%M:%S)"
timeout -k 30 420 python3 -u scripts/summarize.py || echo "SUMMARIZE FAILED (non-fatal)"

mark "build $(TZ=Asia/Shanghai date +%H:%M:%S)"
BUILDLOG="$HOME/.logs/build.log"
mkdir -p "$(dirname "$BUILDLOG")"
timeout -k 30 300 npm run build > "$BUILDLOG" 2>&1 || {
  rc=$?; echo "BUILD FAILED (rc=$rc)"; tail -5 "$BUILDLOG"; exit 1; }

mark "git $(TZ=Asia/Shanghai date +%H:%M:%S)"
git add -A
if git diff --cached --quiet; then
  echo "no changes to commit (data unchanged)"
else
  timeout 180 git commit -m "daily update $(TZ=Asia/Shanghai date +%Y-%m-%d)" \
    || { echo "COMMIT FAILED"; exit 1; }
  timeout 180 git push origin main || { echo "PUSH FAILED"; exit 1; }
fi

echo "DONE in $(( $(date +%s) - start ))s"

Only four things matter: the exec </dev/null on the first line, the numbers in each timeout, the unbuffered python3 -u, and that mark function. The rest is paths to change for your own environment.

Originally written in Chinese for my own notes; this English version is a translation.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.

I checked all 12 Reddit subreddits for freelance gigs. Only 3 are usable.

hc_xshh — Sat, 26 Sep 2026 05:43:01 +0000

I spent a few weeks going through every subreddit people mention when the topic of finding freelance work from overseas comes up. Twelve of them. I pulled subscriber counts and rules through Reddit's own API, and activity numbers from the official RSS feeds, so the numbers below are traceable rather than remembered.

Here is what I found, and what I would tell anyone thinking about Reddit as a client source.

Three subreddits actually work

r/forhire — 684,000 subscribers, about 33 new posts a day. The hard rule: no gigs priced below $15/hour. It protects you from a race to the bottom, and it also caps the low end.

r/DesignJobs — 202,000 subscribers, design work. The threshold is written explicitly: the account must be older than 60 days and have more than 200 karma. Floor price is $20/hour.

r/gameDevClassifieds — 158,000 subscribers, game outsourcing. Be careful: rev-share projects, free work, AI art and personal commissions are all banned. If you are a solo artist or writer, this one is mostly closed to you.

The ones that are dead ends

r/freelance bans hiring and self-promotion outright, and the penalty is permanent ban. r/WorkOnline explicitly forbids "for hire" posts. r/beermoney is a survey site directory, not a job board. r/jobbit is effectively abandoned: the newest 100 posts run from November 2025 to 31 August 2026, and nothing after that.

The karma wall nobody publishes

Both r/forhire and r/slavelabour state in their rules that the karma threshold is not public and will not be answered. What I could measure elsewhere: r/hiring wants 25 comment karma, r/DoneDirtCheap wants 20, r/b2bforhire wants a two-month-old account, r/INAT wants a new account to be at least a week old.

The practical consequence: a new account that posts gets silently removed. No error, no explanation. If you are starting from zero, the first job is not writing a portfolio, it is spending a couple of weeks commenting.

Money never touches the platform

No escrow, no guarantee, no dispute process. Payment happens off-platform: PayPal, gift cards, Bitcoin. The only line in the rules about it suggests you consider using an escrow service. If something goes wrong, the moderators are explicit that they will not get involved.

The trap worth knowing

When your post is auto-removed, do not message the moderators to ask why or to request an exception. The r/forhire rules state that contacting the moderators for an exception results in a ban. Another large subreddit puts it as: no exceptions will be made for any reason, ever. The correct move is to fix the post and submit again.

So is it worth it

For someone outside the US who wants paying clients without a platform taking a cut, Reddit is one of the few places where the rulebook is public and the demand is real. It is also gated by account history, moderated by automations that do not explain themselves, and it will not hold your money.

Treat the first month as an investment in account reputation, not in finding work.

I keep the longer write-ups and the raw measurements at Field Notes — no ads, no tracking, one-click unsubscribe.