DEV Community: Yucong Chen

A real consulting deliverable, unedited

Yucong Chen — Wed, 28 Oct 2026 14:31:27 +0000

This is the unedited output of a consulting pipeline, for a prompt about a 5-person B2B SaaS
at 30k MRR with 40 customers on a flat 750/month plan, asking whether to raise prices 20% for
new customers or add a cheaper tier. The question is generic, so nothing here is confidential.

Two honest facts before you read it:

It took about six minutes end to end. A trivial prompt finishes in about 30–80 seconds; a real decision question does not. Anyone claiming a strategy document in two seconds is returning a single model's stream-of-consciousness.
It cost a few cents of tokens, metered from the balance — not a retainer, not a seat license.

Consulting Report: Pricing Decision for a B2B SaaS at $30k MRR

1. Executive Summary

Decision: Raise prices 20% for new customers. Do not add a cheaper tier at this time.

Raise the standard rate from $750/month to $900/month for new customers.
Grandfather the existing 40 customers at $750/month, at least for a defined period.
Hold off on a cheaper tier until there is clear evidence of a distinct lower-price segment with acceptable unit economics.

The company is at a scale where improving ARPU, margin, and positioning matters more than adding operational complexity or chasing lower-end volume. A 20% increase is moderate, protects the existing revenue base, and requires minimal operational change.

2. Current Economics

Metric	Value
Customers	40
Price	$750/month flat
MRR	$30,000
ARR run rate	$360,000
ARPU	$750/month
Team size	5

The business has a single plan, one price point, and a small team. This means pricing changes should be simple and should avoid creating new support, onboarding, or packaging burdens unless the ROI is very clear.

3. Option Analysis

Option A: Raise prices 20% for new customers

Proposed new price: $900/month

Revenue impact:

Each new customer adds $150/month more than under the current price. Existing revenue remains stable at $30k MRR.

For example, acquiring 10 new customers in a year would generate:

Current pricing: 10 × $750 × 12 = $90,000
New pricing: 10 × $900 × 12 = $108,000
Incremental revenue: $18,000

The short-term revenue lift is modest because the existing base is grandfathered, but the strategic benefit is meaningful: you reset the value anchor without risking current customers.

Key advantages:

Low operational complexity: only sales and marketing pricing updates.
Low churn risk for existing customers.
Improves unit economics and ARPU.
Positions the product as more valuable.
Keeps the product and packaging unchanged.

Main concern:

Some new prospects may push back on the higher price if the value story is weak.

Option B: Add a cheaper tier

A cheaper tier might be, for example, $390–$450/month with limited features or usage.

Revenue impact depends heavily on mix.

Suppose a cheaper tier is set at $450/month:

If one existing $750 customer downgrades, the company loses $300/month.
It takes two new lower-tier customers just to replace the revenue of one downgrade.
If lower-tier customers also demand more support relative to their spend, the ne

The full, unstyled version (with the risk section) is here:
https://flintapi.ai/blog/2026-10-28-sample-consulting-report

If you want to try the same thing on your own problem, describe it and you get the plan first,
then decide whether to run it.

What an 81-second strategy deliverable actually looks like

Yucong Chen — Wed, 28 Oct 2026 13:21:11 +0000

We build a consulting product. Not an API, not a chatbot — a thing you describe a business
problem to, and 81 seconds later a structured, CEO-ready document comes back that you could
put in front of a board.

That number came from a deliberate measurement, not marketing. Last night I ran the smallest
possible request through our pipeline and timed it end to end:

POST /v1/consulting/tasks   { query: "Say hi in one sentence.", mode: consulting_report }
→ 11s running
→ 21s running
→ 71s running
→ 81s succeeded          answer length: 2,178 characters   artifacts: 1
→ balance charged, usage row written

A trivial prompt, and it still took 81 seconds. That is the honest cost of a multi-stage
pipeline: reframe the question, decompose it into sub-tasks, route each sub-task to a
different model, synthesise the results, then assemble a report. Anyone who tells you their
LLM product answers a strategic question in two seconds is either caching, or returning a
single model's stream-of-consciousness and calling it a deliverable.

