Cost stored as cents (BIGINT), CO₂ stored as grams (DOUBLE PRECISION)

Costs and CO₂ are estimates, not billing-grade figures — pricing and CO₂ factors are themselves approximations (see decision 3), and the dashboard’s purpose is trend visibility, not exact accounting.

• Cost: stored as whole cents (BIGINT, banker’s rounding at ingest). Not scaled to sub-cent units; very cheap requests may round to 0 cents, which is accepted. Chosen over NUMERIC/DOUBLE PRECISION for human-readable values in the DB and exact, simple integer addition when aggregating.
• CO₂: stored in grams as DOUBLE PRECISION, since some records fall below 1 gram and an integer type is not viable. NUMERIC was considered but rejected: the main use case is aggregation, and exactness is explicitly not a goal here either — the underlying CO₂ factors are approximations, so NUMERIC’s exact-decimal guarantees would not reflect any real precision in the data.

If a future need for finer-grained cost tracking arises (e.g. per-token pricing well below a cent, or a business requirement for exact billing), revisit the cents/BIGINT choice rather than silently rounding harder.