Skip to main content
logcat.ai raises $2.55M to build the future of device systems engineeringRead
§ 00 — The bugreport

Real bugreport · Nokia 3.2 · 20 MB · 276,834 lines

LMK process death, investigated end-to-end.

A single query on a 20 MB Android bugreport. Below: the actual Deep Research investigation, end-to-end. Then how the same prompt fared on Claude Code, and why frontier LLMs alone don't close real log RCA.

Powered by Claude, Gemini, and other frontier models, routed per task. No lock-in to a single provider.

§ 01 — The investigation

Same bugreport. Same question. Different answers.

See it on a real bugreport

We ran the same prompt on the same Android bugreport through Claude Code and through logcat.ai Deep Research. Here's what each found.

Bugreport
bugreport-Deadpool_00WW-QKQ1.191008.001.txt
Nokia 3.2 (Deadpool) · Android 10 · 1.8 GB RAM · msm8937 · 20 MB · 276,834 lines
Prompt
“The user says the device 'feels broken': apps keep silently disappearing from Recents and the app they were just using is gone when they switch back. There are no visible crash dialogs. What's actually wrong with this device? Quantify the problem and cite specific evidence for every claim.”
Claude CodeOpus 4.7 (current frontier) · ~15 grep / awk passes · ~3 min
$ grep -nc "lowmemorykiller\|lmkd\|Killing" $F
52
$ grep -n "lowmemorykiller: Killing" $F | head -25
13633:<6>[ 2223.685257] lowmemorykiller: Killing 'callenhancement'
13815:<6>[ 2407.859159] lowmemorykiller: Killing 'os.face.service'
$ grep -n "MemTotal\|MemFree\|MemAvailable" $F | head
5640:MemTotal: 1891020 kB
5641:MemFree: 28440 kB
$ grep -n "am_kill\|am_proc_died" $F | head
(no output)
$ grep -nE "MEMINFO in pid|Total RAM:|Free RAM:" $F
57997:Total RAM: 1,891,020K (status critical)
$ grep -nE "lmkd|kswapd|allocstall|page allocation" $F
...
Diagnosis: Chronic low-memory pressure. ~50 LMK kill lines, MemFree 28 MB on a 1.8 GB device, ZRAM 57% consumed, 489 allocstall_normal events. Correct, as far as it goes.
What it didn't find
com.force.stop.app: a third-party task-killer using Accessibility Service automation to tap Force Stop on background apps across 5 timestamped sessions
A second booster app (com.euphmed.free.best.gamebooster.appbooster) running concurrently: two killers fighting each other and the OS at the same time
The LMK cascade escalating from cached apps all the way to android.process.acore (adj 999, contacts storage): a 9-process waterfall in 5 seconds at the peak
SELinux denying CAP_KILL to kswapd0 and swapper threads: the kernel's own memory-reclaim path was being blocked, lengthening every pressure spiral
The compounding feedback loop: every force-stop forces a cold-start re-allocation when the user reopens the app, accelerating the next LMK breach
Capable on a small bugreport with a skilled prompter. Got the contributing condition. Missed both actors and the feedback loop.
logcat.ai Deep ResearchRecommended
Model-agnostic routing · single query · ~16 min · shareable report
Diagnosis: Two simultaneous, independent kill mechanisms producing identical silent disappearance. Kernel LMK killed 25+ processes across a ~36-minute window, escalating from cached apps all the way to android.process.acore (adj 999, contacts storage). Meanwhile com.force.stop.app force-stopped apps via Accessibility Service automation across 5 sessions, with a second booster running concurrently. Neither produces a crash dialog.
What it found that Claude Code missed
com.force.stop.app: opens InstalledAppDetailsTop and uses Accessibility Service to tap Force Stop + OK across 5 documented sessions on 2021-04-04. Does NOT hold KILL_BACKGROUND_PROCESSES; it's pure UI automation
Second booster com.euphmed.free.best.gamebooster.appbooster active in the same window: two independent app-killers fighting each other and the OS
LMK cascade reconstructed across four phases (~2,176 seconds): adj 985 → 999 escalation, peaking with a 9-process waterfall in 5 seconds (985→975→965→955→945→935→925→915→905)
The compounding feedback loop diagnosed: each force-stop forces a cold-start re-allocation (zygote fork + heap init) when the user reopens the app, accelerating the next LMK breach
SELinux denying CAP_KILL to kswapd0 and swapper threads: the kernel's own memory-reclaim path is being blocked, worsening every pressure spiral
YouTube identified as the single largest consumer at 273 MB PSS / 96.6% native heap utilization: 15% of the device's 1.8 GB RAM in one app
Restart-kill loops on 5 processes (.apps.nbu.files killed 3×; calendar, turbo, latin:train each killed 2×) confirmed via PID progression
Open the actual investigation
One query. No prompting tricks. Found two competing app-killers, the LMK escalation up to system-adjacent processes, the SELinux denial blocking the kernel's own reclaim path, and the compounding feedback loop the user didn't ask about.

