Most Lovable apps make the same mistake the first time they add AI classification: they call the strongest frontier model for a job that returns one label. The user waits on the model, the bill grows with every ticket, and the product still needs validation code because the model might answer in prose instead of structured JSON output.
Classification, extraction, and routing are not frontier-model problems. They are output-bounded tasks, which means the answer is short, typed, and easy to evaluate. If your app needs to classify a support ticket, extract invoice fields, or route a request to the right handler, a small fast model plus caching usually beats the expensive path.
This is where production AI starts to look less glamorous and more useful. The win is not "use AI everywhere." The win is proving whether a 1.2-second interaction can move toward a few hundred milliseconds, cutting a 10,000-ticket GPT-4o-mini workload from $76.50/month to below $30 in model spend, and knowing exactly when no LLM should run at all.
The three workloads show up in almost every AI feature
Classification turns text into a label from a fixed set. Think billing, bug, feature, auth, or other for a support ticket. The output is tiny, which makes LLM classification cost mostly a function of input size, prompt design, and how often you call the model.
Extraction turns messy input into a typed object. In an invoicing product like Incasez, where the flow goes from draft to e-Factura in under 30 seconds, the useful AI job is not writing a paragraph about an invoice. It is extracting supplier, buyer, VAT, totals, due dates, and line items into fields your system can validate.
Routing decides what happens next. A request might go to a cheap model, an expensive model, a human, a deterministic parser, or a background queue. Done well, routing is the layer that stops your app from paying frontier prices for every easy decision.
Frontier models are the wrong default for short answers
Frontier models are valuable when the output is long, reasoning-heavy, or ambiguous. They are wasteful when your app needs one enum and a confidence score. If your expected answer is { "priority": "urgent" }, you do not need the same model you would use for multi-step legal analysis.
The May 2026 pricing snapshot should be treated as a deploy-time checklist, not a permanent truth. At the time of writing, the cheap candidates worth checking first looked like this:
| Model | Input / 1M | Cached input / 1M | Output / 1M | Why it matters |
|---|---|---|---|---|
| GPT-5 nano | $0.05 | $0.005 | $0.40 | Cheapest current OpenAI candidate for simple classification, with structured outputs support. |
| GPT-4o-mini | $0.15 | $0.075 | $0.60 | Still a strong small-model default with strict structured outputs and Batch support. |
| Claude Haiku 4.5 | $1.00 | $0.10 cache reads | $5.00 | More expensive raw tokens, but prompt caching can matter for long shared taxonomies. |
| Gemini 2.5 Flash-Lite | $0.10 | $0.01 | $0.40 | Google's current low-cost stable path, with lower Batch pricing for async work. |
Those numbers will change. The shape usually does not: short outputs reward small models, cached prompts, and batching.
At appssemble, the practical rule we use in our AI work is simple. Start with the cheapest model that passes your eval set, then promote only the cases that fail. You do not save money by picking a worse model; you save money by making the model compete on your real labels before it touches production traffic.
GPT-4o-mini wins often, but prompt caching can flip the answer
GPT-5 nano now belongs in the first eval run for one-label jobs because the raw price is lower. GPT-4o-mini is still a strong default for classification and extraction because it is cheap, fast enough for many product flows, and has a mature strict-structured-output path. For a simple taxonomy under 1,000 tokens, we would usually test both before promoting anything larger.
Claude Haiku becomes more interesting when the prompt has a long shared prefix: taxonomy, schema, examples, policy notes, and edge cases. Anthropic prompt caching can cut cached input reads to 10% of the normal input price, turning a stable 4,000-token instruction block from a repeated tax into a shared asset. On workloads where most of the spend is reusable prompt text, that is how an RCA pipeline can move from $720/month toward $72/month after cache markers.
Imagine you are running a Lovable + Supabase support dashboard with five ticket categories and 10,000 tickets a day. A naive GPT-4o-mini synchronous setup at 500 input tokens and 300 output tokens lands around $76.50/month: 150M input tokens at $0.15/M plus 90M output tokens at $0.60/M. Batch the work and the model bill drops to about $38.25/month; add a 25% exact or semantic-cache hit rate, and the model portion falls below $30/month before embedding and cache infrastructure.
Latency is usually the bill your users notice first
Token pricing is visible in your provider dashboard. Latency is visible in your product. In our research notes, a Supabase Edge Function calling OpenAI or Anthropic for a 200-token input and 50-token output lands around 1.0 to 1.5 seconds p50 once you include first token, generation, and the network leg. Treat that as a benchmark to rerun in your own region, not as a provider guarantee.
That is fine for a background task. It is not fine when the user is staring at a modal that says "classifying." For latency-critical routing, Groq Llama 3.1 8B is worth testing because Groq lists high token throughput and JSON object mode. Cerebras is also worth testing for speed, but do not anchor a new production path to llama3.1-8b without checking the replacement model, because Cerebras lists that model for deprecation on May 27, 2026.
The serverless tax still matters. Supabase documents that Edge Function cold starts are possible, and our own AI-function measurements have seen cold invocation overhead land in the low hundreds of milliseconds depending on bundle size and region. If your target is sub-500ms p95, you need a cache hit, a fast model path, or a design that does not block the user.
Structured outputs are the difference between a feature and a cleanup job
Classification and extraction only help if your code can trust the output shape. "Looks like JSON" is not enough. Your app needs an enum, a number, a required field, and a rejected response when the model violates the contract.
OpenAI strict JSON Schema is the lowest-friction path when you use GPT-5 nano or GPT-4o-mini. In TypeScript, the Vercel AI SDK generateObject pattern with Zod gives you provider-aware object generation and validation that fits naturally inside Supabase Edge Functions. Instructor and BAML are good options when you need Pydantic-first or schema-first workflows across providers.
The key is to treat structured JSON output as part of the product contract, not as prompt decoration. A category field should only contain known categories. A confidence score should be bounded. A missing invoice total should fail validation before it reaches billing logic.
Sometimes the cheapest model is no model
The fastest classifier is a rule that never calls an API. Email addresses, phone numbers, URLs, hashtags, file extensions, duplicate checks, and obvious profanity do not need an LLM. Regex, keyword rules, MinHash, BM25, and lightweight local models are boring because they work.
The production pattern is regex for the easy 80%, model for the ambiguous 20%. PII redaction is the clean example: catch emails, phone numbers, card-like strings, and IDs with deterministic checks first, then send only uncertain leftovers to the model. You get lower cost, lower latency, and a more auditable system.
Before adding an LLM, write 20 real inputs and expected outputs. If 18 of them can be handled with rules, ship the rules and reserve the model for the last two. That is not anti-AI. That is how small-model production AI stays cheap enough to survive real usage.
The architecture is cache first, model second
The reference shape we would ship in a Lovable app is straightforward: client to Supabase Edge Function, exact cache lookup, deterministic gate, semantic cache for high-repetition natural-language inputs, fast model call, Zod or strict-schema validation, then write the result back to cache. The model is not the first line of defense. It is the fallback after cheaper paths have had their shot.
For latency-critical classification, we would test Groq Llama 3.1 8B first and keep the model-deprecation page in the deployment checklist for any Cerebras path. For ordinary extraction and routing, we would test GPT-5 nano and GPT-4o-mini with strict structured outputs. For taxonomy-heavy workloads with long shared instructions, we would test Haiku with prompt caching and compare total cost on your traffic shape.
The last piece is evals. A 50-example labeled set is enough to compare three models on your real data, catch taxonomy drift, and alert you when accuracy drops for two days running. The cheaper the model, the more the eval set matters, because you are buying cost savings with discipline.
Cheap classification only works when you measure it
The wrong lesson is "always use the cheapest model." The right lesson is that classification, extraction, and routing are measurable tasks. When the output is short and structured, you can compare models, cache aggressively, batch non-urgent work, and keep frontier calls for the cases that earn them.
That is how you turn AI from a demo into a production feature inside a Lovable + Supabase app. Not by paying 10x for every request, but by building the small path first and proving where the expensive path is needed.
Before you replace the model call, build a 50-example eval set and run the cheap path against real tickets. If the cheap path passes and the measured p95 stays under your UI budget, ship it. If it fails, route only the failing cases to the expensive model.
If your classification is already costing you money or users are waiting on every model call, book a call and we can help you redraw the path.
Built by developers. Accelerated by AI.