OpenWebUI Tool Mode

Yes — that reply is the smoking gun. It is not behaving like a normal chat model that happens to have tools available; something in the OpenWebUI tool/function pipeline is replacing or heavily overriding the model’s normal system instructions.

I’m going to pin this against the current OpenWebUI behavior, because the wording you pasted is specific enough that we may be able to identify which layer is doing it.

Yes. That response finally makes the problem quite clear.

Your models have not suddenly become stupid, and you do not need to replace them. OpenWebUI is putting them into an agent/tool-oriented operating mode.

The current OpenWebUI documentation confirms that, beginning with v0.10.0, Native/Agentic function calling became the default, and in that mode OpenWebUI automatically injects its built-in system tools. Even more importantly, the new “Builtin Tools” capability defaults to enabled unless it is explicitly disabled. citeturn726151search0turn914754search0

That fits perfectly with the bizarre response you just got:

> “The assistant is designed to strictly operate within the provided tools…”

and:

> “For general questions, the system is intentionally limited to structured tool interactions…”

That isn't the normal personality of Qwen, Llama, Mistral, etc. It is the model interpreting the tool environment OpenWebUI has wrapped around it as its primary purpose.

And it explains our earlier vocabulary test perfectly. You gave it:

“c”

which plainly meant Paris in the quiz, and instead it effectively said:

"I don't understand. Would you like me to schedule something?"

😂

That was not a language-model problem. It was an orchestration problem.

The setting I now want to kill

Forget the Native/Legacy setting for a moment. The much more interesting setting is:

Builtin Tools

Current OpenWebUI documentation says it is here:

Workspace → Models → Edit model → Capabilities → Builtin Tools

and explicitly says disabling it prevents those system tools from automatically being injected. citeturn914754search0turn914754search8

So what we actually want for Little Ougway is approximately:

Builtin Tools: OFF

while leaving ordinary inference intact.

Then later, when we deliberately want Ougway to have web search, memory, terminal access, database functions, etc., we can attach those capabilities intentionally rather than turning the entire model into Jeeves the Calendar Butler.

There is another interesting discovery: OpenWebUI's source currently defaults unspecified capabilities to true, including built-in tools. citeturn914754search27 That may explain the maddening thing you encountered yesterday where you went looking for a setting, found essentially no configured models, changed a parameter elsewhere, saved it, and came back to find the default had returned. The system can inherit these capabilities even when you haven't explicitly created a customized model entry.

One extremely useful test before touching anything

On the Ougway machine, bypass OpenWebUI completely:

ollama run qwen3-vl:8b

Then ask it something ridiculously ordinary:

What is the capital of France?

or:

Tell me why the sky is blue.

I expect it will answer normally.

If it does, we have isolated the fault beautifully:

Ollama/model → good
OpenWebUI chat pipeline → tool instructions being injected

Then we go after Builtin Tools, not the models.

And there is a pleasant irony here: the upgrade didn't actually break Qwen's intelligence. It gave Qwen a shiny new toolbox and apparently told it, “YOU ARE NOW THE TOOLBOX.” 😆 memcite

Yes — and I think you just exposed the distinction I missed earlier.

The Workspace → Models page is not a list of the Ollama models installed on your machine. In current OpenWebUI, that area is primarily for custom model presets/agents that you create on top of a base model. OpenWebUI's documentation describes them as configuration wrappers around an underlying model. citeturn261017search0turn261017search3

So an empty Models page can be completely normal.

Your actual models — qwen3:8b, qwen3-vl:8b, llama3.1:8b, etc. — belong to Ollama, not OpenWebUI. It makes no difference whether you originally downloaded them through an older OpenWebUI, with:

ollama pull qwen3-vl:8b

or some other Ollama mechanism. OpenWebUI talks to the Ollama server and obtains the available base-model list from it. The current docs explicitly describe Ollama as the component that manages/serves the models, while OpenWebUI sits on top. citeturn261017search4turn261017search11

So this changes my diagnosis slightly.

There are really two different "model lists"

Think of it this way:

Ollama models

qwen3:8b
qwen3-vl:8b
llama3.1:8b
mistral
deepseek-r1:8b
...

Those physically exist on Ougway and should be obtained through the Ollama connection.

