Skip to main content
Introducing logcat.ai PlaygroundRead

Platform · Diagnose

LIVE

Diagnose: autonomous investigation across the device-software stack.

It runs on Delta, one investigation engine you point at a question, a single capture, or many at once. Quick returns a cited answer in seconds. Deep Research investigates one capture end to end. Delta correlates across many. Same parsers, same correlation, same citation discipline underneath.

The modes

One engine. Three scopes.

You don't switch tools between them. You widen the question: point Delta at a single thing, or at many.

Quick

A question

One question, one cited answer, in seconds. The fastest way in.

Deep Research

A capture

Point it at one artifact and it investigates end to end: multi-step reasoning, follow-ups, structured findings.

Delta

Many captures

Give it several artifacts and it correlates across them: isolates regressions and traces cross-layer chains across builds, devices, and time.

§ 01 — The engine

One engine. Four primitives.

Quick, Deep Research, and Delta aren't three products. They're the same engine at three scopes: point it at a question, a single capture, or many at once.

Parser layer

Every signal format in device software, natively understood. Bugreports, logcat, dmesg, journalctl, CAN traces, kernel oops, U-Boot output, modem signaling. Each parsed with format-aware structure, not treated as text.

Correlation engine

Cross-subsystem causal reasoning. Aligns timestamps across kernel, HAL, framework, modem, and bus layers so a single trace tells the whole story instead of fragments per buffer.

Investigation engine

Multi-step autonomous reasoning with self-correction. Forms hypotheses, gathers evidence, cross-checks against other artifacts, and revises when the evidence pushes back.

Citation discipline

Every claim grounded in source signals. Findings cite the exact lines, sessions, and artifacts they came from. Failed hypotheses surface as failed, not hidden.

§ 02 — Deep Research

Deep Research: depth on a single signal.

Ask a question about one artifact (a bugreport, a logcat session, a dmesg dump) and the engine investigates it end to end. Multi-step reasoning, follow-up questions, structured findings with line-level citations.

Multi-Step Investigation

Deep Research plans an investigation strategy, executes multiple searches, and refines its approach based on what it discovers. If the first hypothesis doesn't hold, it pivots.

Follow-Up Questions

Drill deeper into any finding. Deep Research retains full context from previous steps, so follow-ups build on what's already been discovered.

Cross-Layer Reasoning

Traces cause-and-effect chains across logcat, dmesg, bugreport sections, and telecom traces. Connects events that span system layers and time windows.

Shareable Reports

Every investigation produces an organized report: root cause, supporting evidence from log lines, causal chain, and actionable recommendations. Share via link, no account required.

Demo · Deep Research
Watch Deep Research investigate a high CPU usage issue and find the root cause

Most investigations widen as they go. A Quick answer raises a question, Deep Research runs it down on one capture, and Delta confirms whether it repeats across builds and devices.

§ 03 — Delta

Delta: breadth across many signals.

Drop in multiple artifacts (across builds, devices, time periods, or subsystems) and the engine aligns them, isolates regressions, and traces cross-layer causal chains. The capability horizontal AI tools structurally cannot replicate.

Cross-Layer Correlation

Modem
Logcat
Dmesg
Scanning timeline...

Upload multiple log files (logcat, dmesg, bugreport sections) and Delta finds related events across system layers. See how a low-level kernel event connects to a framework error and ultimately an app crash.

Regression Detection

v1.0 → v1.1
ActivityManager: START
WindowManager: focus
-GC: alloc 128MB
+GC: alloc 512MB
~OOM score: 250→900
+E/App: OutOfMemory

Compare logs from two software versions on the same device. Delta identifies what changed (new errors, timing shifts, missing events) so you know exactly what the update broke.

Device-to-Device

Device A
WiFi: connected
GPS: lock OK
BT: paired
Temp: 38C
Device B
WiFi: connected
GPS: no lock
BT: paired
Temp: 52C

Same software, different hardware. Upload logs from Device A and Device B to find device-specific behaviors, hardware quirks, or configuration differences.

