Sunni 2.0 AI Assistant

THE LOCAL AI STACK

Four layers. One working assistant.

When something fails, knowing which layer owns the problem saves a great deal of unnecessary surgery.

01 SUNNI Desktop shell

→

02 OPEN WEBUI Web interface

→

03 OLLAMA Model runtime

→

04 LLM The actual model

RULE OF THUMB Test each layer independently. The first layer that fails is where troubleshooting should begin.

QUICK NAVIGATION

Go directly to the part you need.

01 · Install the Stack 02 · Install & Swap Models 03 · Configure Open WebUI 04 · Tune Model Settings 05 · Configure the System Prompt 06 · Benchmark a Model 07 · Troubleshoot the Chain

01 · INSTALL THE STACK

Give Sunni something to talk to.

Sunni does not contain an AI model. The current 2.0.x application expects a local web interface at http://localhost:8080, with Ollama providing the model runtime behind it.

01

Install Ollama

Install the local model runtime and verify that the service is available.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

Official Ollama Linux Download →

02

Verify the Ollama endpoint

Ollama normally listens locally on port 11434. Confirm that the service is running before involving the web interface.

ss -ltnp | grep 11434
ollama list

If ollama list works, the runtime itself is alive even if no models are installed yet.

03

Provide Open WebUI

Sunni 2.0.x embeds the local web interface served at http://localhost:8080. If you already have the ollama-webui snap installed, verify the service and port.

snap services ollama-webui
sudo ss -ltnp | grep 8080

The web interface is a separate component. Sunni can launch perfectly while still displaying nothing useful if port 8080 has no working UI behind it.

04

Launch Sunni

Once Open WebUI responds locally and Ollama has at least one model, launch Sunni and select that model inside the web interface.

./Sunni

Source installations may use the supplied launch script instead of a packaged binary.

02 · INSTALL & SWAP MODELS

Sunni is not married to one brain.

Models are managed by Ollama, not packaged inside Sunni. You can install several models, keep them side by side, and change which one Open WebUI uses without rebuilding the Sunni application.

OPEN WEBUI · SETTINGS · MODELS

Install a new model without leaving Sunni.

Open Settings inside the embedded Open WebUI and select Models. The Pull a model from Ollama.ai field lets you download another Ollama model directly from the interface. Enter the Ollama model name, then click the green download button.

Open Settings. Choose Models from the left navigation.
Enter the exact model name. The development test shown here uses qwen3-coder:30b.
Start the pull. Click the green download button. Open WebUI passes the request to Ollama and shows progress in the Models panel.
Let the download finish. Large models can take time and substantial disk space. Keep Ollama running until the pull completes.
Select the new model. Return to the chat model selector and choose the newly installed model. Sunni itself does not need to be rebuilt.

TERMINAL ALTERNATIVE

ollama pull qwen3-coder:30b
ollama list

The GUI and terminal routes manage the same Ollama model library. Use whichever workflow is more convenient.

Sunni Open WebUI Models settings downloading qwen3-coder:30b through Ollama — Installing `qwen3-coder:30b` from Open WebUI inside Sunni. Displayed at 50% of the original 1920 × 1000 screenshot. Click to enlarge.

A

See what is installed

ollama list

This is the quickest terminal check for models currently available to the local Ollama runtime. Models installed through Open WebUI should appear here as well.

B

Test the model directly

ollama run qwen3-coder:30b

Direct CLI testing removes Sunni and Open WebUI from the response path. If the model streams quickly here but feels slow in the web interface, the model itself may not be the bottleneck.

C

Swap the active model

Open a chat in Sunni and use Open WebUI's model selector to choose any installed model. The model can change from conversation to conversation without changing or rebuilding the Sunni desktop application.

D

Compare models fairly

Keep the System Prompt, model parameters and test prompt unchanged while switching only the model. This isolates the model as the variable and makes differences in speed, code quality and debugging behavior easier to judge.

DEVELOPMENT NOTE