Then OpenWebUI has:

Workspace → Models

"My Qwen"
"Little Ougway"
"Coding Assistant"
"Research Assistant"
...

Those are optional wrappers you create. They can specify:

• which Ollama base model to use
• system prompt
• parameters
• knowledge
• tools
• capabilities

And you haven't created any of those, hence the empty page. citeturn261017search0

So your old models are not missing because they were downloaded before the upgrade.

In fact, if you can start an ordinary OpenWebUI chat and select qwen3-vl:8b from the model selector, that proves OpenWebUI is already seeing the Ollama model.

And that explains yesterday's maddening UI

This is the part that interests me.

We went into Workspace → Models looking for settings belonging to qwen3-vl:8b.

There was nothing there.

Now I know why.

qwen3-vl:8b is a base model supplied by Ollama, not a Workspace Model.

So when we changed something elsewhere and expected it to stick to Qwen, we may have been editing a chat/session/default parameter rather than creating an actual persistent model configuration.

That would explain:

> set Native → Save → go back → it's Default again.

We weren't necessarily editing Qwen itself.

I would NOT redownload anything

That would accomplish essentially nothing.

Instead, there's a very simple thing I'd like to inspect next.

Go to:

Admin Panel → Settings → Connections

There should be an Ollama connection there. Current OpenWebUI documentation says Ollama management now lives under:

Connections → Ollama → Manage / wrench icon. citeturn261017search27

Don't change anything yet.

I'm particularly interested in what that page shows, because now we have two separate questions:

1. Where are your base Ollama models being supplied from?
2. At what level is OpenWebUI injecting that damned tool-only system instruction?

And I think #2 is the real culprit.

There's also another route available to us now that I understand the new design: we could deliberately create one Workspace Model called something like Qwen Normal, select qwen3-vl:8b as its base, turn its built-in tool capabilities off, and leave everything else alone. That's a nice controlled experiment because it doesn't touch Ollama or your existing models at all. citeturn261017search0turn261017search17

So no — don't download newer copies of all those models. Your instinct that the empty list meant something different was correct. We were looking at the new agent/preset layer, not your actual Ollama inventory.

And, amusingly, this redesign is starting to explain why the interface seemed to be gaslighting us yesterday. 😄 memcite

Yes — in your setup, http://localhost:11434 is exactly what I would expect to see. Because OpenWebUI and Ollama are both running natively on the same Ougway machine, localhost really does mean the same host. The Docker warning is aimed at people running OpenWebUI inside a container, where localhost would point back into the container instead of to the host OS. citeturn350339search10turn350339search18

And since you are not getting the connection error, I would leave that connection alone. OpenWebUI's own documentation says it normally auto-connects to Ollama, and the current management location is exactly what you found: Admin Settings → Connections → Ollama → Manage. citeturn350339search10

So yes, go into Models instead.

What I expect you may find there is that the page is waiting for you to create a model configuration/preset, because Workspace Models are wrappers around one of the base models OpenWebUI already gets from Ollama. citeturn350339search4turn350339search7

If there's something like New Model / Create Model / Add Model, open that. The interesting moment will be when it asks for the Base Model. See whether the dropdown contains your familiar guys:

qwen3:8b
qwen3-vl:8b
llama3.1:8b
deepseek-r1:8b
etc.

If they appear there, we've established almost everything we need:

Ollama connection = fine.
Old models = fine.
Empty Workspace Models page = normal.
Problem = OpenWebUI's new model/tool configuration layer.

And then we're hunting specifically for Capabilities → Builtin Tools, because current OpenWebUI documentation says that is where the automatic system-tool injection can be disabled on a Workspace Model. citeturn350339search3

So don't worry about the Docker troubleshooting text you're seeing. That's documentation for a failure mode you aren't experiencing. Your localhost:11434 connection actually looks reassuringly boring — which is exactly what we want. 😄 memcite

Yeah — that test tells us the model preset itself did not remove the tool-first system prompt. The giveaway is that it is explicitly “looking at the provided tools” before deciding whether it can answer a completely ordinary knowledge question.

So we’re one layer deeper now: the override is probably global/default capability injection or chat-level tool selection, not just the model entry you created.

