Gemini 3.8 Flash: A Practical Guide to Our New Default

A default model handles the tasks people send before they start comparing models. It needs to follow a policy, preserve a missing field, and repair a small bug without requiring an elaborate setup.

AI Crucible's configured default is now Google's Gemini 3.8 Flash, replacing Gemini 3.5 Flash. That is a product configuration change. Whether it improves everyday work is a question for measured comparisons.

Its predecessor, OpenAI's GPT-5.6 Terra, and xAI's Grok 4.6 provide useful comparison points. Token prices explain part of the choice; three small tasks with explicit acceptance criteria help you check the rest.

This is a practical guide to the default change, supported by configured prices and worked examples. The exercises are reproducible checks, not reported benchmark victories for the new model.

Time to read: 8–10 minutes.

What does the default change mean?

Gemini 3.8 Flash is the shared default API model in AI Crucible's model configuration. The default is a starting point for paths that use that setting. An explicitly selected model remains a separate choice; this change is not evidence that every existing chat now uses Gemini 3.8 Flash.

Google describes the new model as an improvement for coding, reasoning, and agent workflows. Its documentation also notes that complex work can consume more tokens as the model verifies its answers. Those claims motivate testing actual cost alongside latency. Google's Gemini 3.8 Flash documentation

This guide focuses on short everyday tasks. It does not attempt to reproduce a long-running coding-agent benchmark or establish a general model ranking.

Which models and prices are we comparing?

The previous default provides a regression baseline. Terra and Grok provide alternatives from other providers. Keeping those roles explicit makes the comparison useful even if no model wins every task.

These are configured standard uncached rates as of September 5, 2026, including AI Crucible's 20% margin. They are not observed costs per answer. Keep the fixtures below long-context thresholds and record any provider cache effects.

Gemini 3.8 Flash has introductory provider pricing of $0.75 input and $3.75 output per million tokens through December 31, 2026. Google's announced January 1, 2027 rates are $1.50 and $7.50. Google pricing

With the same 20% margin, those future rates would correspond to $1.80 and $9.00 in AI Crucible. That is a projection, not a claim that the application automatically schedules the change.

How can you compare the defaults fairly?

Create one four-model comparison for each fixture, using one round of Competitive Refinement. Score the individual round-one responses, which answer the same task without seeing peer answers. Choose GLM-5.3 as arbiter and account for its synthesis separately.

Repeat each fixture five times, producing 15 scored responses per model. Disable external tools, web search, and semantic response caching. Preserve the exact prompts, effective token allowances, reasoning settings, and actual resolved model IDs.

Use the same requested output allowance for each model and record provider-specific differences. A shared "medium" reasoning label is not proof of equal compute. Do not force temperature settings onto models that do not accept them.

For generation cost, use each model's round-one usage. For elapsed response time, use that model's recorded duration. The complete session also includes orchestration and synthesis, which should have their own cost and latency figures.

Can the model apply a support policy without inventing one?

The first task tests a policy with a precedence rule and an exception. A correct response distinguishes urgency from the customer's preferred resolution. It must also avoid promising a refund the policy does not authorize.

Copy the complete fixture into a fresh comparison:

Apply only this fictional support policy. Return a JSON array, no prose.
Each item must have ticketId, priority, action, and reason.
Policy:
1. Suspected account compromise is P1. Escalate to security; promise no refunds.
2. A duplicate charge is P2. Verify both transaction IDs before promising a refund.
3. A verified paid subscription that cannot export is P2; escalate to engineering.
4. All remaining requests are P3 and receive standard support.
5. A pending card authorization is not a duplicate settled charge.
6. If multiple rules apply, the account-compromise rule takes precedence.
Tickets:
A: "Two settled charges, txn-17 and txn-18. I also see a login I don't recognize."
B: "One settled charge and one pending authorization. Please refund the duplicate."
C: "Verified paid account. Export returns an error; no security issue reported."
Do not assert that an investigation or refund has already happened.

The expected priorities are A: P1, B: P3, C: P2. A requires a security escalation; B needs standard support about the pending authorization; C requires engineering escalation.

Score JSON validity, all three priorities, the requested actions, and the absence of unsupported promises. A polished explanation cannot compensate for applying the wrong policy.

Can the model extract data while preserving ambiguity?

The second task tests whether a model keeps uncertainty intact. The source gives an unambiguous ISO due date and an ambiguous slash-form invoice date. The required output should preserve the raw date and leave its normalized value empty.