During Sunni testing, qwen3-coder:30b proved substantially more code-oriented than llama3:latest. Its first pass was not flawless, but it diagnosed and corrected a threading problem on the second pass instead of abandoning the debugging path. Treat this as a tested Sunni development observation, not a universal benchmark result.

03 · OPEN WEBUI SETTINGS

Know which controls actually matter.

Sunni embeds Open WebUI, so most model behavior is configured inside the Open WebUI Settings dialog rather than in the Sunni desktop shell itself. The interface separates general behavior, generation parameters, model management, external endpoints, interface preferences and account controls. Knowing which panel owns which setting makes configuration much less mysterious.

WHERE TO START

Open Settings inside Open WebUI. The current Sunni-compatible interface exposes General, Advanced, Models, External, Interface, Voice, Chats, Account and About. Most users will spend the majority of their time in General, Advanced and Models.

A

General

Use General for the everyday defaults that shape how Open WebUI starts a conversation. This is where you should confirm the default model and any global chat behavior before changing lower-level generation controls.

Select the model you want Open WebUI to prefer by default.
Keep defaults simple while comparing models so the UI is not introducing extra variables.
If a new model was just installed, verify that it appears in the model selector before changing anything else.

B

Advanced

Advanced contains the generation controls that most directly affect response style, determinism, context usage and output length. This is where Sunni's development baseline belongs.

Temperature controls randomness. Lower values are useful for technical work.
Top K / Top P restrict token selection and help keep output focused.
Repeat Penalty / Repeat Last N discourage looping without over-penalizing legitimate code repetition.
TFS Z and Mirostat are optional sampling systems; Sunni's baseline leaves them effectively disabled.
Context Length controls how much conversation/source material the model can consider.
Max Tokens controls how much text the model may generate in one response.

Change one parameter at a time when testing. If five sampling controls move at once, it becomes nearly impossible to know which one helped.

C

Models

Models is the bridge between Open WebUI and Ollama's local model library. Use it to pull new models, remove models you no longer need, or upload a compatible GGUF model when the interface supports it.

Enter an exact Ollama model name in Pull a model from Ollama.ai.
Watch the progress indicator until the pull completes.
Use the delete control carefully; removing a model frees local storage but also removes it from the selector.
Model installation does not require rebuilding Sunni.

The screenshot in the previous section shows this panel while qwen3-coder:30b is being downloaded.

D

External

External is for connecting Open WebUI to services outside the default local Ollama workflow, including OpenAI-compatible API endpoints.

For the standard Sunni + local Ollama setup, the OpenAI-compatible API Base URL can remain blank.
Only populate an external base URL when you intentionally want Open WebUI to talk to another compatible provider or server.
Do not enter a random localhost address merely because the field exists.

E

Interface

Interface settings control presentation and convenience rather than the model's intelligence. Use these for visual preferences and workflow polish without expecting them to change coding quality.

Theme and appearance changes are cosmetic.
Conversation presentation settings can improve readability without altering model output.
If response text feels artificially slow, compare the same model through the Ollama CLI before assuming the model itself is slow.

F

Voice

Voice settings control speech-related input and output features. They are optional for a development-focused Sunni setup and do not need to be configured for normal text chat, coding or debugging.

G

Chats

Chats controls conversation behavior and history-related preferences. Keep chat history available when you want the current conversation to preserve debugging context, but remember that conversation history is not the same thing as training the underlying model.

H

Account & About

Account contains user-level settings. About is useful for identifying the installed Open WebUI build when troubleshooting compatibility, behavior or performance differences between systems.

Version information matters. Sunni's current stack may use an older Open WebUI build whose behavior differs from newer documentation.

MODEL BEHAVIOR

Settings condition output.

Temperature, sampling controls, context length, max tokens and the System Prompt influence how the selected model behaves. They do not upgrade the model's underlying knowledge or reasoning ability.

MODEL CAPABILITY

The model still sets the ceiling.

If a coding model repeatedly misses imports, invents code that is not in the supplied file, or cannot repair its own runtime errors, changing to a stronger model may accomplish more than endlessly tuning sampling values.

