“Don’t Charge Me a Token Fee for Every Screw You Tighten”: 5 Types of AI Application Tasks That Shouldn’t Call a Large Language Model

Author’s note: Starting with Stardust Intelligence founder Lai Jie’s analogy—“don’t charge me tokens for every screw you tighten”—this article breaks down which parts of an AI workflow belong to fixed programs and which need a Large Language Model’s judgment.

On November 5, 2026, ifanr’s “Diversity Company” column published an interview with Lai Jie, founder and CEO of Stardust Intelligence. One quote has been repeated by many people building AI applications: “I want a fixed program tightening screws, running 24 hours a day. Don’t charge me tokens for every screw it tightens.”

This isn’t just a punchline. Lai was talking about how robots divide up work: an embodied model handles physical actions, then asks a foundation Large Language Model for help in natural language when it runs into a problem. Applied to software workflows, the same idea raises a practical question: Which parts of an AI application shouldn’t call a Large Language Model?

What you’ll get: This article translates the interview’s perspective on robotics into a way to define model invocation boundaries in software workflows. It covers five types of tasks that shouldn’t call a Large Language Model, a layered decision framework, and a routing code example you can adapt. One caveat: robots and software are different kinds of systems, so the application below is an analogy. You’ll need to validate the results against your own actual usage.

“Don’t Charge Me a Token Fee for Every Screw”: Key Takeaways

This quote comes from the final question of the interview. Asked what he hoped robots could free humans from, Lai Jie made it clear that he didn’t want them to “tighten screws in factories.” He believes robots are valuable because of their broad range of capabilities. From a cost perspective, he also argues that repetitive labor isn’t worth paying a token fee for every action.

It’s worth emphasizing that the interview presents the founder’s views; it doesn’t include measured cost data or independent verification. We’re drawing on the logic behind his proposed division of labor, not endorsing any specific conclusion.

Lai Jie’s “Video Call to Mom” Analogy: The Large Language Model Fills In Context

In the interview, Lai Jie offered an analogy that explains the division of labor better than “driving screws.” He said that if he wanted to cook but didn’t know how, he’d video call his mom. She might say, “First, put some oil in a hot pan,” without needing to tell him which bottle contains the oil. If he has questions, he can ask. The key is that his mom supplies contextual knowledge, but he must know how to pour the oil himself—she can’t do it for him over the phone.

For a robot, the embodied model needs to sense physical parameters on its own: weight, grip force, and whether it has a secure hold. It only asks the foundation Large Language Model questions like, “What should I do if I can’t get a firm grip and it’s a bit unstable?” Lai Jie believes training tactile information into the foundation model is “not impossible, but the cost isn’t justified, and communication bandwidth would also be an issue.” He added that this isn’t simply a hierarchy. It’s more like an ant colony made up of agents: each agent may not be especially capable on its own, but together they’re powerful.

This mapping is an interpretation developed for this article, not a direct quote from the interview. Robots face real-time control and communication bandwidth constraints in the physical world, while software workflows are more often constrained by token costs, latency, and stability. Their bottlenecks aren’t exactly the same.

Where AI Applications Shouldn’t Call a Large Language Model: 5 Criteria

When building the first version of an agent, many teams hand every step to a Large Language Model: format validation, date conversion, and even checking whether a field is empty. That makes for a quick prototype, but once it’s in production, you’re paying for deterministic work on every request—and introducing unnecessary variability.

Think of it like driving screws: some jobs don’t need a general-purpose intelligence. Here are five criteria for deciding whether a step warrants a Large Language Model call.

Routine steps suited to fixed code

The following tasks are typically like “driving screws”: they’re highly deterministic and repetitive, and using a Large Language Model can actually make them less reliable:

• Format validation and cleanup: Check email addresses, phone numbers, JSON structures, and required fields with regular expressions and schema validation.
• Data lookups and calculations: Query the database or call a business API directly for order status, inventory counts, and amount totals. Don’t ask a Large Language Model to “work them out.”
• Fixed-template output: Use a template engine to fill in variables for notification texts, standard acknowledgments, and report headers.
• Flow control and retries: Branching, timeout retries, rate limiting, and queuing belong in the orchestration layer and don’t need a model.
• High-frequency cache hits: When the same question comes up repeatedly, check the cache or FAQ database first and return the result directly if there’s a match.

Steps that really do need a Large Language Model’s judgment

