---
title: "Comment by Kartik N V J K on \"Choosing an LLM API for production in 2026: not benchmarks\" | Hashnode"
description: "Separating time to first token from total generation time is the distinction I wish more procurement conversations started with, since a model that starts fast"
url: "https://hashnode.com/posts/llm-api-production-2026-enterprise-evaluation/6a4cd95ecf7ef55aeda78ad9/comment/6a4e86cb48654d032bdf3d1f"
---

[Discussion](https://hashnode.com/posts/llm-api-production-2026-enterprise-evaluation/6a4cd95ecf7ef55aeda78ad9)

Comment [Choosing an LLM API for production in 2026: not benchmarks](https://hashnode.com/posts/llm-api-production-2026-enterprise-evaluation/6a4cd95ecf7ef55aeda78ad9)

[Kartik N V J K](https://hashnode.com/@kartik-nvj)

[Jul 8](https://hashnode.com/posts/llm-api-production-2026-enterprise-evaluation/6a4cd95ecf7ef55aeda78ad9/comment/6a4e86cb48654d032bdf3d1f)

Separating time to first token from total generation time is the distinction I wish more procurement conversations started with, since a model that starts fast but crawls through a long answer fails a batch job while feeling perfectly responsive in interactive chat. The cost-per-workflow point is the other one people skip, because per-token pricing hides what retries and tool calls actually do to the bill. When you evaluate a provider, do you load-test P99 under a full queue before committing, or is that something teams only find out after the migration is already locked in?