AnythingLLM used to want a second program. You ran the app in a container, you ran Ollama beside it, and then you pointed one at the other. Version 1.19.0, published on 26 October 2026, puts a model engine inside the container and makes that second program optional.
Start with the caveat, because it decides what this is worth. This is an assessment, and it is desk research. AnythingLLM does not run in my lab, so nothing below is a measurement of mine and I have not booted the image. What I read was the vendor’s own release note for 1.19.0, the Lemonade project’s site, its repository and the AnythingLLM repository. The vendor’s setup page answered my browser with a 403, so the detail here comes from the release note, which is the primary document anyway.
What actually shipped
The engine is Lemonade, which the note describes as AMD’s fully open-source local model server. It is Apache-2.0, it sits at 6,004 stars on GitHub, and it runs models through llama.cpp underneath. AnythingLLM itself is MIT and 67,622 stars.
The engine is off until you ask for it. Set -e ENABLE_BUILT_IN_LLM=true to turn it on, then add --gpus all if you want it to use the card.
Once it is on, the app picks a backend by itself. It takes CUDA on an NVIDIA card, Vulkan on AMD and Intel, and the processor when there is nothing else. Both x86 and ARM hosts are covered, so a small board is not left out.
On the first run, Built-in becomes the default provider, with 3 models suggested for the hardware it finds. You can pull any GGUF file from Hugging Face. The engine then shows up anywhere a provider can go, such as the system model, workspace and agent models, the chat picker, and Model Router. That range is the difference between a demo and a default.
The note is blunter than anything I would write. It says “You no longer need to run Ollama, LM Studio or any other inference server next to AnythingLLM.”
Why the second program was the hard part
Every self-hosted app is a chain. The chat app needs a model server, the model server needs a driver, and the driver needs a card it still recognises. Each link is a port, a version and a file of settings. Any one of them can break on a Tuesday, for reasons that have nothing to do with you.
I have set up enough of these stacks to know how that ends. The app starts, the model server starts, and then the two disagree about a CUDA version. The evening goes into a log file, and the person who wanted a private chat window over their own notes goes back to a web tab. That is not a guess, because the pattern is old and I have been the person in the log file.
So the interesting number in this release is not a token rate. It is the count of services, where 2 becomes 1. Someone who would have quit at the second install now has one thing to run, one to update and one place for the logs to land. That is a smaller claim than a faster model, and it is worth more to more people.
What the vendor got right
Three things deserve credit, and they are worth saying before the objections.
First, the engine is off by default. Nothing arrives on your disk just because you pulled an image, so the model files and the card time stay your decision. A vendor that switched this on by default would be spending your electricity to make its own first screen look clever.
Second, the engine is a separate open-source project and not a black box inside the app. Lemonade is Apache-2.0, it reads GGUF files, and those files are the ones every other local engine reads. So what you lose is the choice of server, not the choice of model.
Third, the note leaves the old road open. Ollama is still a provider, and the same list carries a fix for Ollama losing context windows when a model lookup fails. Nothing was taken away here. A step was removed from the front of the queue.
What a built-in engine costs you
The trade is control.
An engine that ships inside the app now moves on the app’s release cycle. If a new llama.cpp brings a speed-up for your card, you get it when the next app version lands. The version you can pin is the app’s, not the engine’s.
A default is also a decision made on your behalf. Someone on their first run gets 3 models and a provider already set. That is the right call for the first evening, because they have nothing to compare it to. It is also how a default turns into a habit, and a habit into a thing you never check again.
Then there is the note’s claim that the engine is “accelerated on whatever hardware you have”. That is honest, and it is also a lowest common answer. Vulkan on an AMD card is the sane default, and it is not the fastest path on every card. A tuned box still beats it, and the person who tuned the box knows that.
None of this is a defect. It is what a default is.
The fixes nobody will read
The same release carries 2 safety fixes, and both deserve more of your attention than the new engine.
One caps the size of a request body, which closes a hole where someone with no login could make the app do work until it stopped answering. The useful word there is “no login”, because the attack did not need an account.
The other strips spreadsheet formulas out of CSV chat exports. A cell that starts with an equals sign is a small program, and a CSV of your conversations is full of text you did not write. Open that file in Excel and the formula runs. The trick is old, cheap and boring, which is why it keeps working.
Both fixes arrived in a dot release, in the same list as a colour palette. That is the shape of most safety work. There is no press release and no demo, just 2 lines near the bottom. It is also the best reason to update, and it is why “it runs locally” does not mean “it is safe”. A local app still has bugs, an open port and a browser in front of it.
Where this is going
Desktop builds already carried an engine, so the container was the last place this had not reached. The 1.16.2 release from 22 September bumped a bundled Ollama runtime to 0.33.3, which shows the app has shipped model runtimes before. What is new is that the container now carries one, and that one is Lemonade.
Expect the same move from the rest of the self-hosted apps that still open with “install the model server first”, because that step is where their users leave.
Expect the model choice to become a menu inside the app, and expect the app’s release to become the moment your engine changes. Within a year I would bet that “which model server” is a question only people with opinions ask, and everyone else takes what shipped. The longer argument about why the file outlasts the server is in this piece on who pays for the compute.
The version of that future worth worrying about is an engine that only accepts the vendor’s list. The note says any GGUF, which is the right answer, and it is the part to watch when the next version lands. A list that quietly narrows is how a local app becomes a rented one with extra steps.
What I would do
If I were setting this up for the first time, I would take the built-in engine. One container, one log, one version to update, and the model files stay on my disk where I can move them. That is a good first evening, and the note is right that the second server was never the interesting part.
For the rack I already run, I would not. I have an engine I chose, sized for the card in it, and able to move when a new build lands. Trading that for one that ships with a chat app’s release cycle is trading control for an hour I do not need to save. This is a good release, and it is not aimed at me.
So the verdict is narrow, and I will say it plainly. This is the best thing in 1.19.0, and it is a convenience rather than a principle. The flag you set today is easy. The question is the release after next, when the engine changes under you and the note calls it a fix. Sovereignty was never about who wrote the server. It is about who decides when it changes, and on this release that decision belongs to a version number you do not set.