What the deliverable is made of

The output is not a paragraph. It is a document with a fixed skeleton:

Executive summary — the answer, in the form you could read aloud in a meeting
Context and goals — what we understood the problem to be
Key findings — the parts that surprised us, or that constrain the answer
Recommended design — the actual proposal, with options and trade-offs
Risks and mitigations — what would make this fail, and what we'd do about it

The interesting engineering problem is not generating text. It is making five sections that
agree with each other, when each was produced by a different model with a different context
window. That is where most of the 81 seconds goes, and it is why a single-model answer reads
fluent but incoherent if you check one section against another.

The boring parts nobody shows you

Three things we had to fix before the pipeline was worth shipping:

1. A dead upstream must not kill the whole run. Our router used to pick models from a
fixed per-domain list. When one provider's account ran out of credit, every request died with
HTTP 403 用户额度不足 — and the failure surfaced as a content string inside a 200 response.
Now: failures are detected as failures, the run does not get billed, and the router fails over
to a provider that is actually healthy.

2. A thinking model leaks its thinking. Some upstreams stream the entire answer in a
reasoning_content field and leave content empty. Our first fix was to copy it into
content so clients saw something; the second fix was to buffer it and only emit it if no
real content ever arrives. Streaming should give you the answer, not the rehearsal.

3. Never promise a channel you cannot deliver on. The product page used to say "leave and
we'll email you the report." For one day our transactional email quota was exhausted, which
meant leaving the page meant losing the report. The copy now says the report stays on the page,
and email is a if available extra. Two words change, one broken promise avoided.

What it's not

It is not a replacement for a consultant who knows your industry. It is the thing you do
before hiring one: getting a structured initial position, in a minute, so that the expensive
conversation starts from a draft instead of a blank page.

And it costs tokens, not retainer hours — which is exactly why it runs on a token-metered
pipeline rather than a per-seat subscription.

If you want to see the shape of the output, describe a problem you actually have. The report
appears in the page, usually under two minutes.

Build a Multimodal App in an Afternoon with FlintAPI

Yucong Chen — Wed, 28 Oct 2026 12:34:10 +0000

FlintAPI unifies a dozen Chinese AI models behind one OpenAI-compatible endpoint. Swap your base URL to https://flintapi.ai/v1 and start building in minutes. New accounts get free starter credit.

Why a unified API

Managing multiple provider accounts wastes engineering time. One key, one SDK, every model.

Get started

Send a request to /v1/chat/completions and switch models by changing one field.

Learn more at https://flintapi.ai

How Flint-Smart Routing Can Cut Your AI Bill

Yucong Chen — Wed, 28 Oct 2026 12:33:29 +0000

FlintAPI unifies a dozen Chinese AI models behind one OpenAI-compatible endpoint. Instead of juggling a dozen provider accounts, you send every request to https://flintapi.ai/v1/chat/completions and switch models by changing a single field.

Why automatic routing matters

Picking the right model per task is tedious and expensive. A flagship model is overkill for classification; a small model struggles with reasoning. Flint-Smart analyzes each prompt and routes to the best model for the job — usually the cheapest one that still does it well.

Get started

Point your OpenAI-compatible client at FlintAPI, set model=flint-smart, and ship. New accounts get free starter credit — no credit card required.

Learn more at https://flintapi.ai

The Chinese LLM Landscape in 2026: A Practical Guide

Yucong Chen — Wed, 28 Oct 2026 12:32:47 +0000

FlintAPI unifies a dozen Chinese AI models behind one OpenAI-compatible endpoint. Swap your base URL to https://flintapi.ai/v1 and start building in minutes. New accounts get free starter credit.

Why a unified API

Managing multiple provider accounts wastes engineering time. One key, one SDK, every model.

Get started

Send a request to /v1/chat/completions and switch models by changing one field.

Learn more at https://flintapi.ai

What we tell users when 9 of our 13 models are down

Yucong Chen — Wed, 28 Oct 2026 12:30:01 +0000