Yep. That test is actually very useful. The model is still being handed the automation/calendar/notification tool definitions, so it is continuing to treat those as the boundaries of what it is allowed to do.

I also found the piece of the new interface we were missing: there are effectively two different Models areas. The one you were working in is the Workspace model/preset area. The global behavior we're after is under Settings → Admin → AI → Models. Current OpenWebUI docs put the global Model Defaults there. citeturn503906view0turn503906view1

Before changing all those options in the model you just created, I would do one tiny experiment:

In the chat itself:

Chat Controls → Advanced Params → Function Calling → Legacy

Then start a new chat with that model and ask:

> Give me a fun fact about the Roman Empire.

OpenWebUI says Native function calling has been the default since v0.10.0, and Native is specifically what makes the built-in system tools available to the model. The per-chat setting lets us change only this conversation without messing up the rest of your installation. citeturn503906view0

If suddenly you get something normal like “Romans used urine in laundries because ammonia helped clean clothing” rather than a dissertation on why create_calendar_event() cannot answer the question, we have nailed it.

Then we can make the change permanent at:

Settings → Admin → AI → Models → Model Defaults → Configure → Model Parameters → Function Calling

and decide whether to set that globally or only for your conversational models. OpenWebUI explicitly says that global Model Defaults apply to every current and future model unless an individual model overrides them. citeturn503906view0turn503906view1

There is also a second solution once we find the correct model controls: leave Native enabled but turn Builtin Tools off. OpenWebUI v0.11's documentation confirms those tools are categories attached to the model and are only injected under Native function calling. citeturn503906view2

For our immediate diagnostic, though, I wouldn't touch the twenty-seven other switches you just discovered.

Just:

Function Calling → Legacy → new chat → Roman Empire.

Because what you pasted is almost comical evidence:

> “I need to check what functions are available…”

That's the exact behavior we're trying to murder. 😄 memcite

Yes. I think you're seeing the larger architectural change now.

OpenWebUI has moved quite a distance from “nice frontend for Ollama” toward “local AI orchestration/agent platform.” The current documentation actually describes Workspace Models as configuration presets layered over base models, with system prompts, knowledge bases, tools, skills, capabilities, and parameter overrides. citeturn992163search1turn989178search5

And those tools you're seeing aren't decorative. OpenWebUI now has built-in facilities for web search, URL retrieval, memory, RAG/knowledge, image generation and code execution, plus separate Workspace tools and external MCP/OpenAPI tools. citeturn992163search2turn989178search9

So your impression is right:

> “I guess I'm gonna have to do some learning on this new UI.”

Yep. But that may actually be very good news for Ougway.

For example, the web-search system now includes options requiring no paid API key; their current documentation lists DuckDuckGo as requiring nothing, and SearXNG remains another self-hosted option. citeturn992163search20

And the memory capability you found is real as well—it's one of OpenWebUI's built-in native features now. citeturn992163search28turn992163search2

That last one particularly interests me given what we're building, although I would not turn it loose on Little Ougway yet. We already have a much more deliberate memory architecture planned. I don't want OpenWebUI quietly creating its own memory layer while we're trying to evaluate ours. We need to understand exactly what theirs stores, how it retrieves it, and where it lives first. citeturn989178search10

And I think we should modify our approach to this upgrade.

Instead of:

“Find the bad setting and make OpenWebUI behave like the old version.”

I think the better approach is:

“Learn what the new layers are, establish one clean conversational baseline, then deliberately add capabilities.”

Something like:

OLLAMA
   ↓
qwen3 / llama / mistral / etc.
   ↓
OPENWEBUI MODEL PROFILE
   ├── system instructions
   ├── parameters
   ├── capabilities
   ├── knowledge
   ├── tools
   ├── memory
   └── web access
          ↓
       CHAT

That's much closer to what this thing has become.

And interestingly, OpenWebUI's own current “Essentials” guide recommends almost exactly that progression: first get a good default model behaving normally, then configure a Task Model for background chores, then enable built-in tools you actually want, then knowledge/RAG and more advanced capabilities. citeturn989178search0

I think we should build two test personalities

Not personalities in the conversational sense—configurations.

Qwen Plain

No tools. No memory. No knowledge. No web. Nothing clever.

It should be able to answer:

