Diagnostics and Debugging

Use local inspection tools to understand prompt assembly, retrieval behavior, and scene failures.

Diagnostics are for the situations where the app is technically running, but the scene quality still feels wrong.

These tools exist so you can inspect what Abolitus is doing locally instead of guessing blindly.

What Diagnostics Are Actually For

Use diagnostics when the problem is interpretive rather than purely technical.

Typical examples:

the model forgot an important fact,
a lorebook entry never seems to trigger,
a wrapper feels too strong or too weak,
context pressure feels worse than expected,
or you want to understand why one reply looked completely different from the last few turns.

Diagnostics are especially valuable because many scene failures look similar from the outside while having very different causes underneath.

These Controls Are Device-Local

Diagnostics settings are local to the current device.

That is intentional.

They control inspection surfaces and debug capture behavior on the machine you are actively using. Another device does not need to mirror your entire debugging posture just because it shares the same creative workspace.

Context Inspector

Context Inspector is the first tool to reach for when you want to understand what the model likely saw.

Use it when:

a scene lost continuity,
Author's Note is not having the effect you expected,
prompt-pruning changes produced surprising results,
or a strong character suddenly started sounding generic.

The goal is not merely to show "the prompt exists." The goal is to show whether the right material actually made it into the live turn.

That distinction matters because content can still be stored in your workspace while no longer fitting into the prompt that the model receives right now.

Memory Inspector

Memory Inspector is for retrieval questions rather than broad prompt questions.

Use it when:

a lorebook entry should have appeared but did not,
the wrong memory keeps surfacing,
you are tuning dense worldbuilding,
or you want to understand whether retrieval is the problem before changing your prompt stack.

This is one of the cleanest ways to distinguish "the model ignored it" from "the system never surfaced it in the first place."

Retrieval Trace

Retrieval Trace gives you a more explicit record of what was matched or injected on the memory side.

Turn this on when your problem is specifically about lore retrieval, semantic recall, or continuity support rather than general model quality.

This is most valuable when you are testing:

trigger wording,
lore scope overlap,
retrieval noise,
or large imported worldbooks.

Chat Statistics

Chat Statistics give you a fast operational read on the current scene.

Use them when:

the chat feels bloated,
you want a quick read on turn growth,
you want to compare heavy and light scene setups,
or you suspect that the scene is collapsing under its own size.

This is less about literary analysis and more about catching workload patterns early.

Persist Prompt History

Persist Prompt History is for sustained investigation rather than one-off curiosity.

Use it when you want a longer audit trail of how prompt construction changed across turns.

That is helpful when:

a bug only appears intermittently,
a scene degrades gradually rather than all at once,
or you are comparing two different tuning strategies over time.

If you are only casually chatting, you probably do not need it enabled all the time.

A Good Debugging Order

If you are not sure where to start, use this sequence:

Check Context Inspector.
Check whether token pressure is the real issue.
Check Memory Inspector or Retrieval Trace if the problem looks retrieval-related.
Only then start changing samplers, wrappers, or routing.

This order prevents one common mistake: rewriting the creative stack before verifying whether the needed context was present at all.

What Diagnostics Cannot Do

Diagnostics can show you a lot, but they do not magically turn every model decision into a perfectly explainable machine.

They are best at helping you narrow the problem to the right layer:

prompt construction,
retrieval,
context pressure,
local runtime conditions,
or route behavior.

That alone is usually enough to save a huge amount of blind trial and error.

"the lorebook is not triggering,"
"old chat is being squeezed out too early,"
or "the provider route is refusing, not the local prompt stack."

Turn heavy debug capture off when you are done

Diagnostics are powerful, but they are most useful during deliberate investigation rather than relaxed everyday use.

Read Token Budget if the failure smells like context pressure.
Read Local RAG if the issue is long-term retrieval quality.
Read Settings Reference for the bigger picture of what stays local and how settings are divided.