Update (2026-10-28, 21:44 UTC+8). The upstream account behind these models recovered within hours: GET /api/health/models now reports 11 of 13 healthy. The numbers below (four healthy, one account at minus three cents) are the state at the time of writing and are kept as the reason this contract exists — not as the current status. For the live number, always call the endpoint.
A gateway fails in two ways. The loud way is a 500. The quiet way is a model that
has been returning 503 for six hours while every dashboard says "active".

We shipped the quiet way twice this month. This is what we changed, and the
contract you can now check before you build against us.

The mistake

We had a health checker that did this, more or less:

for model in catalogue:
    if upstream_returns_2xx():   mark_healthy(model)
    else:                        mark_unhealthy(model)
        if model.unhealthy_for_2_checks(): deactivate(model)

Two assumptions in four lines, both wrong.

One: "unhealthy" is not always the model's fault. When the upstream account
runs out of balance, every model behind it fails at the same instant, with the
same error. My checker saw eight failures and dutifully deactivated eight models.
The models were fine. The account was empty. Deactivating them made the outage
longer, because now they would not even be retried.

The fix was a distinction the code did not previously have:

if all_checks_failed_with_account_level_error():
    log("SKIP auto-isolate: account-level failure (balance) -- do NOT deactivate")
else:
    isolate_the_single_bad_model()

Now that line exists in the log, and it looks like this:

[auto-isolate] SKIP kimi-k3: account-level failure (balance) -- do NOT deactivate the model

Two: "2xx from upstream" does not mean "works for this model name". Some
suppliers route by model name and return a perfectly valid 200 with an error body,
or accept the name in /models and reject it in /chat/completions. A health
check that only looks at status codes will mark those models healthy forever.

The contract we publish now

If a model is unavailable, the response is not a mystery. It is this, with
HTTP 503:

{
  "error": {
    "message": "Service temporarily unavailable: upstream model capacity is exhausted for the requested model. Please retry later or contact support@flintapi.ai.",
    "type": "service_unavailable",
    "code": "upstream_capacity_exhausted",
    "hint": "Other models may still be available right now: https://flintapi.ai/api/health/models",
    "available_models": ["deepseek-v4-pro", "deepseek-v4.1-flash", "glm-5.3", "glm-5.3-flash"]
  }
}

Three properties matter here:

A machine-readable code (upstream_capacity_exhausted), so your retry and failover logic does not have to parse English.
The list of models that are working right now, so a 503 is actionable — you can fall back without a human.
Retry-After, so a naive client does not hammer us in a loop.

And the single source of truth, which is public and needs no auth:

GET https://flintapi.ai/api/health/models

It returns total and healthy counts joined against the catalogue that we
actually serve. If that endpoint says four models are healthy, then four models
are healthy — we do not keep a second, prettier number anywhere else.

Why we do not "just multiply the model list"

It is tempting to advertise thirty models and route whatever works. That converts
our availability problem into your correctness problem: your temperature, your
token budget, your structured-output assumptions silently run on a different model
than the one you named. We would rather return a loud 503 for a named model than a
quiet 200 from a substitute.

If you do want substitution, it is opt-in: send model: "flint" and the router
decomposes the prompt and picks per sub-task, and it says which model answered.

The numbers, dated

As of 2026-10-28: 13 models in the catalogue, 4 healthy, because one upstream
account is at a negative balance of about three cents. This post exists partly
because that is an embarrassing ratio and partly because the interesting part is
not the ratio — it is that the ratio is published, checkable, and per-model
rather than hidden behind a green dashboard.

If you are running something similar, two checks are worth adding today:

Distinguish account-level failures from model-level failures before any automated isolation runs. Otherwise one billing problem takes out your whole catalogue and looks like thirteen separate bugs.
Return the currently-available list inside your error body. It costs one join and turns every 503 into a self-healing instruction.

Flint-Smart: The Model That Picks the Best Model

Yucong Chen — Wed, 28 Oct 2026 12:29:03 +0000

Flint-Smart: The Model That Picks the Best Model

Choosing the right AI model for every request wastes engineering time. Flint-Smart does it automatically.

How It Works

Send request with model: flint-smart
FlintAPI analyzes your prompt
Routes to the best model
Same API, smarter backend

Why This Matters

