In almost every AI project meeting I've sat in, the cost conversation goes the same way. Someone asks, "Which model should we use?" Half the room argues for the expensive one, for quality. The other half argues for the cheap one, for scale. Eventually someone senior picks one, and everyone moves on.
Building SandurTech RevE taught me that this conversation is wrong in two ways.
First, "which model?" isn't one question. In our pipeline it turned out to be ten different questions, one per task, with ten different answers. Second, some of the biggest savings had nothing to do with model choice at all. They came from simply looking at where the money and the memory were actually going.
Get it right first, then make it cheap
We started sensibly, with one strong model, OpenAI's gpt-6.1-sol, for everything. Get the reading right, then worry about cost.
Over the whole first-draft development period of 4 days, we made 1,741 model calls for a total of about US$20. That's very cheap for a prototype. But the target wasn't a prototype. It was a tool a fabrication shop uses every day, on every enquiry, re-running drawings after corrections. A full drawing cost around US$0.69 to read, and early runs took well over ten minutes. That kills the experience of "upload and look".
Step one: read the bill before touching anything
Before changing a single model, we broke the bill down by task and by token type. Two things stood out.
Output was the lever, not input. About 61 percent of the cost was the model's output, including its internal reasoning. Tuning how hard the model "thinks" was worth more than squeezing the prompts.
No single task dominated. Reading text blocks and the parts list was about a quarter of the bill. Sorting parameters was another quarter. Finding blocks and checking box edges made up most of the rest. So no single model swap would fix the cost. It had to be decided task by task.
There was also an embarrassing early discovery. We'd been paying to set up prompt caching that was never reused, and on some steps that wasted cache was up to 94 percent of the input cost. No model choice would have found that. Reading the bill did.
Step two: a bake-off against the truth
The tempting move is to switch everything to the cheap model and see if anything looks broken. That's how you get a system that's cheaper and quietly worse.
Instead we ran a bake-off. We took three drawings whose readings had been fully reviewed by a person, so we had a trusted answer for every block, line, row and value. Then we ran every task several ways:
- the strong model, gpt-6.1-sol (US$2 per million input tokens, US$10 per million output)
- the same model with low reasoning effort, on OpenAI's discounted Flex tier, which is half price but slower
- the small model, gpt-6-luna (US$0.10 and US$0.50, about twenty times cheaper)
- a mix: the small model reads first, and the strong model reads again only where two reads disagree
The whole bake-off cost US$3.84. It's the best four dollars I've spent this year.
What the bake-off showed
Neither camp in the big-versus-small argument would have predicted the results.
The small model was an excellent reader. On the parts list it scored 99.8 percent against 99.9 for the strong model, at a tiny fraction of the cost. On tying balloons to parts, it actually scored higher.
The small model couldn't find things. Asked to look at a whole sheet and draw boxes around its tables and views, it agreed with the reviewed layout only about 54 percent of the time, against about 94.5 percent for the strong model. That isn't a small gap. It's a different capability.
Engineering judgement sat in between. For mapping parts to components and reading design data, the small model dropped to between 82 and 94 percent. The strong model with low reasoning on Flex held 96 to 99 percent at roughly half the price.
Some differences were just noise. The same strong model, run twice on the same drawing, varied by several points on block-finding. So we stopped pretending a one-point difference between models meant anything.
The resulting plan gives each task its own choice. The strong model at full service finds blocks. The small model reads parts lists, tables and balloons. The mix reads text blocks. The strong model with low reasoning on Flex handles judgement. The estimated cost per drawing fell from US$0.69 to US$0.32, a 54 percent cut, and the first real run on a fresh drawing came in at US$0.36.
The choice belongs to the user, with guardrails
We didn't hard-code the plan. In the app, every task has a small menu of models. The recommended choice carries a star, each option shows its bake-off score and cost, and the estimate for the whole run updates live. If a choice measured noticeably worse than the strong model, the app warns: expect more items to review.
Why give users the choice at all? Because cost sensitivity differs. A shop re-reading a drawing after a small correction may want the cheapest option. A shop quoting a critical exchanger may want the strongest everywhere. Making the trade-off visible is better than making it for them.
Speed: stop standing in a queue
The original pipeline made every call one after another, about 15 seconds each. But finding blocks on sheet 2 doesn't depend on sheet 1, and reading design data doesn't depend on reading the title block.
So we let independent work run side by side: up to four calls at once by default, with results reassembled in the same order so the output is identical to a one-by-one run. The parameter steps became a small dependency map, where some steps start together and others wait for what they need.
The run window shows this as a pipeline of boxes, with live call counts and cost in both dollars and rupees. When the user watched four sheets start at once for the first time, the speed-up finally felt real. A full run on a two-sheet U-tube exchanger now takes about six minutes.
The hidden cost that never appears on an invoice
Here's the saving I'm proudest of, and it had nothing to do with AI.
The customer will run RevE on a Windows laptop with 4 to 8 GB of memory. An A1 sheet rendered at high resolution is about 370 MB as a picture in memory, and our reading step kept full-sheet pictures around while cutting out blocks. On my Mac, nobody noticed. Measured honestly, one drawing peaked at 4.4 GB, and a four-sheet drawing was killed at over 6 GB. On the customer's laptop, that's a crash on the first real job.
The fix was simple once we saw it: render only the piece you need, at the resolution you need, and keep no full-sheet picture. Peak memory fell to about 0.3 GB, a reduction of over 90 percent, with identical results.
Memory never shows up on an API invoice. It shows up as a support call.
Never pay twice
Two small lessons were about respecting money already spent.
Resume must reuse what you've paid for. It mostly did, until one drawing with a long name reused only 2 of 22 saved answers. Log file names were being cut to 40 characters, so the lookups failed. After the fix, a resume on the same drawing reused 67 answers.
Stop must really stop. Early on, pressing Stop ended the visible run but not a background step, which kept making calls. Now Stop ends everything the run started.
Eight rules I'd give any team
I've run cost-reduction programmes in manufacturing for years, and the playbook is the same: measure, segment, then optimise each segment.
1. Read the bill before touching models. By task and by token type.
2. Run a bake-off on reviewed truth. A few dollars of measurement beats weeks of opinion.
3. Choose per task. Small models can be excellent readers and poor finders.
4. Respect the noise. If a model varies by five points run to run, a one-point difference means nothing.
5. Test discount tiers per task. Some tasks degrade on them and some don't.
6. Run independent work in parallel, and reassemble the results in a fixed order.
7. Count memory as cost. Design for the customer's machine, not yours.
8. Never pay twice, and show spend live. Limits, resume and visible cost build trust in the bill.
The cheapest call is the one you don't make. The second cheapest is the one made by the smallest model that's good enough for that specific task. The most expensive is a confident model on the wrong task. Measure which is which. It cost us less than four dollars to find out.
Next, in Part 9: "Where does my customer's drawing go?" How we kept confidential drawings confidential, without a local AI model.
#IndustrialAI #CostOptimisation #OpenAI #LLM #AIEngineering #MLOps #Manufacturing #ModelSelection #CloudCosts #SandurTech
Disclaimer
This series introduces SandurTech RevE, a product in development for AI-assisted engineering drawing analysis and generation. Examples reflect our current capabilities and ongoing validation. Outputs should be reviewed by qualified engineers and verified against approved drawings, standards, and project requirements before use.