Claude Code is genuinely capable on a small bugreport with a skilled prompter. logcat.ai finds things a domain expert would find, without one, and produces a report your team can share, cite, and act on tomorrow.

20 MB is a small bugreport. Real ones are 100 MB to 500 MB, past Claude Code's file-read limit, where the comparison stops being a comparison.

§ 02 — Failure modes

What General AI Gets Wrong About Logs

These aren't edge cases — they're what happens the first time you paste a real bugreport.

01

Your bugreport doesn't fit in their context window

A real Android bugreport is 50–500 MB. ChatGPT silently truncates. Claude Code runs out of tokens by the first tombstone. logcat.ai parses, chunks, and indexes the entire file, and answers questions about parts the model has never seen.

02

They read text. Logs aren't text.

A bugreport contains 30+ structured sections: dumpsys, event_log, ANR traces, tombstones, battery_history, kernel buffers. A general LLM has no idea that event_log row 30041 is a process death, or how to align dmesg timestamps with logcat. logcat.ai has dedicated parsers for each.

03

They hallucinate timestamps and PIDs

Ask ChatGPT for the PID of the process that crashed and it will confidently invent one. logcat.ai grounds every claim in real log lines and rejects answers it can't cite.

04

There's no platform — just a chat window

No API to wire into your CI. No persistent storage of investigations. No team sharing, no usage controls, no role-based access. Once a conversation closes, the analysis is gone.

05

Customer device logs don't belong in a public chatbot

Most enterprise security policies prohibit pasting customer telemetry into ChatGPT. logcat.ai supports self-hosted and dedicated deployments so logs never leave your boundary.

06

Single-shot Q&A can't do real investigation

Hard bugs need multiple search steps, hypothesis testing, and pivots when a lead dies. ChatGPT answers once. logcat.ai's Deep Research engine plans, retrieves, judges, and self-corrects across many steps until the evidence holds up.

§ 03 — Independent research

The framework, not the model, is the bottleneck.

Above on this page, Claude Code on Opus 4.7, the current frontier model, missed two competing app-killers, an SELinux denial blocking the kernel's reclaim path, and the compounding feedback loop that logcat.ai's Deep Research surfaced on the same 20 MB bugreport with a single query. The same pattern shows up across the academic literature: the gap isn't model intelligence: it's the framework around the model.

  1. [01]
    Tested on Claude Sonnet 4 and GPT-5 mini · 2026

    Hallucination >66%, incomplete exploration >53%

    A 2026 study of frontier LLMs on cloud root-cause analysis found that even current-generation models hallucinate interpretations more than two-thirds of the time and abandon investigations before reaching ground truth more than half the time. The authors conclude the gap is structural: a framework problem, not a model-quality problem.

    Source: arxiv.org/abs/2602.09937
  2. [02]
    Hardware bug RCA on commercial-scale designs

    3× gap between specialized and generic agents

    On a benchmark of root-cause analysis across millions of lines of HDL and waveform data, a domain-specific RCA agent reached 56% top-1 accuracy versus ~19% for the most widely used state-of-the-art software programming agent, roughly 3× the gap on the same task, regardless of underlying model.

    Source: chipagents.ai/blogs/chipagents-rca
"These uniformly high failure rates point to the shared framework as the primary bottleneck rather than to any individual model's limitations."
— Authors et al., "Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis," arxiv:2602.09937

These findings are model-agnostic. Each new generation of frontier models has narrowed the gap in places, and exposed it in new ones. The framework around the model is the work.

§ 04 — Apparatus

Six Things Built Specifically for Logs

Each of these is a real subsystem inside logcat.ai — not a prompt trick.

01/06

Native parsers for every log format

Dedicated parsers for Android bugreports (30+ section types: dumpsys, event_log, ANR traces, tombstones, battery_history, kernel buffers), logcat in every common format with adaptive pattern detection for unknown ones, dmesg with kernel exception typing and subsystem attribution, modem traces, and automotive CAN bus data.

02/06

Built for 100MB+ files

The whole file is parsed and indexed up front, so you can ask questions about parts of it that would never fit in a model's context window. Stack traces stay intact, related events stay together, and search works across bugreport, logcat, and dmesg content.

03/06

Autonomous Deep Research, not single-shot answers

A dedicated investigation engine runs multi-step investigations: it plans, scouts in parallel, judges intermediate results, grounds every claim in real log lines, and self-corrects when a hypothesis fails. Every finding is citable.

04/06

Multiple domain-tuned analyzers in parallel

Specialized analyzers for application crashes and ANRs, system services, network, power, security, storage, memory, CPU, timeline, and overall system health. They run in parallel, each with its own severity scoring, and stream results to the UI as they finish.

05/06

Platform with API, CLI, and MCP server

A REST API with a published OpenAPI spec, API-key auth for machines, a CLI for pipelines, and an MCP server so Claude Code (or any agent) can call logcat.ai as a tool. Ready-to-use API request collections are provided for every endpoint.