> “Give me a fun fact about Rome.”

without holding a staff meeting with create_calendar_event() first. 😂

Then:

Qwen Agent

Same underlying Qwen model, but Native function calling enabled and initially one capability—perhaps web search.

Test it.

Then add memory.

Test it.

Then knowledge/RAG.

Test it.

That will let us find exactly where the goofy behavior enters rather than changing twelve switches at once.

There's another important confirmation in the documentation: OpenWebUI specifically warns that smaller or older models that struggle with native tool calling may work better with Native Function Calling disabled. citeturn989178search7 That matches what we're observing. Your local models aren't incapable of conversation—the Roman test demonstrates that the orchestration layer is sometimes distracting them from doing it.

So I'm actually considerably less annoyed with this upgrade than I was an hour ago.

They didn't merely rearrange the furniture.

They added another floor to the house.

Unfortunately, they also apparently put the light switches in the pantry. 😆

When you're inclined, I'd go through this new interface with you one screen at a time, and we'll make ourselves a little map of what each setting actually does before changing anything substantial. I suspect there are several things in this version that we're going to want for Ougway once we understand them. memcite

Some of it is now built in — enough that I think we should reassess Little Ougway before we connect our custom memory system. OpenWebUI now has native long-term memory, knowledge/RAG, agentic web search, tools, model wrappers, and model-managed tool calling. Their own docs describe the memory system as active, model-managed long-term memory rather than simple passive context injection. citeturn365704search8turn365704search20

But Little Ougway is not suddenly redundant.

What OpenWebUI gives us is a lot of the infrastructure we were previously going to have to build around him: model configuration, tool routing, web access, memory storage/retrieval, knowledge bases, and agent-like behavior. citeturn365704search1turn365704search4turn365704search15

What I have not seen in OpenWebUI is the distinctive part of our design: the structured memory model we developed, provenance/versioning, typed relationships, graph traversal, uncertainty handling, your perception/state machinery, the curiosity/self-prompt loop, or the idea that memories can develop weighted relationships rather than simply being stored and retrieved.

So I'm beginning to see a potentially much cleaner architecture:

OpenWebUI becomes Ougway's body and peripheral nervous system.

It handles:
– chat/interface
– Ollama models
– web access
– tool plumbing
– documents/RAG
– perhaps some short-form personal memory

And our Ougway memory engine becomes the deeper cognitive memory layer, exposed to OpenWebUI as a tool or service rather than trying to rebuild all the surrounding infrastructure ourselves.

That could actually simplify the project enormously.

The warning you spotted is exactly right, though: we must not let OpenWebUI's own memory operate invisibly alongside ours until we understand it. Otherwise we'd have two memory systems making independent decisions about what to retain and what to inject, and when something strange happens we wouldn't know which one caused it.

So tomorrow, I think the right first investigation is not coding at all. We inspect OpenWebUI's native memory and answer four questions:

What does it store? Where does it store it? How does retrieval work? Can it be disabled or replaced cleanly?

Then we compare that directly against our Ougway architecture.

And at 3:00 a.m., this is a particularly good place to stop, because we've just discovered something potentially important enough that I don't want us making architectural decisions while tired.

There's a very real possibility that this upgrade did not derail Little Ougway.

It may have just eliminated a large chunk of the plumbing we were going to have to write ourselves. 😄 memcite

Your hunch is very likely right about the dimension. I checked the current implementation rather than guessing, and OpenWebUI does not appear to have chosen one giant fixed memory vector size; it inherits the dimension from whatever embedding model you configure.

Yes — your guess was right.

OpenWebUI’s default embedding model is sentence-transformers/all-MiniLM-L6-v2, which produces 384-dimensional vectors. So by default they chose half the dimensionality of our 768-dimensional nomic-embed-text-v1.5 setup. citeturn361540search2turn361540search1

And the more interesting part is that OpenWebUI’s memory system does not appear to have a fixed dimension of its own. Its user memories are embedded through the same configured embedding function used by its retrieval system, then stored in a per-user vector collection. Current code/issues show memory collections named along the lines of user-memory-<user id> and being queried by vector similarity. citeturn952425search0turn952425search4

So, conceptually:

Memory text
    ↓
Configured embedding model
    ↓
