# Gemini 3.8 Flash API Pricing and Agent Cost

> Compare Gemini 3.8 Flash API pricing from Google and OmniaKey, then calculate retry-aware cost per accepted agent task with current and 2027 rates.

- Canonical HTML: https://omniakey.com/blog/gemini-3-8-flash-api-pricing
- Markdown: https://omniakey.com/blog/gemini-3-8-flash-api-pricing.md
- Published: 2026-09-20 (updated 2026-10-30)
- Author: Kiki, COO at OmniaKey
- Language: en
- Category: Cost control
- Reading time: 11 min
- All posts: https://omniakey.com/blog/llms.txt

---

Updated October 30, 2026: OmniaKey's price now sits on the [Gemini 3.8 Flash model page](https://omniakey.com/gemini-3-8-flash), so the tables and worked example below show only Google's official rates.

**Gemini 3.8 Flash API pricing** is $0.75 per million input tokens and $3.75 per million output tokens on Google's paid Standard API through December 31, 2026. Google lists $1.50 input and $7.50 output from January 1, 2027. The [Gemini 3.8 Flash model page](https://omniakey.com/gemini-3-8-flash) shows the current price.

The direct figures and dates above come from [Google's live Gemini API pricing table](https://ai.google.dev/gemini-api/docs/pricing).

The same 3.8 Flash rate card applies to `gemini-2.5-pro` traffic from December 1, 2026, when Google sends those requests to `gemini-3.8-flash`, and the [2.5 Pro deprecation and migration guide](https://omniakey.com/blog/gemini-2-5-pro-deprecated-migration-guide) lists the request changes that come with the reroute.

Those rates answer what one token bucket costs. An agent budget needs a different number: **total spend divided by the tasks that pass your test**. A cheap request that fails twice can cost more than a dearer request that passes once.

> **Fact-checked September 20, 2026.** Google prices, dates, token limits, thinking levels, caching, and Batch behavior were checked against current Google documentation.

## Gemini 3.8 Flash API prices at a glance

All figures below are USD per one million tokens. "Cached input" is the lower read rate, not Google's separate cache-storage charge.

|Billing path|Input|Cached input|Output, including thinking|Scope|
|-|-:|-:|-:|-|
|Google Standard through Dec. 31, 2026|$0.75|$0.075|$3.75|Direct paid Gemini API|
|Google Batch or Flex through Dec. 31, 2026|$0.375|$0.0375|$1.875|Direct, eligible delayed or flexible work|
|Google Priority through Dec. 31, 2026|$1.35|$0.135|$6.75|Direct priority processing|
|Google Standard from Jan. 1, 2027|$1.50|$0.15|$7.50|Scheduled direct Standard rate|

The [Gemini 3.8 Flash model page](https://omniakey.com/gemini-3-8-flash) shows the current price. OmniaKey sets its own catalog rates, while Google sets the direct rate card. Recheck the [live pricing table](https://omniakey.com/pricing) before approving a production budget.

Google's Batch and Flex modes cost less than Standard, but they work differently. Batch is asynchronous, has a target turnaround of 24 hours, and Google documents it for `generateContent`. Do not assume that Google's Batch, Flex, or Priority modes work through OmniaKey.

Google also lists cache storage and grounding as separate charges. Tool providers, browsers, databases, hosting, taxes, and human review may add costs that are absent from a token table.

## Calculate cost per accepted agent task

Start with how you call the model, not the model name:

```text
model cost per attempt
  = input millions x input rate
  + cached-input millions x cached-input rate
  + output millions x output rate

all-in attempt cost
  = model cost + tools + grounding + infrastructure + review

observed cost per accepted task
  = total spend across successful and failed attempts
  / number of tasks that passed the acceptance check
```

For a forecast where every attempt has roughly the same cost and an independent probability of passing:

```text
expected cost per accepted task = cost per attempt / pass rate
```

That last shortcut is an estimate. Failed runs can stop early, loop longer, call different tools, or trigger human repair. Production reporting should use total observed spend in the numerator.

Define "accepted" before the test. It might mean a patch passes unit tests, a JSON object validates against its schema, an extraction matches reviewed labels, or a support answer passes a human rubric. HTTP 200 is not a quality check.

## Worked example: 20K input, 5K output, 70% pass rate

Assume each full attempt consumes 20,000 uncached input tokens and 5,000 output tokens. The output bucket includes provider-billed thinking tokens. Exclude tools, cache storage, taxes, and human review so the token math stays reproducible.

|Billing path|Cost per attempt|Expected cost per accepted task at 70%|
|-|-:|-:|
|Google Standard through 2026|`0.02 x $0.75 + 0.005 x $3.75` = **$0.03375**|**$0.0482**|
|Google Standard from 2027|`0.02 x $1.50 + 0.005 x $7.50` = **$0.06750**|**$0.0964**|
|Google Batch/Flex through 2026|`0.02 x $0.375 + 0.005 x $1.875` = **$0.016875**|**$0.0241**|

The direct Standard price doubles in this fixed-token example on January 1, 2027. The Batch/Flex row shows why the consumption mode must be part of a comparison: a delayed direct job can have a lower token bill than an interactive Standard request.

At the current Google Standard rate, the same $0.03375 attempt costs $0.0375 per accepted task at a 90% pass rate, $0.0482 at 70%, and $0.0675 at 50%. Improving the pass rate can matter more than trimming a small prompt.

## Thinking tokens can dominate the output bill

Google documents `low`, `medium`, and `high` thinking levels for `gemini-3.8-flash`; the default is `medium`. The `minimal` level is not supported and returns an error. Output pricing covers both visible response tokens and thinking tokens.

The current model page lists a 1,048,576-token input limit and a 65,536-token output limit. Those are capacity ceilings, not free allowances; every billed token still belongs in the task numerator.

This changes cost control in three ways:

1. A short visible answer can still have a large output bill if the model reasons for many tokens.
2. A small `max_output_tokens` value can stop the response while it is still reasoning, return an incomplete or empty result, and still bill generated thinking tokens.
3. `high` is economical only when its additional reasoning raises the accepted-task rate enough to offset extra output and latency.

Test `low`, `medium`, and `high` on the same task set. Keep the prompt, tools, permissions, retry policy, and test commands fixed. Choose the lowest level that meets the required pass rate, not the lowest level that merely returns text.

## Caching, retries, and tools belong in the same budget

Google documents implicit caching for Gemini 3.8 Flash with a 4,096-token minimum eligible prefix. Put stable instructions and tool schemas before changing task data when your client preserves that prefix, then verify the provider-reported cache usage. Similar text is not proof of a cache hit.

Retries deserve their own reason code. Separate transient transport errors, invalid tool arguments, failed quality checks, and human-requested revisions. An unbounded retry loop makes the denominator look better while silently expanding the numerator.

For tool-using agents, record at least:

- requested and returned model ID;
- input, cached input, thinking, and visible output usage when the active protocol exposes them;
- tool names, tool charges, and number of turns;
- latency, error category, and retry count;
- the test result and the exact check that produced it;
- final billed amount for that endpoint.

The Gemini native and OpenAI-compatible protocols may expose different usage field names. Reconcile the fields returned by the endpoint you call with the [OmniaKey usage dashboard](https://omniakey.com/dashboard/usage) instead of assuming one provider schema.

## When to use Google direct or OmniaKey

|Requirement|Start with|Why|
|-|-|-|
|Lowest listed rate for delay-tolerant bulk work|Google Batch|Current direct Batch rates are 50% of Standard; jobs are asynchronous|
|Google-specific grounding or consumption controls|Google direct|The direct contract documents those Google surfaces|
|One key and an OpenAI-compatible route|OmniaKey|The catalog lists `gemini-3.8-flash`; the model page shows the current price|
|Interactive agent with strict latency needs|Measure both|Token rate alone does not establish queue time, reliability, or pass rate|
|Production route after Jan. 1, 2027|Recheck both|Google's Standard change is scheduled; the future gateway quote is unknown|

This is not a universal winner table. Data policy, regional availability, rate limits, support, transparency about providers, and the client protocol can change the decision even when the arithmetic favors one line.

## Call Gemini 3.8 Flash through OmniaKey

Confirm that `gemini-3.8-flash` is present in the [live model catalog](https://omniakey.com/models), create a scoped credential in [API keys](https://omniakey.com/dashboard/tokens), and use the OpenAI-compatible endpoint:

```bash
curl https://api.omniakey.com/v1/chat/completions \
  -H "Authorization: Bearer $OMNIAKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "messages": [
      {"role": "user", "content": "Return the riskiest assumption in this rollout plan."}
    ],
    "stream": true
  }'
```

The [API quick start](https://docs.omniakey.com/en/quick-start) covers authentication and base URLs. Use an environment variable, never a real key in source, prompts, benchmark logs, or screenshots.

## Frequently asked questions

### How much does the Gemini 3.8 Flash API cost?

Google's paid Standard rate is $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026. It lists $1.50 and $7.50 from January 1, 2027. The [Gemini 3.8 Flash model page](https://omniakey.com/gemini-3-8-flash) shows the current OmniaKey price.

### Are thinking tokens included in the output price?

Yes. Google states that output pricing includes thinking tokens. Budget from provider usage, not visible answer length.

### Why divide cost by the pass rate?

Failed attempts consume money without adding an accepted result. Dividing a stable per-attempt forecast by pass probability estimates the spend behind one accepted task. Use total observed spend divided by accepted tasks once production data exists.

### Which thinking level should an agent use?

Start with `low` for bounded, checkable work, then test `medium` and `high` where failures are costly. Gemini 3.8 Flash does not support `minimal`. The right level is the least expensive one that passes the same test reliably.

## Primary sources

- [Google Gemini API pricing](https://ai.google.dev/gemini-api/docs/pricing)
- [Google Gemini 3.8 Flash model documentation](https://ai.google.dev/gemini-api/docs/models/gemini-3.8-flash)
- [Google thinking documentation](https://ai.google.dev/gemini-api/docs/thinking)
- [Google context caching documentation](https://ai.google.dev/gemini-api/docs/caching)
- [Google Batch API documentation](https://ai.google.dev/gemini-api/docs/batch-api)

_Sources and calculations were checked on September 20, 2026. Prices, model limits, endpoint availability, and provider behavior can change. Recheck the primary rate card and the live OmniaKey catalog before committing production spend._