No model selection overhead
Always up-to-date
Cost-aware routing
One key, zero decisions

Try flint-smart free

Why Your AI Stack Needs a Unified API in 2026

Yucong Chen — Wed, 28 Oct 2026 12:28:44 +0000

Why Your AI Stack Needs a Unified API in 2026

Managing 15 different AI provider accounts in 2026 is like managing 15 different bank accounts. Every provider has their own SDK, auth scheme, rate limit, and pricing model.

FlintAPI solves this with one API key, a dozen models.

The Real Cost

A typical AI startup in 2026 juggles: DeepSeek for reasoning, Qwen for long context, GLM for Chinese, Kimi for coding. That is 4 API keys, 4 dashboards, 4 rate limit monitors. Engineering time spent on glue instead of product.

One Endpoint, All Models

Send requests to https://flintapi.ai/v1/chat/completions. Switch models by changing one field.

Try Free

New accounts get 20 dollars free credit. No credit card.
Get started

DeepSeek V4 Pro on FlintAPI: Quick Start

Yucong Chen — Wed, 28 Oct 2026 12:28:25 +0000

DeepSeek V4 Pro on FlintAPI: Quick Start

DeepSeek V4 Pro is one of the strongest reasoning models available.

Why DeepSeek V4 Pro

Top-tier reasoning for math, logic, code
128K context window
Competitive pricing through FlintAPI

Quick Start

Use the standard OpenAI-compatible endpoint with model deepseek-v4-pro.

Model Guide

Task	Best Model
Coding	deepseek-v4-pro, kimi-k2.6
Chinese	glm-5.1, qwen3.7-max
Long docs	qwen3.7-max
Fast/cheap	flint-smart

Get your API key

Selling tokens below cost — what a margin audit found in our own gateway

Yucong Chen — Wed, 28 Oct 2026 12:25:07 +0000

We run a small OpenAI-compatible gateway in front of Chinese LLMs. Today we did
something uncomfortable: we took our own rate card, divided every sell price by the
cost we pay upstream, and looked at the ratios. We expected a narrow spread. What we
found was a range from 0.13x to 12.5x, with five models priced below cost.

The worst offender was also the easiest to measure, because the upstream publishes its
price page and we have our own usage logs.

The arithmetic

deepseek-v4-pro is quoted by its vendor, per 1M tokens, in USD:

                        input (cache miss)   output
off-peak                        $0.66         $1.98
peak                            $1.32         $3.96

Peak hours are 01:00–04:00 and 06:00–10:00 UTC on weekdays; everything else is
off-peak. We were charging $0.98 in / $1.96 out.

Then we pulled every usage row for that model from our own database — 23 rows, 800
input tokens and 6,341 output tokens total, split by whether the request fell in peak
hours:

period     rows   input tok   output tok   we charged   upstream cost   margin
off-peak     10         680        6,121      $0.00647        $0.01257   -$0.00610
peak         13         120          220      $0.00030        $0.00103   -$0.00073
total        23         800        6,341      $0.00676        $0.01360   -$0.00683

Minus 101%. We were paying roughly two dollars for every dollar we billed, and the
sample was small enough that nobody had noticed. The input side was fine; the output
side was underwater at every hour of the day.

How this happens

Not through one bad decision. Through a series of locally reasonable ones:

The rate card was a collage. Some models were priced at 1.43x cost (sane), some at 3.3x (also fine, cheap models), some at 1.00x (no margin at all), and five below 1.0x. Each number was defensible when it was typed. Nobody ever computed the whole column.
Cost drifted under a fixed price. The upstream changed its price list at least once while our sell price sat still. A price you set once is a price you are accidentally holding against a moving cost.
The cost field itself was untrustworthy. One model's stored cost implied a 12x markup would be needed to break even — a strong signal that the stored number was wrong, not the price. If you multiply a bad cost by any margin, you get a confident wrong answer.

That third point is the one that generalizes. Before you reprice, audit the
denominator.

What "peak" does to a flat price

The same model costs twice as much between 06:00 and 10:00 UTC on a weekday. A single
flat output price therefore has to cover the peak, or it is only profitable on
weekends. If you publish one number per model, that number is a peak-hours number and
should be set that way — or you should say plainly that you route around the peak.