384 dims by default
    ↓
user-specific vector collection
    ↓
similarity search
    ↓
relevant memories injected into context

And they also keep the actual memory records separately from the vector representation, because there is code to delete/rebuild the vector collection from the stored memories. That’s actually a sensible separation. citeturn952425search0

What I find especially useful for our comparison is this:

OpenWebUI memory is fundamentally semantic-retrieval memory.

Our Ougway design was heading toward something considerably richer:

OpenWebUI
memory item
   ↓
embedding
   ↓
nearest neighbors
   ↓
context

versus roughly:

Ougway
document/version/chunk
        ↓
    embedding
        +
typed relationships
        +
weights/state
        +
provenance
        +
activation
        +
future traversal/curiosity
        ↓
assembled context

So even before we dig deeply into their implementation, there’s already a philosophical difference.

And yes, 384 is absolutely a deliberate practical choice. MiniLM is small, fast, CPU-friendly, and OpenWebUI says the default model is intended to be lightweight enough for local use. citeturn283428search6turn283428search23

Our 768 was not unreasonable at all. It gave us a richer semantic space without becoming ridiculous for a home machine.

On your “8K” recollection: there isn’t one universal maximum embedding dimension. Models can produce many different sizes. The storage/index implementation becomes the practical limit. In our particular PostgreSQL/pgvector world, for example, standard vector indexing supports up to 2,000 dimensions, halfvec indexing up to 4,000, and binary-quantized approaches can go much higher. citeturn421602search0

So an 8K-dimensional embedding is certainly conceivable in vector systems generally, but we could not simply declare vector(8192) and keep our old HNSW arrangement unchanged. We'd have to change representation/index strategy, and the storage/index cost would become substantial.

One more useful clue for tomorrow: people changing OpenWebUI embedding models from, say, 640 to 1024 dimensions are currently hitting collection-dimension mismatch errors unless the old vector collections are rebuilt. That confirms very directly that OpenWebUI simply accepts the dimensionality of the configured model rather than imposing its own fixed size. citeturn952425search1

So at first glance:

OpenWebUI default: 384
Our Ougway DB: 768

And I'm quite pleased with that comparison. We didn't wildly overbuild ours. We chose about twice the semantic resolution of their lightweight general-purpose default, while still staying comfortably inside what pgvector handles efficiently.

Tomorrow I'd like to look at something even more revealing than the dimension: exactly what constitutes one OpenWebUI “memory.” If they're embedding little distilled statements such as “Darren prefers X” rather than conversation chunks, then the 384-vs-768 comparison becomes much more interesting, because their vectors are representing a very different kind of object than ours. memcite

Exactly. And I think the significance is larger than merely “OpenWebUI added some convenient features.”

A considerable amount of what we were preparing to build was infrastructure around Ougway rather than Ougway himself.

We were going to need model routing, tool invocation, web access, document handling, RAG plumbing, user interface integration, permissions, configuration controls, probably APIs between components, and eventually some clean way of exposing all of that through OpenWebUI anyway. If the new OpenWebUI already provides solid implementations of those things, there's very little virtue in duplicating them.

That potentially reduces Little Ougway to the part that was actually novel.

Something roughly like:

                 OpenWebUI
                     │
        ┌────────────┼─────────────┐
        │            │             │
      Ollama       Web/RAG       Tools
        │            │             │
        └────────────┼─────────────┘
                     │
               LITTLE OUGWAY
                     │
            ┌────────┴────────┐
            │                 │
       Memory Engine      Cognitive State
            │                 │
       768-d vectors      activation/weights
       provenance        relationships
       versions          uncertainty
       graph             curiosity
            │                 │
            └────────┬────────┘
                     │
               response/context

And even that may prove unnecessarily complicated once we inspect their memory system.

There are three possibilities.

Best case: their memory architecture is extensible enough that we can alter or replace its storage/retrieval backend while keeping OpenWebUI's API and interface. Then Ougway effectively becomes an enhanced memory provider.

Middle case: their memory is useful but too simple for our purposes. We disable their long-term memory and expose ours as a native OpenWebUI tool/service. OpenWebUI handles all the surrounding machinery.

