codingplan: a generated price and quota table for Chinese AI coding plans

A static comparison site rather than a library you install

wmpeng/codingplan is not a package you add to a project. The repository's primary language is reported as HTML, the default branch is `main`, and the tree is a set of static pages: `index.html`, `coding-agents.html`, `plan-usage.html`, `platform-compare.html`, `relay-detect.html` and `relays.html`, alongside `robots.txt`, `sitemap.xml`, a `favicon.ico` and a `styles/` directory. There is no install step and no build command anywhere in the README. What you consume is the hosted site at codingplan.fyi, and the repository is where the site and its data live.

The site's job is to compare subscription plans that bundle access to AI coding models, with a scope aimed at the Chinese market: Zhipu, Kimi, MiniMax, Alibaba Cloud Bailian, ByteDance Volcano Ark and Baidu Qianfan among them. The README header states the current scope as 37 platforms, 99 subscription plans for sale, 2 pay-per-use APIs, 118 models and 1090 plan-to-model relations, with a stated update date of 2026.9.11.

The license is MIT, which is unusual for a dataset-heavy comparison project and means the JSON in the repository can be reused without asking. The topics are `coding-plan` and `codingplan`. The last push was on 2026-09-19 and the repository is not archived.

The opening line of the README changes how you should treat everything after it. It states that the file is generated by `scripts/codingplan/generate-readme.js` and must not be edited by hand. The README is an output artifact rather than a source document. The editable sources are the JSON files in the tree: `platforms.json`, `plans.json`, `models.json`, `plan-models.json`, `config.json` and `model-comparison-presets.json`.

Reading the quota columns without misreading them

The comparison tables have a fixed shape, and parsing them correctly matters more than the star ratings anywhere above them. Each row is a platform and plan pair. After the plan name come a tier marker that is either valley or peak, the billing terms, a five-hour token allowance, a weekly allowance, a monthly allowance, a blended unit price in renminbi per million tokens, and a basis label.

That last column is the one most readers skip and the one that matters most. Rows labelled as calculated are derived arithmetically from a published plan price and a published quota. Rows labelled as a multiplier conversion were not measured directly; they were translated from a quota multiplier on a model whose per-token price is already known. Rows labelled as measured came from observation. In the DeepSeek-V4-Flash table, the ByteDance Ark Coding Plan Lite row at 40 renminbi per month shows 40M tokens over five hours, 300M weekly and 600M monthly, landing at 0.0667 renminbi per million tokens and carrying the measured label. The surrounding Command Code rows at 1 and 10 dollars per month carry the calculated label instead. A measured row and a converted row sitting in the same table are not the same kind of evidence, even though the columns line up.

The five-hour column also has no counterpart in an ordinary subscription. It models a rolling usage window, which exists because these plans are built for agentic coding sessions that burn tokens in bursts. A monthly figure on its own would tell you very little about whether a plan survives one day of heavy refactoring work.

Peak and valley regimes decide the bill, not the headline price

The tables separate two pricing regimes, and this is the largest cost variable in the entire dataset. DeepSeek's own pay-per-use API is quoted at 1 renminbi input, 0.02 renminbi cache read and 4 renminbi output per million tokens during idle periods, and the peak rate is exactly double: 2, 0.04 and 8. The same halving shows up in the subscription rows. The Command Code Go plan at 1 dollar per month yields 143.8M tokens over five hours at valley and 71.9M at peak, so the quota is cut in half rather than the price being raised.

Why this matters for anyone reading a comparison is that a blended unit price computed from a monthly fee means nothing until you know which regime your hours fall in. The DeepSeek-V4.1-Flash table shows the effect in a single model. OpenCode Go at 10 dollars per month computes to 0.015 renminbi per million tokens at valley and 0.0299 at peak, while DeepSeek's pay-per-use API computes to 0.0887 when idle and 0.1773 at peak. On paper the subscription looks several times cheaper. That comparison holds only if your usage is genuinely valley-weighted, and most of a working day is not.

So the question this repository actually helps you answer is narrower than which plan is best. It helps you find which plans let you predict your bill at all, which is a more answerable question than the one the site is named for.

The recommendation tables carry an opinion and a timestamp

