Price estimate (PAngV compliance) #5099
Description
Summary
German price-display law requires traders to inform consumers of the full end price of goods or services before the transaction. For usage-based digital services (like token-metered API calls), if the exact total cannot be known in advance, the law still requires publishing the calculation method and showing pricing clearly and unambiguously before the service starts. Today, Codex CLI cannot display a concrete pre-execution price or a reliable estimate/cap (input tokens + output tokens + any add-ons). That’s a compliance problem for German users and, frankly, bad developer UX.
Ask: Add a --quote (dry-run) mode and --max-cost hard cap to show the expected cost (or worst-case) before executing—and require explicit user confirmation. This should cover input tokens, output tokens (bounded), and any other billable units.
Legal basis (short):
• PAngV § 3 obliges traders to state the total (gross) price including VAT and all components to consumers; the price must be clearly assigned to the specific service. 
• PAngV § 6 (distance/online sales): if prior indication of certain costs is not possible, the details of the calculation must be given before the transaction starts (e.g., online services). 
• German authorities emphasize “Preisklarheit & Preiswahrheit” (price clarity and truth). For services where the final price depends on usage (taxis, copy shops, EV charging), unit prices and calculation rules must be shown upfront; EV charging law even says price must be visible before the charge starts—a strong analogy for API calls. 
⸻
Current Behavior
• Codex CLI executes calls immediately. Users only learn the actual cost after the API returns (in logs/billing).
• There is no built-in quote/dry-run to tokenize inputs and predict/limit outputs.
• There is no --max-cost hard cap, so a long response or hidden overhead can exceed a user’s expectations.
Impact: German consumers (and anyone acting in a consumer-like context) cannot determine the price of the service before purchase, nor the calculation method in an actionable way at the moment of decision. That’s exactly what PAngV tries to prevent. 
⸻
Why this applies to Codex CLI / API (even if OpenAI is in the US)
1. Scope: PAngV applies to traders offering goods/services to consumers. It explicitly covers services and online/remote offers. 
2. Directed activity to the EU: Under CJEU Pammer/Alpenhof, EU consumer rules apply when a trader directs activities to a Member State (e.g., accessible site, EUR pricing, local documentation, acceptance of EU users). That’s enough to trigger EU consumer protections, regardless of where the company is incorporated. 
3. Choice of law doesn’t help: Rome I, Art. 6—a choice-of-law clause cannot deprive consumers of mandatory protections of their home state’s law. German consumer price transparency rules still bite. 
4. UWG enforcement: Lack of price clarity can be an unfair commercial practice under UWG, exposing traders to injunctions/cease-and-desist (Abmahnung) and damages (post-Omnibus). 
⸻
Legal Details (a bit deeper)
• PAngV § 3 (Total price): Price must include VAT and all components and be clearly assigned to the service—no scavenger hunts. 
• PAngV § 6 (Online/distance): Where you cannot state the exact price beforehand, you must provide the calculation method before ordering (e.g., “€X per 1k input tokens + €Y per 1k output tokens + Z per tool-call; output capped at N tokens”). 
• Analogy provisions: German guidance consistently treats metered services as needing unit prices and transparent rules visible before the service starts (e.g., EV charging price per kWh at the point of decision). By parity of reasoning, an API call should show per-unit token rates and a bounded total before execution. 
⸻
Rebuttals to predictable counter-arguments
• “OpenAI is in the USA.”
Doesn’t matter for EU consumer law. If you direct activities to EU consumers, EU consumer protections apply. Pammer/Alpenhof confirms targeting criteria; Rome I Art. 6 keeps consumer mandatory rules in play despite a foreign governing law clause. 
• “API is for professionals/B2B only.”
Then prove it with effective gating. German practice is clear: if an online offer is publicly accessible and consumers can sign up, PAngV duties are triggered. A mere “B2B only” note is insufficient; courts/authorities expect robust restrictions (e.g., verified VAT ID, business checks) or you must meet consumer rules. 
• “German law doesn’t apply to a website abroad.”
It applies when the offer is accessible and aimed at German consumers; and German UWG/PAngV can be enforced where market effects occur in Germany. Rome I and CJEU jurisprudence back this up. 
• “Output tokens can’t be estimated beforehand.”
Legally, if exact totals are unknowable, you must reveal the calculation method and bound the total before the consumer commits. Technically, CLI can:
• Tokenize input exactly (deterministic) → cost known upfront.
• Require or infer a max_output_tokens (or set a default) → show worst-case output cost and range (e.g., likely 120–300 tokens; capped at 400).
• Display unit prices and max payable for this call, then ask for confirmation. That satisfies PAngV § 6’s “details of calculation” requirement. 
• “Other billables (tools/images/etc.) can’t be pre-estimated.”
CLI already knows which features are enabled. It can:
• Show per-unit prices for each enabled feature.
• For uncertain downstream calls, present branch-specific caps (e.g., “max 1 image generation @ €M,” or “tool calls disabled in quote mode unless confirmed”).
• Or disable cost-volatile features unless the user opts in with a separate, explicit cap. This mirrors how metered services (taxis/EV charging) handle variable parts—unit price + cap visible before start. 
• “We publish a pricing page already.”
Helpful, but insufficient. PAngV requires price information at the moment of decision, unambiguously tied to the specific transaction (your prompt). Users shouldn’t have to manually multiply token tables in their head. 
⸻
What “compliant” looks like (UX/Dev requirements)
New CLI flags & behavior
1. codex --quote
• Tokenizes input and reports price before execution:
• Input tokens × input-rate
• Max output tokens (from --max-output-tokens or default) × output-rate
• Any enabled add-ons with per-unit rates (images, tool calls, file ops)
• Total worst-case price and a likely range (based on length heuristics).
• Shows VAT-inclusive prices for DE users (or clearly states VAT treatment).
2. codex --max-cost=<€> (hard cap)
• The call will not execute if the theoretical maximum exceeds the cap.
• The runtime enforces the cap by truncating output at the declared limit.
3. codex --confirm-price (or auto-prompt)
• After --quote, require a y/N confirmation before proceeding.
4. codex --no-tools / --tools=NAME1,NAME2
• Disable or whitelist cost-volatile features unless user opts in during the quote.
5. Per-call JSON receipt
• Emit a machine-readable receipt (tokens in/out, unit rates, VAT note, total) for audit and reimbursement.
Acceptance criteria
• For any call, the user can see the maximum payable amount and how it was calculated before execution.
• Default sane ceilings (e.g., max_output_tokens) to prevent accidental overruns.
• Clear per-unit rates shown inline (no off-site digging).
• If exact totals can’t be known, the calculation method is disclosed (PAngV § 6), and the hard cap guarantees the end price won’t exceed what the user just saw. 
⸻
Risks if ignored
• Regulatory/competition enforcement (UWG), cease-and-desist risks, negative PR, and churn due to “surprise bills.” The IHK guidance flags both administrative offences and Abmahnungen for price-display failures.