By contrast, the tasks that warrant a foundation Large Language Model are the ones like “questions only Mom on the other end of the phone can answer”: clarifying an ambiguous user intent, synthesizing multiple sources into a conclusion, handling exceptions that existing rules don’t cover, or generating creative content. What these tasks have in common is that there’s no single correct answer, the rules can’t be exhaustively defined, and they come up relatively infrequently.

Specialized models sit between the two. Smaller models can often handle tasks like intent classification, entity extraction, sentiment analysis, and text vectorization. Think of them as a software version of an “embodied model”: they handle what they can themselves, then pass anything they can’t handle to the next layer as a clearly defined question.

Example: Layering an AI Workflow to Avoid Unnecessary Large Language Model Calls

Let’s use a common customer support ticket automation workflow to show how to apply model invocation boundaries to specific steps. This is a design example, not measured data from a real project.

As you can see, only one of the six steps requires a general-purpose Large Language Model. How many tokens you’ll save, whether the success rate drops, and how latency changes all depend on your traffic mix and rule coverage. You’ll need to evaluate those using actual logs.

Minimal Example: Rules First, Model as a Fallback

This code shows a minimal layered routing approach: first, rules intercept routine, “screw-type” requests; then a small model classifies the rest. Only complex cases go to a Large Language Model. Model names are examples—check the platform’s available model list for actual options.

import re
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI-compatible endpoint
)

def handle(query: str) -> str:
    # Layer 1: Fixed logic; don't call a model when rules can handle the request
    if re.search(r"(订单号|单号)\s*[:：]?\s*\d{8,}", query):
        return "已为您查询订单状态（走业务接口，不消耗 token）"
    # Layer 2: Use a small model for intent classification
    intent = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": f"只输出类别(咨询/投诉/其他)：{query}"}],
        max_tokens=5,
    ).choices[0].message.content.strip()
    if intent != "投诉":
        return f"已归类为：{intent}，转入标准流程"
    # Layer 3: Call the base Large Language Model only for complex complaints
    return client.chat.completions.create(
        model="claude-sonnet-4",
        messages=[{"role": "user", "content": f"请给出投诉处理建议：{query}"}],
    ).choices[0].message.content

import re
import time
import openai
from dataclasses import dataclass, field

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

SMALL_MODEL = "gpt-4o-mini"       # Example: small model for classification/extraction
LARGE_MODEL = "claude-sonnet-4"   # Example: Large Language Model for complex reasoning

@dataclass
class UsageLog:
    records: list = field(default_factory=list)

    def add(self, layer: str, tokens: int, latency: float):
        self.records.append({"layer": layer, "tokens": tokens, "latency": latency})

    def summary(self):
        result = {}
        for r in self.records:
            s = result.setdefault(r["layer"], {"count": 0, "tokens": 0, "latency": 0.0})
            s["count"] += 1
            s["tokens"] += r["tokens"]
            s["latency"] += r["latency"]
        return result

log = UsageLog()

RULES = [
    (re.compile(r"(订单号|单号)\s*[:：]?\s*\d{8,}"), "order_lookup"),
    (re.compile(r"(营业时间|几点开门)"), "faq_hours"),
]

def rule_layer(query: str):
    for pattern, action in RULES:
        if pattern.search(query):
            return action
    return None

def call_model(model: str, prompt: str, layer: str, max_tokens: int = 512) -> str:
    start = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        max_tokens=max_tokens,
    )
    tokens = resp.usage.total_tokens if resp.usage else 0
    log.add(layer, tokens, time.time() - start)
    return resp.choices[0].message.content.strip()

def handle(query: str) -> str:
    start = time.time()
    action = rule_layer(query)
    if action:
        log.add("rule", 0, time.time() - start)
        return f"[规则层] 执行动作：{action}"

    intent = call_model(
        SMALL_MODEL,
        f"只输出一个类别（咨询/投诉/其他），不要解释：{query}",
        layer="small",
        max_tokens=5,
    )
    if "投诉" not in intent:
        return f"[专用模型层] 归类为：{intent}"

    return call_model(
        LARGE_MODEL,
        f"你是资深客服主管，请针对以下投诉给出处理建议：{query}",
        layer="large",
    )

if __name__ == "__main__":
    for q in ["订单号：2026110612345 到哪了", "你们营业时间是？", "收到的商品破损，客服一直不回复"]:
        print(handle(q))
    print(log.summary())