Before/After Analysis

Before
Normal GC cycle
Alloc: 64MB
Stable heap
Δ
After
Frequent GC
Alloc: 512MB
OOM crash

Compare logs from before and after a system update, configuration change, or firmware update to isolate the exact impact of the change.

Multi-Source Investigation

logcat.log
dmesg.log
traces.txt
events.log
↓ ↓ ↓ ↓
Processing...

Combine bugreport + kernel dmesg + logcat to build a complete picture. The more context you provide, the better the AI can trace cause-effect chains.

Field Test Comparison

📍Site A
-85 dBm
4G LTE
📍Site B
-112 dBm
No Service

Compare field test logs from different locations, times, or conditions. Identify environment-specific issues, time-of-day patterns, or configuration-specific behaviors.

Timestamp
bugreport_pre_OTA.zip
Apr 22 14:32 · TQ3A.230805
bugreport_post_OTA.zip
Apr 28 09:14 · TQ3A.230901
Delta
10:15:01
kernel: usb 1-1: new device
kernel: usb 1-1: new device
10:15:02
systemd: Started app.service
systemd: Started app.service
10:15:03
GC: alloc 64MB
GC: alloc 512MB
changed
10:15:04
app: heap 128MB stable
OOM killer invoked: app pid 1842
regression
10:15:05
E/App: OutOfMemory in BitmapFactory
new
10:15:08
watchdog: ok
watchdog: timeout expired (8s)
regression
Delta finding
Lines changed
4
Regressions
2
Fixes
0

GC heap budget regression in build TQ3A.230901.

Cites: AOSP Issue #312445 · Affects 3 of 5 Pixel 8 sessions on this build

Pixel 8 OTA regression · 6 days apart, same device

Delta Correlation Engine

Multi-file cross-layer analysis

Uploading
Device Log (Firmware A)
10:15:01 kernel: usb 1-1: new device
10:15:02 systemd: Started app.service
10:15:03 kernel: BUG: sched while atomic
10:15:04 kernel: watchdog: timeout expired
Device Log (Firmware B)
10:15:01 kernel: usb 1-1: new device
10:15:02 systemd: Started app.service
10:15:03 app: request processed 42ms
10:15:04 kernel: all systems nominal
Kernel Log (OTA v3.2)
10:14:58 kernel: IRQ handler timeout
10:15:01 kernel: thermal zone0: 85°C
10:15:03 kernel: OOM killer invoked
10:15:04 kernel: process 1842 killed

Upload multiple log files for comparison

§ 04 — Visualize

The picture comes with the answer.

Every analysis returns a visual layer, not just prose, built automatically from your file, shaped to the artifact, and tied back to the exact lines behind every figure. No board to wire up, no queries to write.

Event timeline
Reliability
Crashes · ANRs · tombstones
12
Process churn
Process lifecycle
68
Foreground
Foreground / UI lifecycle
6
Security
SELinux denials
241
08-22 04:15:3708-22 20:25:4108-23 12:35:4508-24 04:45:4908-24 20:55:54

Quiet in this capture · Fatal exceptions · App freeze / unfreeze · Low-memory kills · Network up / down · switch · Weak signal (RSRP ≤ -110)

Bugreport · event timeline across reliability, process, security, and foreground lanes

