At a glance
Role and impact
Discovery, forecast design, model evaluation and the weekly run in production.
Production model at ~USD 5 a year instead of USD 83, with the same quality. First run: 72 of 72 batches, for USD 0.17.
Methods and tools
DiscoveryData fixed at the sourceRecall and precisionSpot-check of tricky casesAPI terms reviewEcoLogits carbon estimateClaude Code
The problem
About 560 products from two suppliers, a 15–20 day lead time, no shared product code between the supplier's sheet and the stock system, and boxes of 90 or 100 units that take months to sell.
What I did
- Fixed the data at the source: the supplier code went into the stock system for every product.
- Benchmarked 4 models against the owner's real order (recall and precision), plus a 13-product spot-check of tricky cases.
- Weighed cost, reliability and data terms. Gemini was discarded because its free tier can use client data.
Result
What I learned
The differences came from the data, not the model: products that had been out of stock looked like products with no demand. The next step was better inputs, not a bigger model.
Read the full case
Overview
THE COMPANY
Opción Eco is a wholesale aromatherapy distributor in Córdoba, Argentina. Its main supplier sends a spreadsheet with hundreds of products, and the owner, who also does the buying, reviewed stock product by product to decide what to order.
MY ROLE
Discovery, design of the forecast, the model evaluation, and running it in production every week.
Problem space
PROBLEM IDENTIFICATION
The goal: turn two days of manual review into a reviewable order proposal she could check in a few hours.
WHAT MADE IT HARD
- No shared product code between the supplier's order sheet and the stock system. We fixed it at the source: the supplier code went into the stock system for every product, so the data joins natively instead of by fuzzy name matching.
- Large pack sizes. Some products only come in boxes of 90 or 100, which would take months to sell. A rigid "always order" or "never order" rule wouldn't match how the owner buys, so those lines are flagged as budget-dependent and ranked with a running total, so she can cut at her budget.
Hypothesis
An LLM could add judgement a flat formula can't (bulk packs, sudden demand jumps, slow movers), but a bigger model wouldn't necessarily be better. The choice should come from the task, not from a leaderboard.
Solution space
THE BAKE-OFF
Four models, one shared specification, the same 560 products in batches of 8:
- Gemini Flash-Lite (Google)
- DeepSeek Flash (DeepSeek)
- GLM-5.3-Flash (Z.ai)
- Claude Sonnet 5 (Anthropic)
HOW I JUDGED THEM
- Against the owner's real order, not against my own formula: recall (her products the model also picked) and precision (model picks she also ordered). "Exact match" was discarded, because hundreds of products that are zero in both inflated it to ~81%.
- A 13-product spot-check of tricky patterns: bulk packs, demand jumps, slow movers.
- Cost, reliability and data terms from each provider's API terms, plus an estimated carbon range per run.
Results
Three models reached the same quality, so the decision came down to cost, reliability and data handling. GLM-5.3-Flash went to production at ~USD 5 a year. Gemini was discarded because it only echoed the reference formula (98% identical answers) and its free tier allows client data to be used to improve Google's products. Sonnet stays as the fallback. The owner confirmed she was comfortable with her stock and sales data being processed by the chosen provider.
ESTIMATED CARBON PER RUN
Nobody publishes energy or emissions per request, so I estimated them with the EcoLogits method from each model's size, data-centre efficiency and electricity grid. The low figure counts one GPU and output tokens only. The high figure follows the method as published, which counts every GPU needed to hold the whole model.
| Model | g CO₂e per run (560 products) |
|---|---|
| Gemini Flash-Lite | 1.6 – 8.8 |
| Claude Sonnet 5 | 4.7 – 362 |
| GLM-5.3-Flash (chosen) | 7 – 192 |
| DeepSeek Flash | 15 – 616 |
The ranges overlap too much to rank the models, so carbon didn't decide the choice; cost and reliability did. The first production run (576 products) came to 8–232 g CO₂e. At one run a week, that's about 0.4–12 kg CO₂e a year. It's an estimate, not a measurement: one assumption, how many GPUs serve the model, moves the result 20–40×.
Release and outcomes
- Weekly, before each order, at the owner's request. The first run went out on 8 October: 72 of 72 batches without errors, for USD 0.17.
- The proposal reads like a decision: "order this week" or "no need to order", essential lines first, then budget-dependent lines with a running total.
- Every run logs its cost and estimated CO₂e automatically, a sustainability figure the company can report every week.
What I learned
When we compared the suggestions with the order she actually placed, the differences came from the data, not the model. Products that had been out of stock showed no recent sales, and no model could tell that apart from no demand. The next improvement was better inputs (90 days of sales and an out-of-stock flag), not a bigger model.