🚀 Quick start: To draw reliable conclusions about tiered routing, switch between models at different tiers using the same interface and track usage. With APIYI apiyi.com, you can call both small and large models using a single API key and compare token consumption across tiers using the platform’s usage statistics. New users can start prototyping with free test credits.

The Impact of “Don’t Charge Me Tokens for Every Screw”

The diagram above shows the structural differences between the two designs, not measured results. For a meaningful comparison, run the same set of requests through both approaches on APIYI apiyi.com, then use the usage records to draw your conclusions.

Impact on Workflow Builders and Developers

• The design process flips: Instead of connecting a Large Language Model first and figuring out how to save money later, list every step, identify the “screws,” and then decide where to use the model.
• Where specialized models fit matters more: Just as an embodied model translates physical states into natural language, a middle layer can turn ambiguous input into structured questions, making each Large Language Model invocation more focused.
• Observability becomes essential: Once you introduce tiers, you need to track invocation counts, tokens, and latency for each one. Otherwise, you can’t tell whether a task should move up or down a tier.

Impact on Product Owners

• Costs become more predictable: Deterministic steps don’t consume tokens, so costs are concentrated in complex requests that can be estimated.
• You need to accept that “smarter” isn’t always better: Giving order lookup to a Large Language Model may look smarter, but what users really need is accuracy and speed.
• Define evaluation metrics early: Token consumption, task success rate, and end-to-end latency should serve as baselines for comparing the workflow before and after tiering, ahead of launch.

Impact on the Industry

Lai Jie’s view reflects a broader idea: increasingly powerful foundation models don’t mean every capability has to be packed into one model. Instead, “agents” with different capabilities can each handle their own tasks. In software, this aligns with the direction of tool calling and Agent orchestration. That said, the interview focused on robotics. There’s still a lack of public case-study data on how much this approach benefits software workflows, so more teams will need to put it into practice.

Frequently Asked Questions

“Don’t Charge Me Tokens for Every Screw”: Key Takeaways

• Source: This is a founder’s view from an Aifanr interview with Stardust Intelligence’s Lai Jie in November 2026.
• Division of labor: The execution layer performs actions on its own and asks the foundation Large Language Model for additional context only when it encounters difficult problems.
• Five “screw-turning” tasks: Format validation, data queries, template output, workflow control, and cache hits shouldn’t require calls to a Large Language Model.
• Three-layer architecture: Fixed programs form the foundation, specialized models handle the middle layer, and the foundation Large Language Model handles only open-ended and exceptional cases.
• Limits of the analogy: Conclusions about robots don’t automatically apply to software; validate the benefits with your own data.
• Three metrics to track: Compare token consumption, task success rate, and end-to-end latency before and after introducing layers.
• Getting started: Use APIYI apiyi.com’s unified interface to switch models across layers and monitor usage.

Summary

“Don’t charge me tokens for every screw” is fundamentally a reminder to rethink where AI workflows should—and shouldn’t—call a Large Language Model:

1. Identify the screws first: Assign highly predictable, frequent steps with a single correct answer to fixed programs.
2. Add specialized models next: Use small models for tasks with a limited set of categories and stable patterns, and to organize questions.
3. Bring in the Large Language Model last: Open-ended reasoning, decisions about exceptional cases, and creative generation are worth spending tokens on.

This approach doesn’t depend on a specific model or release. It can serve as an ongoing checklist for Agent design. When putting it into practice, be sure to use your own business logs to measure the differences before and after introducing layers, rather than assuming costs will automatically fall.

If you’re designing a layered workflow, you can use APIYI apiyi.com to access models of different sizes with a single API key, switch between them across layers, and compare usage statistics. Let the data decide who should turn each “screw.”

📚 References

1. ifanr – Interview with Stardust Intelligence’s Lai Jie: The 15th interview in the “Diversity Companies” series
2. Link: ifanr.com/1687805

3. Notes: The original source of the “turning screws and token fees” analogy and the proposed division of work between embodied models and foundation Large Language Models

4. OpenAI Chat Completions API documentation: Parameter reference for the OpenAI-compatible interface

5. Link: platform.openai.com/docs/api-reference/chat
6. Notes: Explains fields such as model, max_tokens, and usage to help implement usage tracking by layer

Author: APIYI Technical Team
Technical discussions: Contact us through the APIYI homepage. For more on model integration and usage tracking, visit the APIYI documentation center.