Extract this fictional invoice into one JSON object, with no prose or code fence.
Keys: invoiceId, currency, netAmount, taxRate, taxAmount, grossAmount,
invoiceDateRaw, invoiceDateISO, dueDateISO, purchaseOrder, warnings.
Amounts and taxRate must be numbers; taxRate is a fraction, not a percentage.
Missing or ambiguous normalized fields must be null. warnings is an array of strings.
Do not infer a locale. Do not round amounts to whole currency units.
Source:
Invoice ID: INV-204
Invoice date: 03/04/2026; no locale stated.
Due date: 2026-04-30.
Currency: EUR. Net amount: 1,200.00. Tax: 20%. Gross amount: 1,440.00.
Purchase order: not provided.

The expected amounts are 1200 net, 240 tax, and 1440 gross, with a tax rate of 0.2. The invoice's normalized date and purchase order must be null. The due date is 2026-04-30.

Parse the returned JSON with a standard parser. Check types as well as values, and require a warning about the ambiguous invoice date. Do not use an LLM judge to decide whether malformed JSON is valid.

Can the model fix a boundary error without changing the contract?

The third task is a deterministic debugging exercise. Zero is a valid setting, and the allowed upper bound is inclusive. The current implementation mishandles both conditions, so a correct repair must address each without changing valid-input behavior.

Paste the instructions and code together:

Repair this JavaScript function. Return only the corrected function, no Markdown.
Input limit is either undefined or an integer from 0 through 100 inclusive.
undefined means 20. Zero means zero. Values outside that integer domain must throw.
Do not coerce strings, booleans, or null into numbers.
Keep the function name and parameter unchanged. No imports or external dependencies.

function normalizeLimit(limit) {
  const value = limit || 20;
  if (!Number.isInteger(value) || value < 0 || value >= 100) {
    throw new Error('Invalid limit');
  }
  return value;
}

Run candidate functions in an isolated local JavaScript environment. Preserve formatting failures separately from semantic failures. If a response includes prose despite the contract, record that instead of silently repairing its format.

What does the new pricing mean for an ordinary request?

For equal uncached token counts, Gemini 3.8 Flash's introductory rates produce a lower bill than the other configurations in this comparison. Actual savings depend on the number of tokens each model uses. A model that reasons longer can spend more despite a lower unit price.

Assume 10,000 input tokens and 2,000 billed output tokens, with no tools, retries, or cache effects:

This is a token-cost calculation, not a measured response comparison. The future Gemini row holds usage and margin constant; it does not predict future application pricing or model behavior.

The introductory price provides a clear cost reason to try the new default. It cannot establish that the model applies your policy correctly or preserves an ambiguous field. Those questions require the acceptance checks above.

What should a corrected boundary function look like?

Use an explicit check for undefined, then validate the inclusive integer range. A truthiness fallback changes valid zero input into the default and also lets some invalid values through. The upper-bound check should reject values above 100, not 100 itself.

function normalizeLimit(limit) {
  const value = limit === undefined ? 20 : limit;
  if (!Number.isInteger(value) || value < 0 || value > 100) {
    throw new Error('Invalid limit');
  }
  return value;
}

This is our reference solution, not output attributed to a model. We checked it locally against the 12 acceptance cases listed above. It illustrates how a small test can distinguish correct code from a fluent explanation.

Apply similarly concrete checks to the other tasks. Parse the invoice JSON and check field types. For support triage, verify priorities and actions independently of writing style.

Should a default also be the arbiter for every task?

An everyday default and an arbiter perform different jobs. The fixtures above test direct answers. They do not establish whether Gemini 3.8 Flash is best at reconciling contradictory responses from other models.

For an arbiter comparison, freeze the same candidate answers and send them to several synthesis models. Score which facts and errors survive. Changing both the candidates and the arbiter would make the source of any improvement unclear.

That follow-up can use the outputs from this experiment. It should have a separate result table and include the arbiter's actual cost.

When should you keep or change the default?

Keep Gemini 3.8 Flash when it meets your acceptance criteria at the latency and cost your workflow needs. Compare alternatives when it repeatedly violates a policy, invents a missing value, or fails a required test. A provider's broad capability claim does not replace those checks.

The configured default change gives users access to a newer model at lower introductory token rates than the previous default. The strongest way to assess that choice is to preserve a small set of tasks that matter to you and rerun them when the model changes.

Use the fixtures above as a starting point. Add your own policies and edge cases, retain failed responses, and count total spending per accepted answer. That makes a default an evidence-based operational choice rather than a permanent endorsement of one model.

What should you read next?

These articles provide background on model selection and the earlier Gemini comparison.

• Getting started with model selection in AI Crucible
• The earlier Gemini 3 Flash comparison
• Fast models: speed and cost considerations