Why I’m Finally Letting Go of Alibaba’s Coding Plan

I subscribed to Alibaba’s Coding Plan right when it launched. I kept it through the restrictions on new subscriptions, continued paying ¥200 every month, and resisted cancelling because I wasn’t sure I could ever get the same deal again.

Now I’ve decided to stop renewing.

It’s not because the plan was always bad value. Quite the opposite: it was an exceptionally generous deal at launch. But the models stopped keeping pace, and eventually preserving access to that deal became less useful than moving on.

It really was a good deal

Coding Plan arrived with aggressive pricing and enormous request allowances. Contemporary launch coverage explicitly framed it as bringing the subsidy war to AI coding: Lite offered 18,000 monthly requests at ¥20 on renewal, while Pro offered 90,000 requests, with heavily discounted introductory prices. Source

My impression was that Alibaba had priced it almost too generously. Whether that was deliberate customer acquisition or an offer that proved difficult to sustain, I can’t say. But it explains why early subscribers like me were reluctant to leave.

When access for new customers became restricted, that reluctance grew. Cancelling no longer felt like simply ending a subscription. It felt like giving up something I might not be able to buy again.

For a while, that was enough reason to keep renewing.

The quota stayed generous. The models fell behind.

What gradually changed my mind wasn’t the allowance. It was the model selection.

I don’t expect a subscription to include every new model on launch day. But I do expect it to evolve. Instead, the Coding Plan increasingly felt like a legacy product: still operating, still collecting its monthly payment, but no longer somewhere I expected to find the latest models.

For my usage, Qwen3.7-Plus remained the main option. Meanwhile, my interactive coding had already moved elsewhere.

The published Coding Plan model list still includes Qwen3.7-Plus alongside older Qwen models and third-party options, but not Qwen3.8-Flash. Source

That doesn’t prove Alibaba will never update it again. But I don’t want to keep paying based on the possibility that it might.

A subscription should earn its renewal through what it provides now, not what I hope it eventually becomes.

Qwen3.8-Flash was the tipping point

The awkward moment was realizing that a newer, inexpensive model could outperform the top Qwen option in my existing subscription.

Qwen’s published evaluations put Qwen3.8-Flash-Next ahead of Qwen3.7-Plus across several coding and agent benchmarks. These are vendor-reported results, and the open-weight benchmark model shouldn’t be treated as a guarantee of identical behavior on every hosted endpoint. Still, the direction was enough to make me question why I was holding on to the older plan. Source

“Flash” no longer meant an obvious quality compromise I had to accept to save money. It looked like a credible upgrade for the kind of work I cared about.

That changes the value proposition. A huge allowance for an older model becomes less compelling when a newer, cheaper model is the one I actually want to use.

What I was actually using the plan for

I had two separate workloads:

• Coding Plan: running five Hermes agents, primarily on Qwen3.7-Plus.
• Token Plan: interactive coding with Qwen3.8-Flash, and occasionally Qwen3.8-Max when I felt rich.

So Coding Plan wasn’t useless. It had a defined job, and its separate allowance protected my coding Credits from the agents’ background consumption.

But I was using less than 20% of its monthly request quota.

Initially, that made cancellation seem obvious. Then I looked more closely and realized quota utilization alone was the wrong measure.

A request can contain a short prompt or a long conversation history. Agent workflows can repeatedly process system instructions, tool definitions, files, and previous results. Using a small percentage of a request allowance doesn’t necessarily mean the equivalent token bill would be small.

The right comparison wasn’t “How much quota am I leaving unused?” It was “What would it cost to replace the useful work this plan does?”

The token totals looked scarier than the workload

My Hermes usage report initially showed around 155 million tokens for the reporting period. That sounded substantial enough to justify keeping a fixed-price subscription.

But the detailed breakdown told a different story:

Most of the identified input volume—roughly 82%—was cache reads.

There were still accounting discrepancies in the report, including uncertainty about whether the reasoning counter overlapped with output. So I wouldn’t treat those numbers as an audited bill. But they were enough to show that “155 million tokens” did not mean “155 million expensive, fresh input tokens.”

Using the published Beijing Qwen3.8-Flash rates of ¥0.80 per million uncached input tokens, ¥0.10 per million cached input tokens, and ¥2.70 per million output tokens, repricing the identified categories came to roughly ¥34–35. Source

That is a same-volume calculation, not a measured Flash bill. A different model might produce more reasoning, take more steps, or achieve a different cache-hit rate. The unexplained usage also needs resolving.

Still, it gave me a much better basis for the decision than the headline token total—or the size of my unused request allowance.

I don’t need to merge everything into Token Plan

At first, I framed the decision as a choice between keeping both subscriptions and squeezing everything into my 180,000-Credit Token Plan.

That was unnecessarily restrictive.

I already have useful coding work for those Credits. Moving the Hermes agents into the same pool would displace some of that work, even if the agents consumed only a modest share.

There is also a straightforward third option: keep Token Plan for interactive coding and pay for Hermes separately through ordinary Flash API usage.

I haven’t found a verified model-specific conversion that lets me confidently turn my Hermes token records into Token Plan Credits. A small PAYG bill does not automatically mean the same workload consumes an equally small percentage of a Credit subscription.

But I don’t need that conversion to decide whether the old Coding Plan still deserves ¥200 a month. I can compare it against actual replacement spending instead.

The hardest part was giving up the option

The strongest argument for keeping Coding Plan was always:

What if I cancel and can never get it back?

That isn’t irrational. A generous fixed-price plan can be useful insurance against heavy months, runaway context, or a sudden increase in agent work.

But that insurance has a recurring price: ¥200 a month, or ¥2,400 a year.

Eventually, I had to ask whether I was buying useful capacity or paying to avoid the discomfort of losing access.

For me, it was increasingly the latter.

My preferred coding models were already elsewhere. The old plan’s quota was far beyond my normal usage. And its main remaining workload looked potentially inexpensive to replace.

I don’t need to consume the entire allowance to justify a subscription. Equally, I don’t need to preserve a subscription simply because its theoretical maximum value is impressive.

Why I’m moving on

I’m not claiming that everyone should cancel Coding Plan.

If you use its included models heavily, benefit from request-based billing, or genuinely need predictable fixed-cost capacity, it may still be excellent value. My decision isn’t a verdict on someone else’s workload.

But for me, the balance has changed.

I subscribed early because the offer was compelling. I stayed because the allowance was generous and access became harder to obtain. I’m leaving because the models I want to use have moved on, while the subscription hasn’t kept pace.

I can understand why Alibaba might not want to keep expanding such a generous product indefinitely. As a customer, though, I don’t have to keep funding my hope that it will become compelling again.

It was a good deal when I bought it. That doesn’t mean it’s still the right deal for me.