We have not finished repricing. The honest status is: we know which rows are safely
above cost, which rows are safely below, and which rows are blocked on getting a real
bill from a supplier whose price list we do not have. Guessing the last group would
just move the error.

The four checks we now run

Ratio audit, per row. sell / cost for input and output, weekly. Any row below 1.25x opens a ticket; below 1.0x is an incident.
Official list prices, not memory. Fetch the vendor's pricing page when auditing; third-party comparison sites disagreed with the vendor by up to 2x in our sample.
Realized margin from your own logs, not from the rate card. The rate card says what you intended. The usage table says what happened. Split by peak/off-peak and by cached/uncached input if the vendor bills them differently.
Do not reprice off an unaudited cost field. If the implied markup is absurd in either direction, the cost is the suspect.

Why publish this

Because the alternative is a quiet number that quietly gets worse. A gateway is a
margin business with a thin spread and a moving denominator; the failure mode is not a
crash, it is a ratio. And because a price article without a date is a rumour — so the
numbers above are dated 2026-10-28, and the live model list is at
/api/health/models.

If you are running something similar: pull one week of usage, join it to your cost
table, and compute the ratio per row. It takes twenty minutes and it is the most
uncomfortable twenty minutes of the quarter.

What Chinese LLM APIs actually cost in 2026 (measured per 1M tokens)

Yucong Chen — Wed, 28 Oct 2026 12:24:54 +0000

Prices for Chinese LLM APIs are quoted per million tokens, which is the least useful unit if you have never billed a request. A $0.01 model and a $2.45 model are not two points on one line: they are two different products, and the cheap one usually fails differently.

This is the table we measured on 2026-10-28 across the models our gateway serves. Every number below is the charged rate, per 1M tokens, in USD.

model                       input / 1M    output / 1M
doubao-seed-2-0-lite          $0.0100        $0.0300
doubao-seed-2-0-pro           $0.0100        $0.0400
doubao-seed-2-1-pro           $0.0120        $0.0500
glm-5.3-flash                 $0.0686        $0.2400
deepseek-v4.1-flash           $0.1286        $0.5143
glm-5.3                       $0.1500        $0.6000
qwen3.7-plus                  $0.3300        $1.3100
deepseek-v4-pro               $0.9800        $1.9600
kimi-k2.7-code                $1.0600        $4.4100
deepseek-v4-pro-thinking      $1.2000        $2.4000
kimi-k3                       $2.0000        $1.3400
qwen3.7-max                   $2.4500        $7.3500

Two rows deserve a second look, because they break the assumption that output costs more than input.

kimi-k3 charges $2.00 in and $1.34 out. deepseek-v4-pro-thinking charges $1.20 in and $2.40 out. If you estimate cost by multiplying input price by total tokens, you will be wrong on both, in opposite directions.

List price is not your bill

A price table multiplies tokens by rate. Your bill also depends on three things the table cannot show you.

Cached input. Some providers charge a fraction of list for a repeated prefix. A long system prompt that is billed once instead of forty times changes the arithmetic more than switching models does.

Reasoning tokens. A reasoning model can emit thousands of internal tokens before it writes anything. They are billed, they are not in your output, and they are the reason "why did this one-shot query cost ten times what I expected" has an answer.

Failures. A request that returns 200 with an empty choices[0].message.content still costs whatever was generated. In an early version of our own gateway we billed it as zero, and our margin silently inflated, because the only thing we counted was the response body.

The one line that shows your real number

Ask the API, not the pricing page. On an OpenAI-compatible endpoint, the response usually carries usage:

curl -s https://flintapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $FLINT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4.1-flash","messages":[{"role":"user","content":"Say OK"}],"max_tokens":64}' \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d.get("usage"))'

If usage comes back null, that provider is not telling you what it charged, and no price table will save you. This is not hypothetical: it is one of the first things we had to fix, because a gateway that cannot report usage cannot be audited by its own customer.

What actually decides your monthly cost

Not the per-token price. These three, in this order.

