Gemini 3.8 Flash API Pricing and Agent Cost

Updated October 30, 2026: OmniaKey's price now sits on the Gemini 3.8 Flash model page, 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 shows the current price.

The direct figures and dates above come from Google's live Gemini API pricing table.

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 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.

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.

The Gemini 3.8 Flash model page shows the current price. OmniaKey sets its own catalog rates, while Google sets the direct rate card. Recheck the live pricing table 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:

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:

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.

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 instead of assuming one provider schema.

When to use Google direct or OmniaKey

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, create a scoped credential in API keys, and use the OpenAI-compatible endpoint:

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 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 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
• Google Gemini 3.8 Flash model documentation
• Google thinking documentation
• Google context caching documentation
• Google Batch API documentation

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.