FAST DIAGNOSTIC

ollama run <model-name>

If the exact same model responds much faster in the terminal than through Sunni/Open WebUI, raw model generation is not the only bottleneck. The web frontend, streaming path or embedded browser rendering can also affect the perceived response rate.

04 · MODEL SETTINGS

A disciplined baseline.

These values were developed as a practical starting point for Sunni's software-development workload. They are not magic numbers. Different models can prefer different sampling settings, but this baseline keeps the model relatively focused and gives code generation enough room to finish complete files.

TEMPERATURE 0.3

TOP K 40

TOP P 0.9

MIROSTAT 0 / Off

TFS Z 1.0

REPEAT PENALTY 1.1

REPEAT LAST N 64

CONTEXT LENGTH 16,384 starting target

MAX TOKENS 4,096

OPENAI API BASE URL Leave blank unless using an OpenAI-compatible external endpoint

05 · SYSTEM PROMPT

Condition the model for the job.

A System Prompt does not retrain the model. It gives the model persistent operating instructions: how Sunni should approach debugging, code generation, project safety, Linux, web development and communication.

WHAT IT CAN DO

Shape behavior

The System Prompt can tell Sunni to inspect supplied code before guessing, preserve working behavior, return complete files, avoid placeholder code, verify explicit requirements and continue debugging after the first error.

WHAT IT CANNOT DO

Raise the model ceiling

A detailed System Prompt cannot manufacture knowledge or reasoning ability that the underlying model does not possess. If repeated failures remain after good conditioning, change the model instead of turning the prompt into a 40-page repair manual.

PROMPTING RULE

Be explicit about the outcome, not every implementation detail. For example: “Accept hostname, IP or full URL. Display Port, Service and Status. Keep the GUI responsive.” The model should decide whether that means urlparse, QThread, sockets or another suitable implementation.

06 · BENCHMARK A MODEL

Change one variable at a time.

A model that looks brilliant on a polished demo can still collapse when it has to repair its own runtime error. Test generation and debugging as one workflow.

01

Use the same prompt

Keep the benchmark identical between models.

Generate a simple PySide6 application that accepts a hostname, IP address, or URL. Scan a list of common TCP ports and display the results in the GUI as Port, Service, and Status (OPEN/CLOSED). Use Python sockets. Keep the GUI responsive while scanning. Generate a complete runnable app.py.

02

Run the generated application

python3 app.py

Judge the result by behavior, not appearance. Does it launch? Does it accept every promised input type? Does the UI remain responsive? Does it display every requested field?

03

Feed the exact failure back

Paste the traceback and the complete current file. A useful coding model should inspect the code, identify the actual cause and continue repairing the same application instead of inventing nonexistent code or sending you on an unrelated scavenger hunt.

04

Compare the whole loop

Measure first-pass correctness, response speed, debugging accuracy, persistence after failure and how many repair rounds are needed before the feature actually works.

07

TROUBLESHOOTING

Find the slow or broken layer.

Do not blame the entire stack when one component is coughing smoke.

The web interface feels much slower than Ollama. +

Run the same model directly with ollama run <model-name>. If CLI generation is substantially faster, the model is not the only bottleneck. The web frontend, streaming path or browser rendering layer may be adding delay.

Sunni opens, but there is no working AI response. +

Verify the chain in order:

snap services ollama-webui
sudo ss -ltnp | grep 8080
sudo ss -ltnp | grep 11434
ollama list

DIAGNOSTIC ORDER

Sunni → Open WebUI → Ollama → Model. Stop at the first layer that does not work independently.

A model generates attractive code that still fails. +

Treat generated code as a first implementation, not divine revelation. Run it, capture the exact failure and test whether the model can repair its own work. Debugging quality is often more valuable than a flashy first pass.

Should I keep expanding the System Prompt whenever a model makes a mistake? +

Add general engineering rules when a failure reveals a reusable lesson. Do not add application-specific instructions for every bug. If you have to teach the System Prompt how to implement every feature, the underlying model is probably the limiting factor.

Build the brain behind the interface.