reggz · HackerTrans

há 3 mesesdiscuss

yeah you’re not wrong, but the issue is usually mixing pricing lanes. The clean comparison is plan-only vs plan+overflow vs usage-priced baseline for the same seat/activity assumptions. Buying credits is fine if it's part of your cost modeling (the only potential trap is setting it to auto-reload).

reggz

há 3 mesesdiscuss

The signal I’d care about is whether they can scope the task, prompt the model, review the output, explain tradeoffs and clean up what the model got wrong.

reggz

há 4 mesesdiscuss

can treat each internal agent like a small product: one owner, one budget, and one event ID that bundles retries and tool calls into the true cost per successful outcome.

If you only track provider spend, nobody knows what one useful outcome actually costs. Behavior changes should go through the same path as product changes (review/audit trail/rollback)

reggz

há 4 mesesdiscuss

I’d break it into a few separate numbers instead of trying to estimate one blended API cost.

We usually look at cost per workflow run, runs per active account, and the heavier paths separately, then keep retries and tool calls as their own line items. That makes the pricing side easier to reason about.

reggz

há 4 mesesdiscuss

I think there's the work and there's the compute bill. AI mostly changes the work side since you can finish faster but the compute cost is still real and can vary a lot. The way I’ve seen it handled is a fixed project fee with “normal” AI usage included, and if it turns into heavy runs or lots of experimentation that part gets billed separately.

Otherwise you end up paying the API bill yourself.

reggz

há 4 mesesdiscuss

If you're paying for model calls, retrieval, or other backend work on each request, charging earlier is a lot easier to justify because usage can literally cost you money while you're still figuring things out.

But I agree that it's feels like a mistake to charge before the value is obvious enough for someone to understand what they're paying for. Especially products with low marginal cost.

reggz

há 4 mesesdiscuss

In practice I’ve found agentic search does improve accuracy on harder queries, but the cost climbs pretty quickly once you move away from a single pass. More steps, more chances to call the model again, more room for retries. It compounds faster than you expect.

Plain RAG is easier to keep predictable if your retrieval is tight. But once chunk count grows and you start pushing larger contexts, quality drops and you end up compensating somewhere else.

What’s worked best for me is a hybrid. Cheap default path first, then only route ambiguous or high-value queries into the heavier agent flow.

Also I think cost per successful task is more meaningful than cost per query. The expensive path only makes sense if it actually reduces retries or downstream fixes.

comments