Cost tracking

How GoModel estimates request costs, where pricing comes from, how to override it, and how to recalculate stored costs.

GoModel estimates the cost of every tracked request from model pricing and shows the totals on the dashboard.

These costs are estimates, not a billing record. Unless a provider reports an exact cost, GoModel multiplies the tokens a provider reports by that model’s configured rates, so discounts, promotions, and provider-side rounding are not reflected. Treat the provider’s dashboard as the source of truth, and check GoModel figures against it before using them for invoicing or reconciliation.

How costs are estimated

For each request GoModel prices:

• Input and output tokens at the model’s per-million-token (MTok) rates.
• Cached input, reasoning, and audio tokens at their own rates when the provider reports them, so cache-heavy and reasoning-heavy traffic is priced correctly.

When a provider returns an exact cost (OpenRouter credits, xAI cost_in_usd_ticks), GoModel uses that value instead of catalog pricing. Each row records which method was used in its cost_source field: model_pricing, openrouter_credits, or xai_cost_in_usd_ticks.

Cached tokens are discounted only when the model’s pricing includes a cached_input_per_mtok rate. Without it, they are priced at the full input rate.

Time-of-day pricing

Some providers charge different rates depending on when a request runs. DeepSeek, for example, bills its off-peak hours at half the peak rates and treats weekends as off-peak. The catalog publishes the standard (peak) rates as a model’s base prices and lists the discounted periods under pricing.time_windows:

"pricing": {
  "input_per_mtok": 0.44,
  "output_per_mtok": 1.32,
  "cached_input_per_mtok": 0.014,
  "time_windows": [
    {
      "label": "off_peak",
      "utc_ranges": [
        { "days": ["mon", "tue", "wed", "thu", "fri"], "start": "00:00", "end": "01:00" },
        { "days": ["mon", "tue", "wed", "thu", "fri"], "start": "04:00", "end": "06:00" },
        { "days": ["mon", "tue", "wed", "thu", "fri"], "start": "10:00", "end": "24:00" },
        { "days": ["sat", "sun"], "start": "00:00", "end": "24:00" }
      ],
      "pricing": { "input_per_mtok": 0.22, "output_per_mtok": 0.66, "cached_input_per_mtok": 0.007 }
    }
  ]
}

GoModel prices each request with the rates in effect at the moment it completed, evaluated in UTC regardless of the server’s or the dashboard’s timezone. Ranges are half-open (start inclusive, end exclusive); an end at or before start wraps past midnight, and days limits a range to weekdays (all days when omitted). Rates absent from a window keep their base price, and outside every window the base prices apply. Recalculating stored costs uses each row’s stored timestamp, so historical rows are re-priced for the window they actually fell in. The dashboard’s cached-input cost estimate applies windows per minute of the week, matching the precision of the window bounds.

On the Models page, a * next to a price marks a model with time windows; hover it to see the schedule and rates. Overriding a base rate (input, output, cached input, or cache write) replaces the catalog’s discount for that rate as well: the override becomes the price at every hour. config.yaml model metadata may also declare its own time_windows, which replace the catalog’s.

Time windows are recurring UTC schedules only. Rules the catalog cannot express — a provider’s holidays, or promotions with a fixed end date — are not applied.

Where pricing comes from

Pricing for a model is resolved in priority order:

1. Operator overrides set in the dashboard.
2. config.yaml providers.<name>.models metadata.
3. The model catalog, sourced from the ai-model-list registry.

The catalog supplies the default pricing for most models. If a model’s price looks wrong or a rate is missing (for example, a cached-input rate), check it against ai-model-list and contribute a correction there, or set an override for an immediate fix.

Pricing is one part of a wider metadata pipeline that also resolves context windows, capabilities, and model categories — see Model metadata for the full source chain.

Override pricing

Override pricing when the catalog price is wrong, missing, or differs from your negotiated rate. Open the Models page, find the model, and open its Pricing override editor. Set one or more price types (input, output, cached input, and so on) in USD. Saved fields override catalog and config.yaml pricing for that selector; unset fields keep inheriting.

The Models page lists each model's prices; the $ action opens its pricing override

Set a price type and USD value; saved fields override catalog and config.yaml pricing for the selector

Overrides apply to new requests. To re-cost requests that already ran, recalculate them.

Dashboard totals

• Estimated Cost — spend on live provider requests; cache hits are excluded.
• Saved Cost — what requests served from the cache would otherwise have cost.

A --- value means the cost is unknown because no pricing was available, which is not the same as $0.

Recalculate stored costs

Recalculating recomputes the stored cost of matching usage rows from current pricing. Use it after changing an override, or when pricing was unavailable at the time a request ran. The action is enabled by default (USAGE_PRICING_RECALCULATION_ENABLED); on the usage view, choose Recalculate, then type recalculate to confirm. It is scoped to the selected date range, provider or model, and user path.

Recalculation overwrites the cost fields of every matching row, and clears the cost of any row whose model no longer resolves to pricing. The result reports how many rows still lack pricing. Token counts are never modified.