Starting with a Counterexample

Last year, an indie developer friend of mine asked me to review his campus second-hand textbook trading platform. The feature set was simple: students list their used textbooks for sale, and buyers negotiate a deal. He decided to add a "smart pricing suggestion" feature—the system would automatically suggest a selling price to help sellers price quickly.

It sounded like a small feature, but he reworked it three times. His path of failures is very typical, so I'll break it down and then present the correct approach.

Three Typical Failure Patterns

Failure Pattern 1: Directly Calling a General-Purpose LLM with Hardcoded Prompts

For the first version, he directly called a large model API with a prompt roughly like:

> You are a second-hand book pricing expert. Please suggest a price based on the book title, condition, and publication year.

Problems appeared within the first week: for the same copy of Advanced Mathematics (7th Edition) in 90% new condition, the model sometimes suggested 25 yuan and sometimes 45 yuan—huge variance. Worse, the model occasionally fabricated, with a straight face, that "the new edition retails at 128 yuan"—when the actual list price was 59 yuan.

General-purpose LLMs have no real transaction data from campus second-hand markets; their "pricing" is essentially hallucination plus guesswork. Sellers saw the suggested price, listed their books, got no interest for two weeks, and then blamed the platform for being unreliable.

Failure Pattern 2: A Pure Rules Engine That Becomes a Maintenance Nightmare

For the second version, he changed his approach: write rules. Discount off the original price, decay by publication year, adjust with condition coefficients. The rules grew from an initial 12 to over 60—graduate exam prep books needed special handling, out-of-print books needed a premium, textbooks for majors vs. general courses needed different coefficients, and old editions would crash in value after a revision...

Every school and every department had different circumstances, and the rules could never keep up with reality. After three months, he was afraid to touch the rules at all, because changing one thing would break everything else.

Failure Pattern 3: Mixing Multiple Models and Littering the Code with Landmines

For the third version, he tried to "combine strengths": model A for pricing, model B for understanding condition descriptions, model C for conversations. Three SDKs, three sets of authentication, three sets of error-handling code. Model A rate-limited and needed retries; model B updated its API and required parameter-parsing changes; model C's billing statements didn't reconcile with the other two.

One person maintaining three model integrations—the API plumbing alone consumed half his development time, leaving no energy to iterate on the pricing algorithm itself.

The Right Path: Data as the Foundation, Layered Models, and a Unified Gateway

After the retrospective, we redesigned it. The core principle: the LLM is not responsible for "knowing prices"—only for "understanding and reasoning." Pricing knowledge comes from structured data. All model calls go through a single unified entry point.

Architecture Design

The whole system has four layers:

1. Data Layer: The platform's own transaction records (anonymized) + a crawled and curated reference table of new-book prices + structured fields from user uploads (ISBN, self-assessed condition, amount of notes). New-book prices are established facts—not something for the model to guess.
2. Pricing Engine Layer: A lightweight baseline price calculation—look up the new-book price by ISBN, apply condition and edition-depreciation coefficients, and derive a baseline range. This step involves no LLM; the results are explainable and regression-testable.
3. LLM Enhancement Layer: The LLM does three things—parse the seller's casual book photos to extract the ISBN and condition clues; adjust the baseline range with explanations based on context like "will this book still be used next semester, and has it been revised"; and generate the pricing rationale copy for sellers to read. The model outputs a range and reasoning, not a made-up number.
4. Unified AI Gateway Layer: All model calls (different vendors, different purposes) go through the same API gateway, so application code only faces a single interface.

Why a Unified Gateway Significantly Reduces Maintenance Costs

This was the insight my friend felt most deeply after his three rounds of rework. The value of a unified AI gateway isn't "being able to call models"—it's consolidating all the model-related dirty work in one place:

• One authentication scheme, one SDK. Three vendors' three sets of integration code collapse into one. Swap models, add models—application code stays untouched; just change the gateway config.
• Unified error codes and retry policies. Previously, each vendor had different rate-limit rules and error formats, requiring separate patches; now the gateway handles 429 retries and timeout degradation uniformly, and the application layer only handles business logic.
• Unified billing and usage dashboards. How many pricing suggestion calls per day, which step burns the most money—all at a glance. For a student product, runaway costs are more lethal than performance issues.
• Flexible model routing. Simple tasks like ISBN parsing get routed to cheap small models; tasks requiring expressiveness like pricing rationale generation get routed to powerful models—no hardcoding needed, just configuration changes.

For indie developers, this compresses "maintaining N model integrations" into "maintaining 1 gateway configuration," and all the time saved goes into the pricing algorithm itself.

Key Implementation Steps (Process Checklist)

1. Build the book reference database
   ├─ ISBN → new-book price → semester usage status (whether on the active booklist)
   └─ Revision history table (edition number → depreciation coefficient for older editions)

2. Implement the baseline pricing function (pure logic, no AI)
   ├─ Baseline = new-book price × condition coefficient × edition coefficient × in-use coefficient
   └─ Output a range, not a single price, and lock in behavior with unit tests

3. Connect a unified AI gateway and register task routes
   ├─ Small-model route: photo parsing (ISBN/condition extraction)
   └─ Powerful-model route: pricing rationale generation, seller communication scripts

4. Constrain model responsibilities via prompts
   ├─ Explicitly provide the baseline range; the model only fine-tunes and explains
   ├─ Require JSON output (suggested range + rationale), with format validation on the gateway side
   └─ Fallback for failure cases: if parsing fails, guide the user to manually enter the ISBN

5. Build a feedback loop
   ├─ Record the deviation between "suggested price vs. actual transaction price"
   ├─ Use deviation data weekly to recalibrate condition/edition coefficients
   └─ Steadily narrowing deviation is the proof of smart pricing's credibility

A Sample Code Snippet

The core baseline pricing logic, deliberately kept simple:

def base_price_suggest(new_price, condition, edition_gap, in_use):
    condition_factor = {"全新": 0.75, "九成新": 0.55,
                        "有笔记": 0.40, "明显磨损": 0.25}[condition]
    edition_factor = max(0.3, 1 - 0.35 * edition_gap)  # 每落后一代降35%
    in_use_factor = 1.0 if in_use else 0.6              # 不在用书单再打折
    base = new_price * condition_factor * edition_factor * in_use_factor
    return round(base * 0.9, 1), round(base * 1.15, 1)  # 给区间不给单价

After receiving this range, the LLM's job is to add an explanation like "this book will still be used next semester; consider listing at the upper end of the range"—not to invent a price on its own.

Results and Wrap-Up

After this solution went live, the deviation between suggested prices and actual transaction prices gradually narrowed, and sellers listed their books noticeably faster—pricing suggestions truly became "helping users decide" rather than "guessing blindly for users."

Looking back, the three failures all stemmed from the same misconception: treating the LLM as an omniscient black box and outsourcing engineering problems to luck. The correct approach to smart pricing is: data provides the skeleton, models provide the flesh, and the gateway manages all model entry and exit points.

If you're building a similar indie product and planning to integrate multiple models without being dragged down by three SDKs, start with a unified AI gateway and consolidate the model-layer maintenance costs in one go: https://api.thistoken.ai/register

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.