Video Summary - Fable Broke My App and Couldn't Fix It

Tech/performance problem (Web app GPU/CPU usage)

The creator debugs T3 Code’s web UI performance, where simply using the app caused unexpectedly high resource usage:
- GPU process CPU usage around 13–15% at 720p
- Up to ~50% CPU utilization (graphics process) at higher resolution (e.g., 5K Studio Display XDR)
The app felt fast (UI snappy), but GPU utilization was pegged, implying a rendering/compositing problem rather than slow networking or heavy JS execution.
Browser DevTools profiling was not helpful, especially because DevTools often emphasizes JS timing/requests and may miss issues dominated by CSS/compositor behavior.

The creator tried “agents” to analyze and fix the performance issue:
- Soul and Codeex
The agent output was often confident but wrong, including:
- Garbage/irrelevant profiling summaries
- Misleading feature focus (e.g., treatment of Ultrathink composer elements)
Even after a massive PR (~10,000+ lines) focused mostly on performance in network / React update handling, the GPU issue didn’t meaningfully improve.
Lesson: agents can build tools quickly, but they still require human steering, and automated diagnosis can be inaccurate.

The creator asked the agent to generate a runtime testing harness:
- A window function like _t3GPU.apply that injects custom CSS to toggle visual features, including:
  - animations, filters, shadows, composer elements
  - blur, noise layer
  - media-related layers, etc.
- A reset function _t3GPU.reset to restore state
This enabled rapid A/B testing in production via console commands, directly correlating feature toggles with GPU process utilization.

Toggling animation-related features produced decisive results:
- Disabling animations dropped GPU usage from ~25–30% to ~3% or less
- Resetting returned the GPU spike
Nuance from the analysis:
- With 120 Hz displays, infinite animations keep the compositor active.
- Multiple concurrent animated elements can force many tiny composited GPU layers, causing constant recomposition even when the UI otherwise isn’t changing.

The debugging isolated multiple animation sources; the biggest/early “culprit” was:
- Pulsing terminal icon in the sidebar (an opacity pulse / pulsing indicator)
Other smaller-but-real animated UI elements mentioned:
- Typing dots for message timeline
- Thread/status indicators
- Connection preview / spin / countdown elements (generally not major)
- “Working completed / work in progress” indicators

The creator criticizes agent advice as often visually/semantically poor, e.g.:
- Suggestions to replace pulsing with a “static” or “finite pulse only when active” strategy
The creator felt this guidance was incorrect engineering/design-wise.

After giving up on Soul/Codeex for diagnosis, the creator used Fable for deeper visual/performance triage.
Fable produced an animation inventory and categorized animations by impact:
- Some “obvious” ones didn’t matter much (initial loading skeleton, Ultrathink-related effects)
- Others did matter: infinite pulses and compositor-driven opacity animations
Core explanation:
- Each infinite animation promotes elements to their own GPU/compositor layers.
- Even if each animation is small, the combination becomes expensive—especially at high refresh rates.

Fable also highlighted backdrop blur (added for aesthetics).
The creator discovered an additional compounding factor:
- A noise/grain overlay applied at low opacity for texture
- When combined with backdrop blur and consistent animations, it caused:
  - significant GPU compositor load
  - visible UI color inconsistencies, especially on HDR displays
Fix involved:
- Removing/reducing the noise layer and tuning grays/colors to prevent jarring differences across UI regions
- Adjusting dark mode styling (including changes affecting the composer lower chrome strip / branch/checkout area)

After shipping the fixes and switching to another browser (Helium), GPU usage initially still seemed high.
The creator later realized the root cause wasn’t the T3 Code UI alone:
- Other open tabs (specifically multiple Claude pages) independently caused notable GPU usage.
Conclusion:
- Even an idle Claude.ai page can use about ~10% GPU per tab on the creator’s high-end laptop.
This reframed the “did the T3 Code fix work?” doubt: the environment (open AI tabs) still contributed to GPU utilization.

Agents are useful for:
- Navigating codebases faster
- Generating targeted debugging tools (like CSS togglers)
- Testing many hypotheses quickly
Agents are not reliable solvers when:
- Their profiling interpretation is wrong
- CSS/compositor GPU behavior isn’t represented well in their summaries
Recommended mental model:
- Use agents as tool builders and hypothesis generators, but rely on human-controlled experiments to confirm.

Sponsor: Blacksmith for CI acceleration on GitHub Actions
- Claims: 2x faster actions, 4x faster cache downloads, up to 40x faster Docker builds
- Features include: SSH access, git checkout caching, and observability/logs for build diagnostics

Primary speaker: the YouTube creator (author of the T3 Code debugging story; also references “Fable” and “Soul” as tools/agents)
Tools/agents mentioned: Soul (Codeex/Codex-style agent) and Fable
Other systems referenced as sources of GPU load: Chrome/DevTools, Helium browser, and Claude.ai tabs