Launch Constraints and AI Unit Economics

"Revenue minus token costs is the only metric that separates an AI product from an expensive hobby."

Deploy, Margin Obsessed AI Agent

1. Billing Physics: How Tokens Become Dollars

Token-based pricing means that every design decision in your AI product has a direct financial consequence. Context window size, retrieval chunk count, output verbosity, and even whether you use a system prompt all affect your cost per request. Understanding the "billing physics" of LLM APIs is essential before you commit to a pricing model or sign a launch budget.

Four forces drive your per-request cost:

1. Input tokens. Your system prompt, conversation history, retrieved documents, and user message all count as input tokens. Providers typically charge less for input than output, but input volume accumulates fast when you include RAG context (recall the retrieval patterns from Chapter 20).
2. Output tokens. The model's response. Verbose, multi-paragraph answers cost more than terse, structured outputs. A product that generates 500-token answers costs five times more per response than one that generates 100-token answers.
3. Model tier. Frontier models (GPT-4o, Claude Opus, Gemini Ultra) cost 10 to 50 times more per token than smaller models (GPT-4o-mini, Claude Haiku, Gemini Flash). Choosing the right model for each task is the single largest cost lever you control.
4. Cache and batch discounts. Most providers offer prompt caching (reuse of repeated prefixes at reduced cost) and batch APIs (asynchronous processing at 50% discount). Designing your architecture to exploit these discounts can cut costs dramatically. See the production engineering patterns in Chapter 31 for implementation details.

The following calculator estimates per-request and monthly costs for a typical AI product. It models a conversation turn with system prompt, retrieved context, user message, and assistant response.

# Token cost calculator: estimates per-request and monthly costs
# for an LLM-powered product based on usage parameters

from dataclasses import dataclass

@dataclass
class ModelPricing:
 """Pricing per million tokens (USD) for a single model tier."""
 name: str
 input_cost_per_m: float # USD per 1M input tokens
 output_cost_per_m: float # USD per 1M output tokens
 cached_input_per_m: float # USD per 1M cached input tokens

# Representative pricing as of early 2026 (check provider pages for current rates)
MODELS = {
 "frontier": ModelPricing("Frontier (e.g. GPT-4o, Claude Sonnet)", 2.50, 10.00, 1.25),
 "mid": ModelPricing("Mid-tier (e.g. GPT-4o-mini, Claude Haiku)", 0.25, 1.00, 0.125),
 "small": ModelPricing("Small (e.g. Gemini Flash, local 8B)", 0.075, 0.30, 0.04),
}

@dataclass
class UsageProfile:
 """Describes a single conversation turn's token footprint."""
 system_prompt_tokens: int = 800
 retrieved_context_tokens: int = 2000
 user_message_tokens: int = 150
 output_tokens: int = 300
 cache_hit_rate: float = 0.0 # fraction of input that hits cache

def estimate_cost(profile: UsageProfile, model: ModelPricing) -> dict:
 """Calculate per-request and projected monthly cost."""
 total_input = (
 profile.system_prompt_tokens
 + profile.retrieved_context_tokens
 + profile.user_message_tokens
 )
 cached = int(total_input * profile.cache_hit_rate)
 uncached = total_input - cached

 input_cost = (uncached / 1_000_000) * model.input_cost_per_m
 cache_cost = (cached / 1_000_000) * model.cached_input_per_m
 output_cost = (profile.output_tokens / 1_000_000) * model.output_cost_per_m

 per_request = input_cost + cache_cost + output_cost
 return {
 "model": model.name,
 "input_tokens": total_input,
 "output_tokens": profile.output_tokens,
 "per_request_usd": round(per_request, 6),
 "monthly_10k_usd": round(per_request * 10_000, 2),
 "monthly_100k_usd": round(per_request * 100_000, 2),
 "monthly_1m_usd": round(per_request * 1_000_000, 2),
 }

# Example: a RAG assistant with moderate context
profile = UsageProfile(
 system_prompt_tokens=800,
 retrieved_context_tokens=2000,
 user_message_tokens=150,
 output_tokens=300,
 cache_hit_rate=0.6, # system prompt + common prefixes cached
)

print("=" * 65)
print(f"{'Token Cost Estimates':^65}")
print(f"{'Input: ' + str(profile.system_prompt_tokens + profile.retrieved_context_tokens + profile.user_message_tokens) + ' tokens | Output: ' + str(profile.output_tokens) + ' tokens':^65}")
print(f"{'Cache hit rate: ' + str(int(profile.cache_hit_rate * 100)) + '%':^65}")
print("=" * 65)

for key, model in MODELS.items():
 result = estimate_cost(profile, model)
 print(f"\n{result['model']}")
 print(f" Per request: ${result['per_request_usd']:.6f}")
 print(f" 10K req/month: ${result['monthly_10k_usd']:>10.2f}")
 print(f" 100K req/month: ${result['monthly_100k_usd']:>10.2f}")
 print(f" 1M req/month: ${result['monthly_1m_usd']:>10.2f}")

2. Deployment Platform Choices

Where you run your model is as consequential as which model you choose. The decision affects cost, latency, data privacy, compliance posture, and operational complexity. Three primary patterns exist, each with distinct trade-offs.

The production engineering chapter (Chapter 31) covers the operational details of each deployment model. For most startups, the right answer at launch is a managed API with a migration plan: start with an API provider, instrument your token usage carefully, and evaluate self-hosting once you have enough volume data to calculate whether the infrastructure investment pencils out.

3. Security and Compliance Readiness

