SmartPerfetto 1.19.0 is out. Since the previous update, which covered 1.15.1, the largest change has been consolidating the analysis engine around Pi Agent Core. We also upgraded Perfetto, added analysis capabilities, and fixed problems uncovered by several rounds of TraceDemo testing.
Here is what matters in this update:
- One default analysis engine: Pi Agent Core replaces the multiple-runtime default path. Web, CLI, and API share evidence acquisition and delivery. The old model declaration and claim-verification flow has been removed.
- A more usable investigation process: add context while an analysis runs, keep source selections per conversation, and recover more reliably from long sessions, budget limits, interrupted connections, and unclear tool errors.
- More evidence to work with: Perfetto v59.1, process lifecycle and JobScheduler observations, plus improvements to Bitmap, Doze, CPU PMU, camera, and rendering analysis.
- Concrete results from multiple test rounds: synthetic cases, real traces, targeted reruns, and final release artifacts were checked separately. The details below preserve what each result can establish.
- An independent option for your existing agent: install Perfetto-Skills in Codex, Claude Code, or OpenCode if you prefer working there rather than running the full SmartPerfetto product.
Download 1.19.0 · SmartPerfetto · Perfetto-Skills
This is a standalone article following the previous update log. It covers 1.16.0 through 1.19.0. Pi became the default in 1.18.0; 1.19.0 continues the capability work and fixes that followed that migration.
The version timeline
| Version | Changes covered here |
|---|---|
| 1.16.0–1.16.2 | Stronger units, evidence, and answer delivery; fixes to complete HTML reports, offline controls, and identity recovery. The declaration and semantic-review flow was still being maintained, before its removal in 1.18.0 |
| 1.16.3–1.16.4 | History rendering, idle trace-processor cleanup, CPU/FPS target identity, and AI Assistant docking, resizing, narrow panels, and themes |
| 1.17.0 | Perfetto UI, Wasm, trace processor, and SQL knowledge upgraded to v59.1; process start/exit and JobScheduler evidence |
| 1.18.0 | Pi Agent Core becomes the default; in-run supplements; removal of embedded OpenCode/Qoder engines and the model declaration-verification flow |
| 1.18.1 | Per-conversation source selection, user-initiated import of local Claude Code/Codex gateway configuration, and bundled Node 24 SQLite bindings in npm |
| 1.19.0 | Bitmap, Doze, and PMU capabilities; camera/rendering evidence; Pi budgets, tool results, SQL guidance, identity diagnostics, and CLI report delivery |
The full list is in the 1.19.0 Changelog. Below, I want to explain the changes users will notice and the reasoning behind them.
The architecture: one model loop, product-owned analysis
A trace investigation combines several different jobs. The model interprets the question and chooses what to inspect next. Skills and SQL retrieve data. Process identity, time windows, and provenance must stay consistent. Conclusions, HTML reports, and session results then need to reach the user.
Previously, those responsibilities had to connect across multiple model SDKs and runtimes. Pi Agent Core now owns the default model request and tool loop. SmartPerfetto continues to own strategies, tools, Skills, SQL, identity and authorization, reports, and sessions. Web, CLI, and API use the same backend analysis capabilities.
The diagram shows the default execution path. Version 1.19.0 retains a hidden fallback for the old Claude/OpenAI engines; they are no longer selectable in normal provider settings.
A Provider still determines the API, endpoint, model, and credentials. Migration must preserve the request destination. Restoring a session must not silently send it to another service just because the active provider changed later. Old configurations that cannot be migrated fail explicitly. Source authorization, process identity, and trace ownership remain product-controlled.
Pi does not automatically gain arbitrary file or shell access here. SmartPerfetto supplies its own analysis tools, and source access still requires authorization. The current runtime architecture describes these boundaries.
A workflow we invested in was also removed
Readers of the previous article may remember the emphasis on answer declarations and verification. Models had to declare relationships between conclusions and evidence in a particular format; the product parsed, repaired, and verified those declarations.
We were still fixing that process in 1.16.x, including formatting, recovery after exhausted budgets, and incomplete references. Real-model runs continued to expose friction between declarations, repair, and final answers. The 1.17.0 release notes explicitly retained the limitation that exploratory startup and scrolling runs had not delivered final reports. In 1.18.0, the runtime model-declaration and claim-verification flow was removed.
The current approach puts deterministic work into acquisition: Skills and SQL provide data, and producers describe units, scope, and semantics wherever possible. The model uses that material to investigate and explain. The backend still enforces identity, authorization, budgets, and delivery contracts. Producing a report does not establish causal proof for every sentence in it.
I think this decision belongs in the update. Listing additions alone would suggest that everything described in older posts simply accumulated into today’s product. This was an explicit architectural change.
Add context during a run, and keep evidence available
Sometimes the useful detail occurs to you after analysis has started: “focus on the second launch,” or “this process just restarted.” You can now supplement an active run, with the UI showing whether the information was queued, delivered, or could not be applied. It does not promise to retroactively redo completed steps, but you can see whether the new context entered the run.
Source selection is now stored per conversation, and new conversations start with the most recent selection. Users can also explicitly import third-party gateway configuration from local Claude Code/Codex settings. This reads designated configuration files and asks for confirmation through a system dialog. A Claude Code subscription login still does not configure SmartPerfetto automatically; valid API credentials are required.
Evidence management matters during long investigations. A model may need rows from an early overview after dozens of later tool calls. We enlarged the bounded artifact working set while limiting rows sent directly into model context, keeping pagination and retrieval available. This reduces disruption from early eviction while controlling context size. The cache still has capacity and lifetime limits.
Pi’s closeout and connection recovery received several fixes. Runs approaching turn or context limits reserve room for a conclusion. Retryable service failures and idle streams can recover within retry, time, turn, and known-cost constraints, while preserving completed tool results. Cost limits apply only to models with known pricing; they are not a universal billing guarantee for third-party gateways.
New analysis capabilities—and what they can observe
Perfetto v59.1, process lifecycle, and background jobs
Version 1.17.0 synchronized Perfetto v59.1 across the UI/Wasm, pinned trace processor, and generated SQL knowledge. Upstream changes such as FrameTimeline layer groups, heap navigation, and CPU-time views came with it.
Analysis now exposes process start context, startup delays, exit reasons, and state transitions. JobScheduler uses framework track events alongside the existing ATrace view. Missing waiting durations, cancelled jobs, and incomplete attribution retain their limitations instead of being presented as zero.
Bitmap, Doze, and CPU PMU
Bitmap analysis now describes recorded per-process live-set shape, size distributions, and large objects. This helps move an image-memory investigation beyond “usage is high” to the object distribution behind it. Recorded Bitmap objects and total process memory remain different measurements.
Doze analysis adds labelled light/deep idle states and transitions. Rapid switching can warrant further investigation; it does not, by itself, prove abnormal power consumption.
CPU PMU analysis adds counter deltas, event ratios, and process attribution where available. The trace must contain the required counters. An upgrade cannot reconstruct hardware events that were never captured, and incomplete attribution cannot be forced onto one application.
Camera, rendering, and presentation
Camera analysis measures observed frame cadence more explicitly and uses a shared SurfaceFlinger binding decision. Buffer/Transaction analysis distinguishes frame production, transaction activity, and presentation evidence. WebView, React Native, and browser compositor paths have their own conditions.
This matters when a conclusion jumps from rendering activity to assuming that a frame was displayed. Producer activity supports an observation about that stage; presentation needs the corresponding binding and display evidence. Rendering explanations now come from maintained teaching cards, validated together with the pipeline catalog.
What the TraceDemo rounds found
Many test findings were subtler than “the run crashed.” A report might be delivered after unnecessary detours: failed evidence retrieval, invoking a discovery tool as a Skill, guessed parameters, an identity rejection buried in a long result, or SQL using a nonexistent column.
Those problems affect whether an investigation progresses smoothly. We kept the separate run ledgers and targeted reruns rather than flattening them into one result. In the table, P1–P5 denotes five process fixes; F1–F6 denotes six diagnostic and invocation issues identified in the fresh50 investigation.
Batches used different code revisions and samples. Completion counts are not diagnostic accuracy; targeted reruns are not full-batch reruns.
| Record | Observed result | What it establishes |
|---|---|---|
| fixround88 | 88 synthetic cases recorded as completed | Exposed tool-use problems; not every sentence in every conclusion was recalculated |
| P1–P5 targeted reruns | 9/9 delivered; targeted error strings disappeared in the relevant cases | There were still 15 recovered free-SQL failures, so this was not zero tool failures |
| unseen30 | Original batch: 29 successes, 1 failure; combined evidence: 27 original completions + 3 isolated replays | A concurrent asset change made dist and runtime assets inconsistent; the original 29/1 ledger is retained |
| fresh50 | 49 batch records + 1 separate smoke completed | These preceded the F1–F6 fixes; the full 50 were not rerun afterward |
| fresh50 fix verification | Natural camera/thermal reruns plus controlled diagnostic probes | Validates the corresponding fixes, not an overall benefit across every scenario |
These figures come from TraceDemo runner outputs and local SmartPerfetto validation records. Public release evidence is linked from 1.19.0; the complete traces and local sessions are not distributed with this article.
A few concrete examples
Errors need to explain what failed. A long parameter contract once pushed the important part of an identity rejection out of the result preview. Safe reasons and next actions now take priority. SQL diagnostics can expose bounded missing-table, missing-column, or missing-function identifiers with a query hash, without printing the complete raw SQL.
A model’s SQL assumptions can be wrong. sched.is_idle is one example: the correct route uses thread.is_idle through a thread join. We added a core-column reference checked against the bundled schema, slice/thread joins, and window-function guidance. In one camera rerun, SQL failures changed from 3 to 1—but the total query counts also differed. One sample cannot establish a general percentage reduction.
Large timestamps need explicit units. A thermal case exposed an incorrect seconds magnitude. Previews now derive seconds only from values explicitly witnessed as ns and safe to handle precisely, preserving the original cells and clock origin. A targeted check confirmed that 394361.352 s → 394406.092 s spans 44.74 s. A separate frequency-unit label issue remained unresolved in that record and is not counted as fixed.
Plans should explain missing evidence. Phase feedback lists missing calls, successful calls, and failed calls with actual tool-call IDs. The model can investigate further or cite a failed call to explain unavailability. That does not turn an unresolved investigation item into success.
Semantic review also preserved important limits: summing CPU time across parallel threads does not prove an end-to-end critical path. SurfaceFlinger using HWC does not establish that all global GPU work belongs to the target app. I want readers to see these issues alongside the completion markers.
Final artifacts were checked separately
The complete 1.19.0 verify:pr passed, including 405 corpus expectations, 2,013 executed SQL contracts, and 6/6 scene traces.
Those contracts cover production paths, forced contexts, isolated probes, and exact-UPID bindings. Only some have positive semantic assertions; they are not 2,013 real-model cases. SQL coverage had zero skipped/unavailable entries, while other tests retained existing skips.
Delivery received separate checks: native smoke of the final Windows/macOS/Linux archives, npm Trusted Publishing and public installation, and dual-architecture Docker builds.
The macOS package was Developer ID signed, notarized, and stapled. npm installation checked native SQLite and a real trace query without credentials or install scripts. Docker’s version, latest, and SHA tags point to the same dual-architecture manifest.
Already using your own agent? Install Perfetto-Skills
You do not have to run the full SmartPerfetto UI and backend. Perfetto-Skills is an independent Agent Skill for agents with filesystem and terminal access. It supplies analysis workflows, SQL, evidence rules, and a deterministic runner.
| How you want to work | A suitable entry point |
|---|---|
| Open traces in a UI, investigate, save sessions, export reports, and compare | SmartPerfetto |
| Ask your existing Codex, Claude Code, or OpenCode agent to investigate local traces | Perfetto-Skills |
It does not require the SmartPerfetto backend, Provider runtime, UI, or MCP server. Public SQL and methodology are synchronized through immutable source pins, alongside native code, independently owned real-trace fixtures, and a full validation gate. This update pins the 1.19.0 source in public commit 070053917. Its complete gate recorded 514 tests with one skip.
The current repository README gives this project-level installation command:
1 | npx skills@1.5.16 add Gracker/Perfetto-Skills \ |
Keep only the -a options you use; add -g for a user-level install. Running the scripts requires Python 3.11+. Follow the Skill instructions to prepare the pinned trace processor on first use. The skills CLI is a convenience installer from the ecosystem, not an installer mandated by the Agent Skills specification.
A useful first request is:
Use perfetto-performance-analysis to investigate the target application’s startup in this trace. Confirm the process instance and time window first, then list the key evidence, unresolved causes, and data worth capturing next.
SmartPerfetto removed its embedded OpenCode execution engine; using Perfetto-Skills inside the independent OpenCode application remains a separate option. This project is also distinct from Google’s official Perfetto Skill. It has its own domain workflows and executor; the official Skill is another upstream-maintained choice. See the Perfetto-Skills README for installation and usage.
The same evidence limits apply: executable SQL alone does not verify causality. Keeping a trace locally also does not settle what data may be sent to a model service. Users manage their agent’s file permissions and Provider data policy.
Download and upgrade
The GitHub Release provides Windows x64, macOS arm64, and Linux x64 portable packages with bundled runtimes. The npm CLI requires Node.js 24:
1 | npm install -g @gracker/smartperfetto@1.19.0 |
Without a configured Provider, doctor reports that the AI runtime is not ready; credentials still need to be configured. Docker users can select w553000664/smartperfetto:1.19.0; latest has also been updated. Docker does not read the host’s Claude Code login state.
This release preparation adds no historical data backfill. Existing Providers follow the migration rules; retired configurations that cannot be mapped need a valid endpoint. Upgrading cannot fill gaps in PMU, heap-object, or presentation data in old traces. We did not repeat exhaustive real-Provider acceptance on the final version, and historical GLM/DeepSeek coverage cannot be generalized to every model or cloud service.
What I wanted to document here is both the new engine and the smaller problems that can interrupt an investigation. Choose SmartPerfetto for the full analysis product, or try Perfetto-Skills if you prefer to stay inside your existing agent environment.