Above the comparison tables the README carries recommendation tables grouped by scenario: an overall ranking, then one table each for plans including GLM-5.3, plans including the newest DeepSeek models, and plans including Kimi-K3. Each entry carries a five-star score, a purchase status and a written rationale.

Two aspects of that format deserve scepticism. The scores are editorial, and the rationales lean on promotional phrasing such as best value across all platforms and open for purchase with no waiting. The links are also not direct. Every platform entry routes through a redirect domain with a per-platform path, which is the ordinary shape of affiliate or referral tracking. If a recommendation sends you toward a purchase, type the vendor's own domain instead of following it.

The status column is the most reliable part of the table precisely because it is the part that moves. At the stated 2026.9.11 update, both Zhipu and Kimi are listed as temporarily closed to new purchase, and Kimi carries an extra note that it requires a lottery for access and that memberships were paused after the Kimi-K3 launch. ByteDance Ark is noted as having lifted its purchase limit. A snapshot of fast-moving sales conditions like this is the main reason to treat the update date as the real datum and the stars as decoration.

There is also a stated update note at the top of the README about one vendor's DeepSeek Flash model moving to DeepSeek V4.1 Flash, which is a good illustration of how quickly the model column ages.

v1, v2, monitor, and the absence of any release history

The tree shows a site with a history rather than a fresh script. There are `v1/` and `v2/` directories, an `articles/` directory, a `monitor/` directory and a `vendor/` directory, alongside tooling directories (`.github/`, `.dev/`, `.codegraph/`) and platform-specific files such as `.coze` and `.cozeproj/`. A `baidu_verify_codeva-2macIxYf7K.html` file sits at the root, which is a search-console verification artifact that ended up committed alongside the actual site files.

There are no GitHub releases at all, so there is no version history to install from and no changelog to read. The last push was on 2026-09-19.

The `monitor/` directory implies the data is refreshed by some job rather than typed by hand, but nothing in the README documents what that job does, how often it runs, or how it detects a price change. That gap matters more than it might seem. If you plan to use this as an input to a purchasing decision, the useful question is when the last successful refresh ran, not when the last commit landed, because a commit can be a wording change to a page rather than new pricing.

The `articles/` directory is also unexplained. Comparison sites sometimes keep long-form editorial pages next to the tables, and methodology notes would live there if they exist. Nothing in the README links to them, so treat the directory as a hint rather than a documented feature.

Three questions this dataset cannot answer

There is a hard ceiling on what a comparison dataset can resolve, and this one runs into it in three specific places.

The first is workload dependence. The tables know token counts, but a five-hour allowance of 40M tokens reads very differently once you account for agentic sessions with tool calls, retries and long context, which produce a different token profile from plain completion work. Two developers on identical plans can land several times apart on effective quota.

The second is reliability, which the dataset does not model at all. Rate limits, queueing during peak hours and upstream provider outages are the usual reasons people walk away from a coding plan, and none of those appear in a JSON file. The recommendation rationales gesture at the problem with phrases about a platform not being crowded, which is an editorial judgment rather than a measurement anyone published.

The third is a gap the project names itself. Kimi-K3 is described as the strongest model available at the time of writing but expensive enough to use on demand, and its official plan is paused. When the model you want has no purchasable plan, a comparison table has nothing to put in the row.

The alternative is not another comparison site. It is the vendors' own pricing pages, which are authoritative on price and silent on effective yield, read alongside your own token meter. Use this repository to decide which two or three plans deserve a closer look, then confirm the numbers at the vendor before paying.

Editorial conclusion

Treat wmpeng/codingplan as a screening tool rather than a source of truth. It earns your time if you are narrowing a long list of Chinese AI coding plans down to two or three worth studying, because the peak and valley quota columns and the basis labels tell you which numbers were measured and which were derived, and no vendor page offers that comparison. It does not earn your time if you need an API to query prices programmatically, a reliability or uptime signal, or an answer for a model that has no purchasable plan, because none of those exist in the repository. Before you buy anything, open the vendor's own site rather than the redirect links in the recommendation tables, then compare the README's stated update date against the pricing page in front of you. The repository is MIT licensed and not archived, with its last push on 2026-09-19, so the JSON underneath is yours to fork if you would rather refresh it on a schedule you control.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. wmpeng/codingplan on GitHub