06/06

Built for teams, not chats

Share investigations with a public link, export to PDF, collect team feedback, set per-team usage limits, see full audit logs of who ran what, and run the whole thing self-hosted if your logs can't leave your network.

§ 05 — Interfaces

It's infrastructure. That matters.

ChatGPT and Claude Code are tools you sit in front of. logcat.ai is infrastructure your team and your CI plug into.

REST API + OpenAPI spec

Every capability is exposed under a versioned REST API with a published OpenAPI spec, API-key authentication, and ready-to-use request collections. Wire log analysis into CI, internal dashboards, or your existing triage workflow.

MCP server — works with Claude Code

logcat.ai ships its own MCP server, so Claude Code (and any MCP-capable agent) can call it as a tool. Use Claude Code with logcat.ai instead of against it: your editor agent gets log analysis as a first-class capability.

CLI + real-time streams

A standalone CLI drops into pipelines for batch analysis, and streaming endpoints push Deep Research and Delta progress to dashboards and build systems in real time.

Source discovery across upstream trees

Built-in clients for Gerrit, GitHub, Gittiles, and CodeLinaro. Trace a kernel oops to the actual upstream patch that fixes it across AOSP, vendor, and distribution trees, something a general chatbot cannot do.

§ 06 — Capability ledger

Capability-by-Capability

What each tool can actually do for device log analysis today.

Capability
ChatGPT
Claude Code
logcat.ai
01Native parsers for bugreport / logcat / dmesg / modem / CAN
02Handles 100MB+ log files end-to-end
Limited
03Search past bugreports for the same crash, by keyword or similarity
04Multi-step autonomous investigation with self-correction
Limited
05Every claim links back to the exact log line
06Compare two bugreports and surface what changed
07Trace kernel oops to upstream Gerrit / Git patches
08REST API for programmatic log analysis
Limited
09MCP server callable from agents
Limited
10Investigations are saved and shareable across the team
11Org-level usage controls, billing, and access
12Self-hostable / dedicated deployment for sensitive logs
13Domain-specific analyzers for telecom, automotive, and CTS / VTS

Limited = possible with significant manual effort or only for very small files. Compared as of 2026.

§ 07 — Honest verdict

When to Use Which

Honest version: ChatGPT and Claude Code are excellent for some things. Device log analysis isn't one of them.

Use ChatGPT / Claude Code

Reach for ChatGPT or Claude Code when…

  • You're writing or refactoring source code in your editor
  • You need a generic explanation of a stack trace pattern in the abstract
  • You're exploring an idea, brainstorming, or drafting a doc
  • You're running ad-hoc shell commands in your dev environment
Use logcat.ai

Reach for logcat.ai when…

  • You have a real bugreport, dmesg, modem trace, or CAN log to analyze
  • You need cross-layer correlation across kernel, framework, and app
  • You need root cause for a regression across builds (Delta)
  • You need an API or MCP tool your agents and CI can call
  • Customer telemetry can't leave your security boundary
  • Your team needs shared, persistent, citable investigations

The best workflow we've seen: keep using Claude Code for your code, and call logcat.ai through its MCP server when your agent needs to actually read the logs.

Continue → Deep Research

See what real log investigation looks like

Deep Research is the autonomous, multi-step investigation engine that's hard to replicate in a chat window. It plans, scouts, validates citations, and produces a shareable root-cause report.

§ 08 — Index of questions

Frequently Asked Questions

Common questions from teams evaluating logcat.ai against general AI tools.

No, and we don't try to. ChatGPT and Claude Code are excellent for writing and reasoning about your own source code. logcat.ai is purpose-built for analyzing device telemetry (bugreports, logcat, dmesg, modem traces, CAN bus) and exposes itself as an API and MCP server so your existing tools can call it.

Two reasons. First, real bugreports are 50–500 MB, far past any model's context window, so the model only sees a fraction. Second, a bugreport isn't free text; it's 30+ structured sections (dumpsys, event_log, ANR traces, tombstones, battery_history, kernel buffers) that need real parsers to be useful. logcat.ai has those parsers, indexes the entire file, and lets you ask questions about parts the model has never read.

Most enterprise security policies prohibit pasting customer telemetry into a third-party chatbot. logcat.ai supports self-hosted and dedicated deployments, you choose where logs are stored and indexed, and ships with role-based access, API-key auth, and full audit logs.

Yes, logcat.ai ships an MCP server, so Claude Code (and any MCP-capable agent) can call logcat.ai as a tool. Your editor agent gets log analysis as a first-class capability without you copy-pasting log snippets back and forth.

Yes. logcat.ai exposes its full functionality through a versioned REST API with a published OpenAPI spec and API-key authentication, real-time streaming for long-running investigations, a standalone CLI, and example requests for every endpoint. Teams use it to gate releases, auto-triage CTS / VTS failures, and feed dashboards.

§ 09 — Close

Stop debugging in a chat window.

Talk to us about wiring logcat.ai into your CI, your agents, and your security boundary.