Gemini 3.8 Flash + File Search: 7–8s TTFT with low thinking (timing breakdown)

Gemini API
1

Hi Google team,

I’m building a customer-support bot with Gemini 3.8 Flash and File Search, and typically see 7–8 seconds before the first answer text arrives—not time to complete the answer. Could someone from the File Search / Interactions API team help determine whether this is expected and whether there is a supported way to reduce it?

Setup

  • Gemini Developer API, paid project, standard service tier
  • Model: gemini-3.8-flash
  • JavaScript SDK: @google/genai 2.24.0
  • Interactions API with stream: true, store: true, thinking_level: "low"
  • File Search with one dedicated store and top_k: 5
  • Synthetic support documents; measurements collected September 27–28, 2026

Direct API measurements
A short-prompt test bypassing our application, database and UI produced the following median event timestamps across three File Search runs (relative to starting the request):

Event Elapsed time
Stream opened 637 ms
file_search_call started 4,478 ms
file_search_result started 6,497 ms
First text delta 7,231 ms
Stream finished 10,538 ms

Individual first-text times were 7,317, 7,078 and 7,231 ms. These are client-observed stream events, not an assertion about Google’s internal execution stages.

A separate five-run-per-variant comparison measured median TTFT of:

  • No tools: 2.195 s
  • File Search only: 6.874 s
  • File Search plus a function tool: 6.902 s
  • generateContent streaming with File Search: 6.717 s
  • File Search with priority tier: 6.358 s

These are small samples, but the difference with File Search is consistent. A separate application-orchestrator evaluation across 223 model turns measured 7.505 s median first-text latency.

Minimal timing example
This uses an existing, fully indexed File Search store containing a short synthetic returns-policy document. Run with GEMINI_API_KEY and FILE_SEARCH_STORE set; compare with the tools field omitted.

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });
const started = performance.now();
const seen = new Set();
function mark(label) {
  if (seen.has(label)) return;
  seen.add(label);
  console.log(label, Math.round(performance.now() - started), "ms");
}

const stream = await ai.interactions.create({
  model: "gemini-3.8-flash",
  input: "How long do I have to return something?",
  system_instruction: "Answer in one or two sentences from the retrieved documents.",
  tools: [{
    type: "file_search",
    file_search_store_names: [process.env.FILE_SEARCH_STORE],
    top_k: 5,
  }],
  store: true,
  stream: true,
  generation_config: {
    thinking_level: "low",
    max_output_tokens: 300,
  },
});
mark("stream open");
for await (const event of stream) {
  if (event.event_type === "step.start") mark(`start:${event.step.type}`);
  if (event.event_type === "step.delta" &&
      event.delta.type === "text" && event.delta.text) mark("first text");
}
mark("done");

Questions

  1. Is roughly 3.8 seconds between stream opening and the File Search call event expected, even with low thinking and a short prompt?
  2. Are there recommended settings or a supported retrieval path that materially reduces first-answer latency while retaining File Search grounding and citations?
  3. Can this be escalated to the File Search / Interactions team, and what additional diagnostic information would help?

Thanks for any guidance. The delay is significant for an interactive support experience.