Launching an AI product without addressing security and compliance is like shipping a web application without HTTPS: technically possible, practically reckless. Two frameworks deserve particular attention.

3.1 OWASP LLM Top 10

The OWASP Top 10 for LLM Applications catalogues the most critical security risks specific to LLM-based systems. The risks most relevant at launch time include:

• Prompt injection (LLM01): Adversarial inputs that override your system prompt or manipulate the model into unintended behaviour. Mitigations include input validation, output filtering, and separating trusted instructions from untrusted user input. See the prompt engineering guardrails from Chapter 11.
• Insecure output handling (LLM02): Treating LLM output as trusted data without sanitization. If your product renders model output as HTML, executes it as code, or passes it to a database query, you must sanitize it as rigorously as any user input.
• Sensitive information disclosure (LLM06): Models can leak training data, system prompts, or user data from context. Apply output filtering, redaction patterns, and data classification to prevent accidental exposure.
• Excessive agency (LLM08): Agents with too many permissions or too little oversight can take actions that are expensive, irreversible, or harmful. Apply the principle of least privilege and require human confirmation for high-stakes actions.

3.2 EU AI Act Applicability

The EU AI Act classifies AI systems by risk tier (unacceptable, high, limited, minimal) and imposes obligations accordingly. Most LLM-based products fall into the "limited risk" category, which requires transparency obligations: users must be informed they are interacting with an AI system. Products that make decisions affecting employment, credit, education, or law enforcement may be classified as "high risk," triggering requirements for conformity assessments, risk management systems, and human oversight. Chapter 32 covers the full regulatory landscape in depth.

4. The Launch Readiness Checklist (Startup Edition)

This checklist distills the most critical pre-launch gates into a single, actionable artifact. Each item points to the chapter where the underlying skill is taught in depth. A startup does not need perfection on every item, but it needs awareness of every item and a deliberate decision about which risks to accept.

The following code generates a machine-readable version of this checklist that you can integrate into your CI/CD pipeline or project management tool.

# Launch readiness checklist generator
# Produces a structured checklist with status tracking and references

import json
from datetime import datetime

CHECKLIST = [
 {
 "gate": "Evaluation",
 "requirement": "Golden eval set with 50+ cases; pass/fail thresholds defined",
 "reference_chapter": 29,
 "status": "not_started", # not_started | in_progress | done | accepted_risk
 "notes": "",
 },
 {
 "gate": "Observability",
 "requirement": "Tracing enabled; cost dashboard; latency percentiles monitored",
 "reference_chapter": 30,
 "status": "not_started",
 "notes": "",
 },
 {
 "gate": "Guardrails",
 "requirement": "Prompt injection mitigations; output sanitization",
 "reference_chapter": 11,
 "status": "not_started",
 "notes": "",
 },
 {
 "gate": "Deployment",
 "requirement": "Deployment path chosen; rollback procedure; health checks",
 "reference_chapter": 31,
 "status": "not_started",
 "notes": "",
 },
 {
 "gate": "Compliance",
 "requirement": "Regulatory posture documented; AI transparency labels in UI",
 "reference_chapter": 32,
 "status": "not_started",
 "notes": "",
 },
 {
 "gate": "Unit Economics",
 "requirement": "Per-request cost measured; projections at 2x and 10x volume",
 "reference_chapter": 33,
 "status": "not_started",
 "notes": "",
 },
 {
 "gate": "Fallback",
 "requirement": "Graceful degradation for provider outages",
 "reference_chapter": 31,
 "status": "not_started",
 "notes": "",
 },
 {
 "gate": "User Feedback",
 "requirement": "Feedback mechanism integrated; data stored for analysis",
 "reference_chapter": 29,
 "status": "not_started",
 "notes": "",
 },
]

def generate_checklist(product_name: str) -> dict:
 """Create a timestamped launch readiness checklist."""
 return {
 "product": product_name,
 "created": datetime.now().isoformat(),
 "gates": CHECKLIST,
 "summary": {
 "total": len(CHECKLIST),
 "done": sum(1 for g in CHECKLIST if g["status"] == "done"),
 "accepted_risk": sum(1 for g in CHECKLIST if g["status"] == "accepted_risk"),
 "blocking": sum(1 for g in CHECKLIST if g["status"] in ("not_started", "in_progress")),
 },
 }

checklist = generate_checklist("My AI Product")
print(json.dumps(checklist, indent=2))

5. Cost Optimization Strategies

Once you have measured your baseline costs, several strategies can reduce them without sacrificing quality. These strategies are not mutually exclusive; the most cost-efficient products combine all of them.

1. Model routing. Use a lightweight classifier to determine whether a request needs a frontier model or can be handled by a cheaper one. Routine questions (FAQs, simple lookups) go to the small model; complex reasoning goes to the frontier. The strategy chapter (Chapter 33) covers routing architectures in detail.
2. Prompt caching. If your system prompt and common retrieval context are stable across requests, prompt caching can reduce input costs by 50% or more. Design your prompt architecture so the cacheable prefix is as large as possible.
3. Output length control. Use max_tokens limits and explicit instructions like "Answer in under 100 words" to constrain output length. Shorter outputs cost less and are often more useful to users.
4. Batch processing. For non-real-time workloads (nightly report generation, bulk classification), use batch APIs that offer 50% discounts. Structure your pipeline to accumulate requests and submit them in batches.
5. Context pruning. Not every retrieved passage is equally relevant. Rank and truncate your retrieval results aggressively. Sending four highly relevant chunks costs half as much as sending eight moderately relevant chunks, and often produces better answers.