Skip to content

chore(weave): add gemini-3.1-flash-lite stable model costs - #6886

Closed
ro31337 wants to merge 1 commit into
masterfrom
roman/add-gemini-3-1-flash-lite-costs
Closed

chore(weave): add gemini-3.1-flash-lite stable model costs#6886
ro31337 wants to merge 1 commit into
masterfrom
roman/add-gemini-3-1-flash-lite-costs

Conversation

@ro31337

@ro31337 ro31337 commented May 19, 2026

Copy link
Copy Markdown
Contributor

JIRA Issue(s)

WB-34501

Description

Google graduated gemini-3.1-flash-lite from preview to general availability on 2026-05-07, with the stable model id gemini-3.1-flash-lite (no -preview suffix) now served from the same endpoints as before. Our cost_checkpoint.json and model_providers.json still only know about the -preview variants, so any customer or internal call that uses the stable model id today gets recorded with $0 cost in Weave's UI and Datadog cost panels.

This PR adds the stable-name rows alongside the existing preview rows so cost attribution catches up with the GA. All four name variants we keep for the preview model (bare gemini-3.1-flash-lite, plus the gemini/, vertex_ai/, and openrouter/google/ prefixed forms) get a corresponding stable-name entry in cost_checkpoint.json. The three prefixed variants that already exist in model_providers.json also get their stable-name siblings there. openrouter/google/gemini-3.1-flash-lite is intentionally added only to cost_checkpoint.json — that prefix is absent for every gemini model in model_providers.json today, so adding it would be a one-off departure from the file's existing shape.

The cost-loader in update_costs.py keeps these manual entries safe across future automated syncs from litellm. It compares the upstream row against the most recent stored row and only appends a new historical entry when costs differ, capped at three entries per model. If litellm later publishes the same numbers, nothing changes; if they diverge by some rounding, the sync appends a fresh row and the hand-added one stays as historical context.

The numeric values stored in cost_checkpoint.json are USD-per-token, so $0.25 per 1M input tokens becomes 0.25 / 1_000_000 = 2.5e-07. Every value can be cross-checked against the public sources linked in the table below — all four sources converge on the same numbers, and each table cell carries the link the reviewer should open to verify that exact value.

JSON field Public price Stored value Source
input $0.25 per 1M input tokens 2.5e-07 Google blog post (2026-03-03) — "Priced at $0.25/1M input tokens and $1.50/1M output tokens" · Google API pricing · OpenRouter listing — "Input Price. $0.25 per 1M"
output $1.50 per 1M output tokens 1.5e-06 Google blog post (2026-03-03) · Google API pricing — "Output price (including thinking tokens) ... $1.50" · OpenRouter listing — "Output Price. $1.50 per 1M"
cache_read_input $0.025 per 1M cached input tokens 2.5e-08 Google API pricing — "Context caching price ... $0.025 (text / image / video)"
cache_creation_input not billed 0.0 Google does not bill cache-creation on this model family; this also mirrors what the existing -preview rows already store in the same file
provider vertex_ai-language-models (bare and vertex_ai/ keys) · gemini (gemini/ key) · openrouter (openrouter/google/ key) each new row uses the same provider value as its -preview sibling already in cost_checkpoint.json
created_at 2026-05-19 10:13:20 the timestamp at which this row was added (matches the datetime.now() format the update_costs.py sync script writes)

Stable model-id GA confirmation: Firebase AI Logic models pagegemini-3.1-flash-lite: "Stable version of Gemini 3.1 Flash‑Lite, Stable, 2026-05-07"; OpenRouter listing — "Released May 7, 2026."

Why this approach

The team's existing pattern for adding new models is exactly this: a hand-edit of cost_checkpoint.json (appended at the end) plus a model_providers.json insertion next to the closest existing sibling, alphabetical-ish within each provider section. PR #6781 ("Add grok 4.3") is the most recent reference. Following that pattern keeps the diff identical in shape to the half-dozen recent merges and minimizes reviewer overhead. The change is strictly additive — no rows removed, no fields renamed.

Testing

Both JSON files re-parse cleanly via the real loader at weave.trace_server.costs.insert_costs.load_costs_from_json(). The loader returns 2,559 models (up from 2,555, +4 as expected) and the four new stable keys round-trip through the CostDetails typed-dict shape with the costs the file declares.

The full suite under tests/trace_server/costs/ passes locally (uv run --group test python -m pytest tests/trace_server/costs/ -v → 18 passed in 0.08s) and uvx ruff check on the touched directories passes too.

@wandbot-3000

wandbot-3000 Bot commented May 19, 2026

Copy link
Copy Markdown

@codecov

codecov Bot commented May 19, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@ro31337
ro31337 marked this pull request as ready for review May 19, 2026 17:49
@ro31337
ro31337 requested a review from a team as a code owner May 19, 2026 17:49
@gtarpenning
gtarpenning requested a review from jwlee64 May 19, 2026 17:52

@jwlee64 jwlee64 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently both of these files are auto generated.
I believe these changes will be overwritten by those scripts

see the make commands make update_costs and make update_model_providers

I think we need a mechanism to add custom costs to our db

@ro31337 ro31337 closed this May 19, 2026
@github-actions github-actions Bot locked and limited conversation to collaborators May 19, 2026
@ro31337

ro31337 commented May 19, 2026

Copy link
Copy Markdown
Contributor Author

Good call - closing this, will go through the script path instead.

Status upstream: litellm merged gemini-3.1-flash-lite stable pricing earlier today in BerriAI/litellm#27933, but to their shin_agent_oss_staging_05_19_2026 branch - their workflow promotes staging to main periodically, so it should land on main in the next 1–3 days.

Plan: I'll monitor litellm main and run make update_costs update_model_providers once the rows are there, unless someone else picks it up first

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants