Best Practices

Start with the right mental model

Zorai works best when you treat it as a daemon-backed operating environment, not as a single chat box.

• Keep the daemon running and reconnect from whichever client is convenient.
• Use the desktop UI when you want broad visibility and settings control.
• Use the TUI when you want keyboard-first control and SSH-friendly work.
• Use the CLI and MCP server for automation and external-agent integration.

Choose strong model roles

The built-in fires are more useful when each one is configured for its actual job instead of pointing everything at the same model.

Svarog — The Smith

Use your strongest available model. Svarog handles:

• Primary execution and long reasoning chains
• Tool orchestration and multi-step coding
• Synthesis across large threads
• Goal runs with planning and recovery

Example configuration: Claude Opus, GPT-4, or strongest available.

Weles — The Guardian

Use a strong review/governance model. Weles handles:

• Risk review and policy pressure
• Checking risky plans before execution
• LLM-based compaction for important threads
• Validating assumptions when the main thread moves fast

Recommended: GLM-5.*, MiniMax M2.7, Qwen 3.6 Plus, or similar tier.

Do not starve Weles. If governance is too weak, Zorai becomes noisier and less trustworthy exactly where it should be more disciplined.

Rarog — The Concierge

Use a light, cheap, fast, tool-reliable model. Rarog handles:

• Onboarding and setup help
• Operator-facing summaries
• Lightweight steering and quick checks
• Conversational glue around heavier fires

Characteristics: Low cost, fast latency, reliable tool invocation. Reasoning off by default is fine.

Use compaction strategically

Heuristic compaction is the default — fine as a conservative baseline and cheaper. For long-lived threads, serious coding, or governance-heavy runs, prefer LLM-based compaction.

Where to change: Desktop app: Settings → Agent → Context Compaction. TUI: /settings → Advanced.

Prefer durable threads

Zorai gets stronger when a thread represents a real line of work.

Resetting too often destroys one of Zorai's biggest advantages: continuity.

Be explicit with objectives

The agent does better when you state the goal, constraints, success condition, and verification path.

check this repo

Find why the release build is failing on Linux, 
identify the first concrete root cause, make the 
smallest safe fix, and tell me what you verified 
locally.

Zorai rewards operationally specific instructions.

Run goal work as goal work

If work is long-running, multi-step, or likely to survive client restarts, use goal runners or a workspace task instead of manually babysitting a chat thread.

Good goal-run candidates:

• Release preparation with checklist execution
• Large bug investigations spanning multiple files
• Repository-wide audits or refactors
• Documentation sweeps across many pages
• Repeated operational workflows you want to capture as skills

Goals are the right layer when you want planning, execution queues, approvals, persistence, and reflection. Workspaces are the right layer when you also want assignment, board status, and review.

Use the right interaction mode

Zorai gives you different ways to involve other fires. Use them intentionally.

Handoff behavior: Changes active responder, future operator messages route to that agent, recorded as visible system event.

Use approvals to protect the edges

Zorai is strongest when autonomy and operator control are both real.

The point is not to slow the agent down. The point is to make expensive mistakes rarer.

Match client to situation

Use the client that gives the right control surface for the task.

There is no single correct frontend. The daemon is the product; clients are views into it.

Keep governance and cost in balance

You do not need maximum quality everywhere. You do need quality where errors are expensive.

Budget strategy:

• Spend most on Svarog (primary execution)
• Spend enough on Weles to keep reviews meaningful
• Save money with Rarog and lighter support roles
• Use heuristic compaction for throwaway threads
• Use WELES compaction for serious or durable threads

If cost is exploding, check:

• Are too many fires configured with premium models?
• Is compaction overpowered for the thread type?
• Are you creating too many fresh threads and losing continuity?
• Are tool loops or retries set too aggressively?

Suggested baseline configuration

A good starting point:

That baseline is usually enough to get Zorai feeling substantially better than a generic single-model terminal chat workflow.