Technology May 01, 2026 · 2 min read

How Many Log Lines Should You Send to Gemini? The Context Window Problem.

All tests run on an 8-year-old MacBook Air. When you send logcat lines to Gemini for diagnosis, how many lines should you include? Too few: the model lacks context, gives a generic answer. Too many: you hit token limits, slow down the response, and bury the relevant signal in noise. Here's what I...

DE
DEV Community
by hiyoyo
How Many Log Lines Should You Send to Gemini? The Context Window Problem.

All tests run on an 8-year-old MacBook Air.

When you send logcat lines to Gemini for diagnosis, how many lines should you include?

Too few: the model lacks context, gives a generic answer.
Too many: you hit token limits, slow down the response, and bury the relevant signal in noise.

Here's what I found after testing different window sizes in HiyokoLogcat.

The naive approach: send everything

First attempt: grab the last 500 lines and send them all.

Problems:

  • Gemini 1.5 Flash has a large context window, but 500 verbose logcat lines is a lot of tokens
  • Response latency increases noticeably
  • The model sometimes focuses on unrelated noise rather than the actual error

What actually works: 50 lines before, 50 after

After testing, ±50 lines around the target error hits the sweet spot:

pub fn get_diagnosis_context(
    buffer: &LogRingBuffer,
    error_idx: usize,
) -> String {
    let window = 50;
    let lines = buffer.context_around(error_idx, window);

    lines
        .iter()
        .map(|l| format!("[{}] {}/{}: {}",
            l.timestamp, l.level, l.tag, l.message))
        .collect::>()
        .join("\n")
}

50 lines before captures the sequence of events leading to the crash.
50 lines after captures any follow-on errors and recovery attempts.

100 lines total. Typically 3,000–6,000 tokens. Fast response, relevant diagnosis.

When to go wider

Some crashes only make sense with more context — memory leaks that build up over minutes, threading issues with long setup chains.

For these, I added a "deep diagnosis" mode that sends ±200 lines:

pub enum DiagnosisMode {
    Quick,  // ±50 lines
    Deep,   // ±200 lines
}

Quick is the default. Deep is one extra click. Most users never need it.

The format matters too

Raw logcat output has a lot of repetitive structure. Reformatting before sending reduces token count without losing information:

// Raw (verbose)
04-20 10:23:45.123  1234  5678 E AndroidRuntime: FATAL EXCEPTION: main

// Reformatted (compact)
[10:23:45] E/AndroidRuntime: FATAL EXCEPTION: main

Same information, fewer tokens. Over 100 lines this adds up.

The result

±50 lines, reformatted, PII-masked → Gemini gives a specific, actionable diagnosis in 2–3 seconds on the free tier.

That's the configuration I shipped with.

HiyokoLogcat is free and open source → github.com/hiyoyok/HiyokoLogcat
X → @hiyoyok

DE
Source

This article was originally published by DEV Community and written by hiyoyo.

Read original article on DEV Community
Back to Discover

Reading List