Which model you call by default. The gap between the cheapest and the most expensive row above is 245× on input. Nothing else you can change in one afternoon moves the number that much.
How much you send in the prompt. At $0.01/1M input, a 50,000-token context costs half a cent. At $2.45/1M it costs twelve cents. Same prompt, different order of magnitude.
How often you retry. A retry loop against a model that times out under load doubles your spend and gives you nothing to show for it.

That is the argument for routing rather than picking: the right model is per-request, not per-company. If the cheap model answers your classification step correctly, paying 245× for the expensive one is not caution, it is waste. And when the cheap one fails the check, you want the fallback in the same request, not in a retry you wrote yourself.

How to read this table honestly

These are the rates we charged on 2026-10-28: a dated snapshot of our own rate card, not an advertisement. They move, and they move without notice when a provider reprices, so the table above is dated on purpose — a price article without a date is a rumour. We do not currently publish a live per-model price endpoint: GET /api/health/models tells you which models are serving right now (no prices), and /pricing covers our consulting product only. For the current rate card, mail support@flintapi.ai and you will get today's numbers.

If you want the current numbers:

curl -s https://flintapi.ai/v1/models | python3 -m json.tool | head -40

And if you want to know what a specific prompt costs before you send it, run it once with a small max_tokens and read usage from the response. That number is the only one that is about you.

The character limit that silently killed our AI replies

Yucong Chen — Tue, 27 Oct 2026 07:19:31 +0000

A customer asked us a normal question. They got a reply that looked like a form letter.

It was polite. It was fast. It was completely useless. And nobody got an alert, because nothing failed in a way that looked like failing.

That is the kind of bug I want to talk about.

What we thought was happening

We have an internal helper that answers support mail. The idea is simple. Take the incoming question, add our own notes about the product, ask a model, send the answer.

The notes are not huge. About a page of text. We appended them to every prompt because it was easy, and because the model seemed happier with context.

For a while it worked. Then replies started degrading in a way nobody could name. Less specific. More filler. Shorter.

We blamed the model at first. Then we blamed the prompt. Both were wrong.

What was actually happening

Our consulting endpoint validates the incoming message length. There is a cap: 3000 characters. Anything longer is rejected before it reaches a model.

Our helper never saw the rejection as a rejection. The call came back as HTTP 400, the code treated anything that was not a success as "provider unavailable", and the fallback fired. The fallback is a friendly template. So the customer got a template, and our logs got one quiet line.

The annoying part is that HTTP 400 is not an outage. It is the server telling you the request was wrong. We read it as bad luck and tried again.

We found it by replaying the customer's own message through the helper. That took about a minute. What took days was not believing the evidence, because the logs said the reply had been sent, and it had. It was just the wrong reply.

If you want the shortest version of this story: our monitoring watched the wrong layer. The prompt assembly was broken, the transport was fine, and we were staring at the transport.

Nobody reads the quiet line.

Why this one took so long to find

Three things lined up badly.

The failure was silent by design. We had built a fallback so that users never see a raw error. That is usually a good instinct. Here it meant the symptom and the cause lived in different places.

The error was classified wrong. A length check returning a client error is not the same as a provider being down. Ours went into the same bucket, so the retry logic kept retrying something that could never succeed.

And the input was only sometimes too long. Short questions passed. Long ones with pasted logs did not. So it looked random, and random makes people guess.

What we changed

The validation error now has its own name in our code, and it does not retry. Retrying a too-long message is just spending money to fail again.

We also log the actual length of the message, next to the cap. That one number would have ended the investigation on day one.

And the fallback stopped being silent. When the fallback fires, it says so. A template that pretends to be an answer is worse than an error, tbh.

The part I am still thinking about

We removed the whole-document paste, which fixed the immediate problem. But the underlying shape is still there. Any time we add context to a prompt, we are spending a budget we do not measure.

So now we trim the notes per question, and we check the assembled size before sending. It is a few lines of code. It should have been there from the start.

If you run a helper like this, I would check one thing today. When your fallback fires, does anything actually tell you?

I think most of us have a template quietly answering for us right now, and we just do not know it yet.

If you want the token budget and the trimming rules we settled on, they're here.