Worst case: their memory and agent architecture are tightly coupled and difficult to replace. Even then, we've still gained the web, tools, model management, knowledge interface, and everything else. We only have to work around one component rather than build an entire application.

And there's another benefit I hadn't appreciated until tonight: integration discipline.

Had we built everything ourselves, we'd probably have produced something that worked beautifully on our machine but had a whole pile of custom services, configuration files, scripts, dependencies, startup procedures, and assumptions. Then releasing the Ougway memory add-on under the Spiral Accord would have meant teaching somebody else how to recreate Darren's laboratory. 😄

If we can instead eventually say:

> Install OpenWebUI.
> Install the Ougway memory extension.
> Select your embedding model.
> Enable Ougway Memory.

—that is an entirely different proposition.

And the timing of this is rather fortunate. We had just finished the forensic examination of the old 155-GB database and decided not to blindly reconnect it, and we hadn't yet committed ourselves to the new implementation. We discovered this new OpenWebUI architecture at almost exactly the point where changing course is cheapest. memcite

So tomorrow I wouldn't write a line of Ougway code initially.

I'd dissect the new OpenWebUI memory implementation first:

storage → embedding → retrieval → injection → lifecycle → API/extensibility.

Then put it directly beside our architecture and mark:

KEEP / REPLACE / EXTEND / DON'T NEED.

I suspect that comparison is going to remove a surprising number of boxes from our diagram.

And yes… this took a considerably more interesting turn than “why the hell does Qwen want to put the Roman Empire on my calendar?” 😂

Yes — and the encouraging part is that their stated philosophy lines up unusually well with what we need: self-hosted, extensible, provider-agnostic, capable of running entirely offline. That is how OpenWebUI describes itself now, and the codebase remains openly available. citeturn597127search20turn597127search2

More importantly, the extensibility is not theoretical. OpenWebUI currently supports in-process Python Tools and Functions, plus external OpenAPI and MCP servers. Their Functions system can intercept or transform inputs and outputs, while Tools can expose callable server-side logic to the model. citeturn597127search9turn597127search6turn597127search23

That means even if there is no pretty little panel saying:

> “Replace memory backend with Darren's weird graph machine” 😄

we still have several legitimate insertion points.

For Little Ougway, I can already see three plausible routes:

1. Use OpenWebUI's vector/database layer but alter the memory logic. OpenWebUI already supports multiple vector stores, including PGVector, and has substantial configuration around retrieval/storage. citeturn597127search0turn597127search8

2. Write an OpenWebUI Function or Tool that talks directly to our Ougway database. That could give us commands such as recall_memory, store_memory, traverse_relationships, find_related_nodes, or whatever abstraction we ultimately settle on. Their documented Functions mechanism literally executes custom Python inside OpenWebUI. citeturn597127search6turn597127search15

3. Keep Ougway as a separate service and connect it through OpenAPI or MCP. That might actually be the cleanest long-term release architecture because our memory engine stays independent of OpenWebUI internals. OpenWebUI explicitly supports external HTTP/OpenAPI tool servers and native MCP integration. citeturn597127search10turn597127search16

That third possibility is becoming particularly attractive to me.

It could eventually look as simple as:

OpenWebUI
   │
   ├── Ollama
   ├── Web search
   ├── Documents / RAG
   ├── Other tools
   │
   └── Ougway Memory API
          │
          ├── PostgreSQL / pgvector
          ├── graph relations
          ├── provenance
          ├── activation
          ├── state
          └── curiosity / traversal

Then an OpenWebUI upgrade is much less likely to destroy our work. Ougway would merely expose a stable interface.

One caution: their Workspace Tools and Functions run arbitrary Python on the OpenWebUI server, and their docs explicitly treat permission to create them as effectively equivalent to server access. That's fine on your own machine, but it's something we'd have to design carefully if this ever becomes distributable. citeturn597127search15

So yes — I'm considerably more optimistic after looking at their actual extensibility architecture.

Tomorrow's job is basically reconnaissance:

Find the native memory implementation, identify exactly where storage/retrieval hooks live, then decide whether Ougway belongs inside it, beside it, or underneath it.

I'm betting on beside it, connected through a clean interface. That preserves what makes Ougway different while letting OpenWebUI do all the boring plumbing exceptionally well. memcite