Show HN: //Beforeyouship is a pre-build tool to estimate the LLM cost (llm-architecture-cost-modeler.vercel.app)

3 points by indiegoing ↗ HN
For one of my projects, I needed to choose an LLM but got lost in numbers and tokenization. So I searched for a solution which could help me do the math, but only found tools that helped with cost management and optimization at the production stage. I did some research and found that this is an existing problem, especially if you are a vibe-coder or solo developer starting an AI-powered app from scratch.

So I built an MVP to test with you guys — if any of you relate to the problem, please tell me what works and what's missing. Already included retries, prompt caching, batch discounts, and 3×/10× growth scenarios across 6 models (GPT-4o, Claude, Gemini, DeepSeek and more). Also the app models full architecture, the user just needs to pick an app type and set the usage pattern.

5 comments

[ 4.1 ms ] story [ 26.3 ms ] thread
Retry logic modeling is a great inclusion most cost estimates miss this completely. In my experience retries account for 15-25% of total cost in production agent systems, especially with tool calling where validation failures trigger re-prompts. Would be useful to see a "worst case" scenario that models cascading retries (retry triggers another tool call that also retries).
This is really valuable, especially the 15-25% figure from real production systems — current assumption of 8% is clearly too conservative for agent workloads with tool calling. The cascading retry scenario (retry triggers another tool call that also retries) is a great idea for a worst case column alongside the current realistic estimate. Going to look into this for v2.
I think this would be super useful as a claude code / visual studio extension, so I can see the cost impact of changes I am making in code. For example by adding a prompt pre-processing function how much am I actually going to save in LLM token cost.
That's actually a great direction I haven't thought about — bringing the cost estimate closer to the code rather than keeping it as a separate planning step. The delta view (how much does adding this preprocessing function actually save) would be super useful. Adding it to the v2 roadmap, thanks for this.
Really interesting angle — I've been working on the post-build side of this problem (finding waste in production LLM spend) and the pre-build estimation gap is something I hadn't thought about. The two tools solve different moments in the same problem: estimate before you build, profile after you ship. Would be curious whether your estimates hold up against what people actually spend in production — that delta seems like useful data for improving the model.