ChatTTS's scheduler carries the highest activity risk — 5 functions to address first

Across 440 analyzed functions in 2noise/ChatTTS, 40 have reached critical band — and every one of the top 5 hotspots sits in the ‘debt’ quadrant, meaning they carry extreme structural complexity that has not been recently touched, but will impose high regression risk the moment development resumes. The headline case is _schedule in ChatTTS/model/velocity/scheduler.py, which combines a cyclomatic complexity of 44, a fan-out of 26, and an activity risk score of 15.74 — structural debt that warrants careful characterization before the next development push. The pattern repeats across the inference and GPT layers, where god-function and complex-branching antipatterns dominate all five top hotspots.

The table below ranks functions by activity-weighted risk — a score that multiplies structural complexity by recent commit frequency. A function that is both hard to understand (high cyclomatic complexity) and actively changing is a higher priority than one that is complex but untouched. CC = cyclomatic complexity (independent execution paths); ND = max nesting depth; FO = fan-out (distinct callees).

Top 5 Hotspots

Function	File	Risk	CC	ND	FO
_schedule	ChatTTS/model/velocity/scheduler.py	15.7	44	4	26
generate	examples/cmd/stream.py	14.8	45	6	14
infer	ChatTTS/core.py	14.7	27	5	15
generate	ChatTTS/model/gpt.py	14.2	70	4	78
forward	examples/onnx/modeling_llama.py	14.1	53	2	18

Codemod / Tooling Files in Results

Two of the top five hotspots — forward in examples/onnx/modeling_llama.py and generate in examples/cmd/stream.py — are located under the examples/ directory rather than the core library. The modeling_llama.py file in particular appears to be an ONNX export adaptation of a LLaMA model forward pass, likely vendored or closely derived from the Hugging Face Transformers implementation, and its CC of 53 reflects the inherent complexity of that upstream model code rather than ChatTTS’s own logic. To exclude these from future analyses, add the following to your .hotspotsrc.json: { "exclude": ["examples/"] }. This will focus Hotspots scoring on the core library under ChatTTS/.

Hotspot Analysis

_schedule — ChatTTS/model/velocity/scheduler.py

Based on its name and location in the velocity scheduler module, _schedule almost certainly orchestrates how inference requests are sequenced and dispatched — the kind of function that sits at the center of throughput and latency decisions. Its cyclomatic complexity of 44 means there are at least 44 independent execution paths to reason about and test; its fan-out of 26 means it directly calls 26 distinct functions, giving it a wide blast radius across the codebase. Flagged as a god_function with exit_heavy and complex_branching patterns, and sitting in the ‘debt’ quadrant with an activity risk score of 15.74, this function is structural debt that has not been recently modified — but any future work on scheduling logic will require navigating all of that complexity at once.

Recommendation: Before any scheduling changes, write characterization tests that cover the major branching paths (44 CC means at minimum 44 test cases to approach full path coverage). Then extract cohesive sub-responsibilities — request prioritization, capacity checks, dispatch — into named sub-functions to reduce both CC and the fan-out of 26.

infer — ChatTTS/core.py

Located in ChatTTS/core.py, infer is almost certainly the primary public-facing inference entry point for the library — the function that downstream callers invoke to convert text to speech. With a cyclomatic complexity of 27, a nesting depth of 5, and a fan-out of 15, it combines moderate-to-high branching with deep control flow, and carries five flagged antipatterns including god_function, deeply_nested, exit_heavy, and stale_complex. Sitting in the ‘debt’ quadrant with an activity risk of 14.71, its stale_complex flag is particularly telling: this is a structurally complex entry point that has accumulated complexity over time and will be a high-risk surface whenever the public API next needs to change.

Recommendation: Reduce the nesting depth of 5 by extracting inner conditional blocks into named helper functions with clear preconditions; the exit_heavy pattern suggests multiple early-return paths that should be consolidated into a guard-clause structure at the top of the function to make the happy path immediately readable.

generate — ChatTTS/model/gpt.py

As the generate function inside the GPT model module, this function almost certainly drives the core autoregressive token generation loop — the most computationally and logically central operation in a TTS system. Its cyclomatic complexity of 70 is in the high range, and its fan-out of 78 is exceptional: it calls 78 distinct functions, meaning changes here can ripple across a very broad surface of the codebase. Flagged as a god_function and long_function in the ‘debt’ quadrant with an activity risk of 14.2, this is the highest blast-radius function in the repository — overdue for decomposition before any model architecture work resumes.

Recommendation: Map the 78 callees to identify which logical phases they belong to (e.g., input preparation, sampling, stopping criteria, output post-processing) and extract each phase into a dedicated function or class. This alone will reduce the CC and make individual phases independently testable.

Patterns Found

Antipatterns detected across the top functions in this snapshot:

Pattern	Occurrences
god_function	7
long_function	5
complex_branching	4
exit_heavy	3
stale_complex	3
deeply_nested	2

These labels belong to two tiers — Tier 1 (structural): complex_branching, deeply_nested, exit_heavy, long_function, god_function. Tier 2 (relational/temporal): hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god.

Key Takeaways

• The generate function in ChatTTS/model/gpt.py has a fan-out of 78 — the broadest coupling in the repository. Any change to it touches 78 potential call sites; map those dependencies before any model-layer work begins.
• All five top hotspots are in the ‘debt’ quadrant, meaning none are actively changing right now — this is the window to refactor before the next development push forces engineers to work inside CC 44–70 functions under time pressure.
• The infer function in ChatTTS/core.py is the library’s public entry point and carries five antipattern flags including stale_complex and deeply_nested (ND 5); adding characterization tests here before any API changes is the single highest-leverage risk-reduction action available.

Reproduce This Analysis

git clone https://github.com/2noise/ChatTTS
cd ChatTTS
git checkout 77b89ee281cd479f5b1a787ada330dc975ca1f2a
hotspots analyze . --mode snapshot --explain-patterns --force

To run the same analysis on your own codebase, run hotspots analyze . --mode snapshot in any local git repo — no configuration required.

Hotspots highlights structural and activity risk — not “bad code.” Findings are a prioritization aid, not a bug predictor. Editorial policy →

$ brew install Stephen-Collins-tech/tap/hotspots

$ cargo install hotspots-cli

$ hotspots analyze .