Settings
Most writing tools bury their settings in a modal you visit once during setup and never again. The settings are usually either obvious (which theme, which font size) or impossibly technical (which tokenizer, which context strategy). Ishvana’s settings are somewhere in the middle — enough depth that serious users can shape the tool to their workflow, but organized clearly enough that nobody has to dig through nested menus to find the thing they want to change. The settings modal has six tabs, each covering a specific category of configuration, and this section of the wiki walks through every knob on every tab. Most of the knobs have good defaults. You probably don’t need to change most of them. But when you do want to change one — when you’re setting up a new LLM provider, when you want to tune the editor to your screen, when you’re troubleshooting performance — this section is the reference for what each setting actually does.
The settings modal is reachable from the gear icon in the main app, or from the Settings keyboard shortcut, or from the Getting Started quickstart flow on first launch. It opens as an overlay on top of whatever you’re currently working on and closes without disrupting your state.
What’s in this section
Section titled “What’s in this section”When to visit settings
Section titled “When to visit settings”Three times in a typical user’s life:
First launch. The Getting Started flow walks you through the essential settings during onboarding — picking a theme, setting up your first LLM provider, configuring auto-save. After that, the settings sit in the background.
When something changes. Getting a new GPU and want Ishvana to use it? Visit Performance. Switching from OpenRouter to direct Anthropic? Visit Models. Buying a license for the first time? Visit Licensing. Settings visits are usually tied to a specific life event.
When something stops feeling right. The editor width isn’t working for your screen. The auto-save interval is too aggressive. The notification level is too noisy. You visit Settings, find the knob that matches, adjust it, close the modal, and get back to writing.
For most authors, the answer to “should I be touching this setting?” is “only if you know why you want to.” The defaults are tuned to work for the common case. The knobs exist for the uncommon cases.
What settings are and aren’t
Section titled “What settings are and aren’t”Settings are user preferences — how you want the app to behave. They’re distinct from:
- Project data. Your manuscripts, your Legendry, your outline — all of that is data, not settings. It lives in your project’s data directory and isn’t affected by what’s in the settings modal.
- System state. Window size, active tab, current scroll position, recent files — these are state, not settings. They persist across restarts but they’re about where you left off, not about how you’ve configured the tool.
- Engine behavior. What the LLM engine does under the hood — routing decisions, context compression, tool registry, caching — is engine behavior. You influence it through settings (especially Models), but the settings expose a curated surface, not every knob.
The settings modal is about the user-preference surface. If you’re looking for something and can’t find it, ask whether it’s actually a preference or whether it’s project data, system state, or engine internals — the answer might be that it’s configured somewhere else.
Configuration layers
Section titled “Configuration layers”Some settings are global (apply to every project), some are per-project, and a few are per-document. The modal makes this distinction clear when it matters.
Global settings live with your user profile, not with any specific project. Theme, keyboard shortcuts, default editor width, your LLM provider credentials — these follow you across every project you open.
Per-project settings live inside the project’s data directory. Project-specific name format, project-specific category tree, project-specific backup preferences — these apply only to the project they’re configured in.
Per-document settings are rare but exist. A specific document might have its own POV override, its own chapter word count target, its own ProseGuard rule exceptions. These are usually set inline from the document’s own context menu rather than from the main settings modal.
When a setting has multiple layers, the more specific layer wins. A per-document override beats a per-project default, which beats a global default.