Battery level (%) over time
peak 69min 66
Bugreport · battery level over time
CPU time share by process
system_server16%
surfaceflinger15%
com.Slack12%
com.google.androi…11%
kcompactd09%
others38%
Perfetto trace · CPU time by process
Errors & warnings / min
peak 1.2kmin 1
05:4921:03
Logcat · errors & warnings / min
Kernel errors by subsystem
cpu-boost
181
binder
6
ADSPRPC
2
logd
2
wcnss_wlan
2
q6asm_callback
1
Kernel log · errors by subsystem
Protocol distribution
802.11
261.8k
LLMNR
1.2k
MDNS
1.0k
NBNS
884
ARP
766
VRRP
682
UDP
420
Network capture · protocol mix
CAN frames by arbitration ID
[chg_protection_with_…
1.8k
type
758
cpu-boost
181
healthd
138
Total
123
iris_radio
106
Free
82
CAN bus · frames by arbitration ID

Real charts from actual analyses, spanning six different log types. Only unique identifiers like IPs and MACs are scrubbed. Every shape and number is untouched.

§ 05 — Coverage

Every signal format in device software.

Native parsers for structured binaries; format-agnostic profiling for text streams. Same engine across all of them.

Mobile

  • Bugreport (.zip · 30+ sections)
  • Logcat (threadtime / brief / time)
  • ANR traces & tombstones
  • Dumpsys (batterystats, meminfo, ...)
  • Event log binary stream

Modem & Connectivity

  • QXDM / QCAT trace logs
  • RIL & telephony framework logs
  • Modem signaling (3GPP)
  • Wi-Fi / Bluetooth HCI traces
  • Baseband crash artifacts

Automotive

  • CAN bus (.asc / .blf / .trc / .mf4)
  • VHAL property events
  • AAOS / Android Automotive logs
  • AGL (Automotive Grade Linux)
  • ECU diagnostic captures

Embedded Linux & Silicon

  • dmesg (ARM · x86 · MIPS · RISC-V)
  • journalctl (systemd journal)
  • U-Boot & bootloader logs
  • Yocto / OpenEmbedded build artifacts
  • Buildroot · OpenWrt firmware logs
  • Device tree compile artifacts
  • Kernel panics · driver traces
§ 06 — Proprietary codebases

Runtime-to-source attribution · how Diagnose understands your code.

When a log line comes from proprietary code, a general LLM can only guess what it means. The runtime-to-source attribution engine indexes your source tree so Diagnose reads what your code actually does, not what the public internet thinks code that looks like it does.

Multi-language

C/C++, Java/Kotlin, Go, Rust, kernel printk, and more

Cross-boundary

follows IPC and cross-repo references in complex codebases like AOSP

Proven at scale

hundreds of thousands of log sites across full AOSP and Linux

On-prem

source never leaves your environment

In research preview.

§ 07 — Scope

Forensic, not monitoring.

Diagnose investigates artifacts after the fact (bugreports, log captures, traces) rather than streaming live telemetry or paging on threshold breaches. Use it alongside an APM, not instead of one.

§ 08 — FAQ

Frequently asked.

Questions that come up most often in technical conversations about Diagnose.

Quick when you want a fast, cited answer to a single question. Deep Research when you have one capture and want it investigated end to end: why this device drained battery, what caused this ANR, what happened during this boot. Delta when you have several captures and want to know what changed: between two builds, across devices, before and after an OTA. Most real investigations move between all three.

Native parsers for structured binaries (Android bugreports, CAN bus traces, modem QXDM, journal binary streams). Format-agnostic profiling for any plain-text log (dmesg, journalctl, U-Boot output, syslog, custom application logs) where the system generates domain context dynamically rather than relying on a per-format parser.

Delta is built for multi-file comparison across builds, devices, time periods, and subsystems. Practical batches range from 2 (before/after) to dozens (regression hunts across many captures). Total payload size matters more than file count.

Diagnose covers everything from the kernel up, including the runtime signatures of build issues (boot failures on a built image, kernel oops from a misconfigured driver, dmesg from a broken device tree). It does not yet investigate the bitbake build process itself or do static recipe-level analysis. That capability lands with Remediate, now in research preview.

SaaS deployments hold uploads for the configured retention window (90 days by default) inside logcat.ai infrastructure. On-prem deployments keep all data inside the customer environment. See the security architecture page. Customer data is never used to train AI models.

Diagnose ships today. Enterprise pricing is scoped per deployment (seats, on-prem vs. SaaS, support level). Request a demo and we'll scope the right shape for your team.

Bring us a real log.

Upload a real bugreport, logcat, dmesg, or trace. We'll show you Deep Research or Delta on it. Your actual data, your actual stack. From there, we'll scope a pilot for your team.