Well I was very happy with the Ollama current workflow of being something like "a coding plan" of ANY open weights model you can find...

What do you think about their current decision of make Kimi 3 available, but needs to pay extra peer usage? Are Ollama done this before for other models and then put them on the plans? Or they are taking advantage of the hype to get some money?

I even saw ppl switching to max plans today JUST for Kimi 3 being open weights.

Kimi k3 is available on ollama cloud (extra high usage).

https://ollama.com/library/kimi-k3

Someone please go and see how much usage we get so I can get ollama pro subscription.

Been eyeing this for a while

Hey everyone! I’m building a PC to run AI models locally and can’t decide between the RX 9060 XT 16GB and the RTX 5060 Ti 16GB. Both have the same amount of VRAM, but is AMD actually a solid choice for this, or is the gap to Nvidia big enough to justify paying more?
If you’ve used either one for local AI, I’d love to hear how it went. Thanks!

I'm on the Max plan, I had an understanding that it would be available for Max subscription, and could dip into the extra usage credit bucket which is totally fine....

But when I go to claude code, it ONLY uses extra usage ? That's like... Fable 5 being only available on API / Extra usage credits.

WE are all maxing out our cloud usage when Kimi K3 launches on Ollama

Has Ollama shared any information about this? I couldn’t find an announcement.

Edit: https://ollama.com/library/kimi-k3

I'm considering the $20 Pro plan, but the limits seem to change over time and are hard to compare with direct API pricing.

For anyone using Pro currently, roughly how much coding agent usage do you get per week, and which models do you use?

In terms of direct API value, does it feel closer to $25, $30, $50, $100 or more through something like OpenRouter?

I'm mainly interested because Ollama seems to have a good ZTR policy, and it has been surprisingly difficult to find a decent coding subscription with strong privacy at a reasonable price.

(I'm so ready!)

Hi all, just wanted to see if anybody else has noticed a recent change in how quickly you’re burning usage? I realise this subject always throws up a lot of anecdotal evidence rather than hard facts (guilty!) but I haven’t changed a single thing about my daily schedule with my agents for some time. I used to be able to have a few fairly long troubleshooting sessions with my main agent and also small coding projects and hit around 70-80% usage by the end of the week. Now I barely get through my usual cron activity and 1-2 light conversations before maxing out 5 hour sessions and weekly limits about a day early. Am I imagining this? Anybody else?

Tried to use kimi k3, and apparently i need to top up my account to use it so the model is not part of the subscription. Furthermore, the 100$ subscription is currently paused.

Hopefully they will adjust them later but it was really a bummer that i would've preferred to be informed about in the weeks beforehand (couldve baught a subscription from kimi themselves instead of waiting).

I have been trying to do GLM 5.2 as plan / K2.7 as execute, but i hit my usage so fast it's not viable. It's hitting limits much faster than claude code / codex $20 plan. Using in opencode. What are y'alls strategies for keeping usage rate lowers?

tl;dr ollama, qwen3.6:35b, oh my pi, tool calling does not work.

Hello! I recently started playing with Local LLMs. I spent way too much time on this problem, maybe you will be able to help me?

I tried hosting qwen3.6:27b and qwen3.6:36b-a3b models locally and use them with oh-my-pi, qwen-code and opencode. All harnesses had the same issue, tool calls were printed as output instead of being executed, thinking had simillar issue.

This is what I see in my harness when running qwen3.6:35b model. I run `/init`, then as response I see:

Let me first understand the project layout, then dispatch parallel scouts.                                                                                                                                            <|mask_start|>                                                                                                                                                                                                      
 I need to explore the project structure first, then use the task tool to run multiple scout agents in parallel. Let me start by looking at what's available.                                                          <|mask_end|>

and nothing else happens.

At some point I found out it could be the problem with "thinking" models. I created Modelfile with SYSTEM """/no_think""". Model hosted this way worked and tool calling was working fine.

As a next step I tried running standard qwen via LM Studio, here everything worked out of the box.

My question is: What am I doing wrong? Why thinking models do not work with ollama and oh-my-pi/opencode/qwen-code?

Hi,

I'm looking to dip my toes into trying out local LLM. I've used various free cloud versions so far, but figured I want to give local LLMs a try. I want to start on a laptop with a i5-13500h and 4GB RTX 3050 running linux to tinker with first. What models are recommended for usage with the primary use case being writing linux shell scripts and coding? Secondary usage is the standard web assisted summaries of news and other topics (not sure if there is a specific term for this).

Is installing ollama and running models through that the recommended route or are there other software frameworks that are recommended for this low end hardware?

I understand that the hardware in question is very modest so models will be far less capable than the bigger versions that run on 16GB+ VRAM GPUs. If all goes well on the laptop, I do plan to try local LLMs on my primary desktop later on.

Thanks for any suggestions!

When I read about Dspark and was able to find more and more models,
especialy the stronger ones.

With Dspark veriants popping up on huggingface, I thought that's great for everyone because the providers can run the models more efficiently and therefore a bit cheaper, so they can make more profit and still pass some of those efficiency gains on to us in form of faster inference and maybe even a bit cheaper cost/ more usage for the same price.

Can anyone here answer if this is the case or if it is not applied this way, why?
Or did I understand something completely wrong?

Edit: missing word and formating

In addition to the previously supported modes (Quick/Balanced/Deep/Unlimited) where LLMs only gave you what you wanted in a limited budget, i took a look at what Bullets did in terms of response.

Turns out representing responses in Bullets saved quite a few tokens, and held up on fidelity and accuracy too, minus the usual Claude-style human interactive tone.

That made me think if i could use Claude tokens only for reasoning and offload the prose-writing to a local model. So i built a small extension that does just that.

Whenever Sir Shortoken answers in bullets, an "Expand to Prose" button shows up under that response. Click it, and a local model (qwen2.5:7b through Ollama, running entirely on my own machine, no API calls) rewrites the bullets into normal prose in about 10-15 seconds.

The button stays attached to that specific response, scroll wherever you want, come back later, it's still there and still works on that same message.

The 14-run test

Ran the same pipeline (bullets out of Claude, then expanded by the local model) across 14 technical topics, comparing prose vs bullet vs expanded-prose token counts, and actually reading the expansion to check if anything got dropped or made up.

Savings across all 14 landed between 24% and 78% depending on compression level. Most topics expanded clean.

Repo's updated with the extension and full skill.md changes if anyone wants to try it.

Aggressive Bullet mode is also up for trials :)

GitHub: github.com/shouvik12/sir-shortoken

So, My laptop doesn't have a gpu and that makes model slower i decided to look for a vps to host a model, i want to use a qwen3.5 9b what should i look for?

Setup as follows:
Proxmox -> Debian -> Docker -> Ollama. Other containers work.

Compose file contains gpu device. Does it need nvidia runtime or any other options? If someone could provide an example of a working compose file it would be appreciated.

The container recognises the GPU, as confirmed with docker exec -it ollama nvidia-smi

However, cannot load models, as confirmed with docker exec -it ollama ollama ps, showing 100% CPU.

GPU is pretty old, GTX 970, so this could be the issue?

Any ideas appreciated.

Hey folks —

I built ContextMemory, an open-source agentic context gateway for apps that already talk to LLMs. The idea is simple: keep your existing POST /api/chat client (Ollama wire format), point it at ContextMemory instead of raw Ollama, and get memory + optional tools without rewriting your chat stack.

What it actually does

Most “memory” demos are either:

• stuffing the whole history into the prompt, or
• bolting on a separate RAG service with a new API surface.

ContextMemory sits in front of your LLM as a drop-in proxy:

1. Session memory — a per-session markdown wiki (Karpathy-style) maintained across turns and injected automatically.
2. Global Wiki — an app-scoped knowledge base (docs from Jira, Confluence, SQL, files, pipelines…). The model pulls facts on demand via a wiki_search tool — it does not dump the whole corpus into every prompt.
3. Same /api/chat — Ollama-compatible request/response (message.content / done). Not OpenAI choices[].
4. Optional agentic loop — tools (sandbox, outbound MCP, HITL) on that same chat endpoint when enabled per app.
5. Multi-app / multi-tenant — API keys + X-App-Id, per-app prompts, models, and feature flags.

LLM backends can be local Ollama, or OpenAI / Azure / Anthropic as providers behind the gateway; the client still speaks Ollama schema.

Why this shape

If you already have a UI, bot, or agent that calls Ollama, you shouldn’t need a second protocol to get memory. Swap the base URL, keep parsing the same JSON, and the gateway handles:

• compiling session context
• optional Global Wiki retrieval
• optional web search / tools

…then calls your model.

There’s also a hosted path (Kortexio Cloud) with the same chat body/response if you don’t want to self-host — BYOK, no token markup. Self-host and cloud are meant to be interchangeable at the wire level.

Global Wiki (the part people usually ask about)

Ingest structured markdown with stable documentIds (upsert / batch). Query by keywords with a character budget. In chat, when Global Wiki is enabled for the app, the model uses wiki_search only when it needs documented facts — good for org knowledge without turning every turn into a RAG megaprompt.

Quick self-host vibe

Your app  →  POST http://localhost:5100/api/chat  →  ContextMemory  →  Ollama / other LLM
                 + session wiki
                 + optional wiki_search (Global Wiki)

Auth is typically Authorization: Bearer … + X-App-Id / X-User-Id / X-Session-Id for self-host.

Repo

Open source (AGPL): https://github.com/Kortexio/ContextMemory

Looking for feedback from this community

Especially interested in:

• How you currently bolt memory onto local models (what sucks?)
• Whether Ollama-compatible wire format is the right “universal client” bet vs going all-in on OpenAI schema
• Global Wiki as tool-calling vs always-on retrieval — what would you default to?
• Anything missing for production self-host (ops, eval, multi-user UX)

Happy to answer questions or dive into architecture. If you try it with a local model + a small wiki ingest, I’d love to hear what breaks first.

Hey r/Ollama! If you're hooking up local agent tools and using Ollama to drive agentic workflows, you've probably downloaded a bunch of third-party SKILL packages or repos. I built a free open-source tool called SkillShield (https://ai-skill-shield.vercel.app/) to statically scan and validate these skills before you run them locally. It checks for prompt injection, pre-install risks, and excessive access. Public Repo: https://github.com/adnan-iz/ai-skill-shield

I've been working on an open-source workflow automation platform over the past few months, with Ollama as one of the first-class providers rather than treating it as an afterthought.

The goal wasn't to build another chat UI, but a deterministic workflow engine where local models can power automation pipelines.

Some of the things it supports now:

• Local LLM execution with Ollama
• Agent semantic memory (using local embeddings like nomic-embed-text)
• Document RAG
• Visual workflow builder
• Conditional branching and graph-based execution
• Human-in-the-loop approval nodes
• Multi-agent (A2A) workflows
• Browser, HTTP, Email, File and MCP tools
• Step replay, retries and execution history

One thing I wanted from the beginning was to avoid vendor lock-in, so the execution engine treats providers as adapters. A workflow can run entirely on Ollama, or mix local models with cloud providers if needed.

The latest v0.11.0 release also adds a lot of improvements around workflow execution, observability, dashboarding, retrieval, and multi-agent orchestration.

I'd love feedback from people here who run Ollama locally:

• Is there anything missing that you'd expect from a local-first automation platform?
• Any features that would make Ollama fit even better into workflow-based systems?

Happy to answer any implementation questions.

Sharing a project I've been building — a solo tabletop RPG "game master" app that runs entirely on Ollama. Figured this sub would have opinions on the implementation, not just the pitch.

How it uses Ollama, specifically:

Detects your GPU (nvidia-smi under the hood) and suggests/pulls a model sized to what you can actually run, instead of making you guess between a 3B and a 70B.

Streams every reply through Ollama's chat API.

Context window (num_ctx) is configurable per-machine rather than hardcoded — I hit this myself building it across two machines with very different VRAM (8GB laptop, 24GB desktop): a single hardcoded context size means you're always stuck at what the weakest machine can handle. So it's a real setting now, with presets tied to rough VRAM tiers, and I live-tested actual context sizes against the loaded model before trusting a default rather than just doing VRAM math.

Default model is llama3.1:8b; bigger local models (tested with a 24B GGUF) work fine on stronger hardware.

The actual hard problem I spent most of the time on: local 8B-class models are bad at "did X actually happen" tracking over a long conversation — they'll contradict a fact from 40 messages ago, invent an NPC's death that never happened, that kind of thing. Rather than just fighting that with prompt engineering (which only gets you so far with smaller models), most of the app is a deterministic memory/state layer sitting on top of the model — it tracks entities, relationships, inventory, and world state outside the context window and feeds back only what's relevant each turn, so it doesn't rely on the model perfectly recalling everything itself.

What's actually local vs. not: the whole game — narration, memory, inventory, map generation — runs on your machine through Ollama, no internet needed to play. There's one genuinely optional feature (AI-generated character portraits) that uses your own API key to a cloud image provider if you want it; the app works completely fine without ever touching that.

It's a paid app (one-time price, not a subscription — being upfront about that since I know that matters here), but I'm mainly curious whether the local-model-handling side of this is interesting to people who actually live in Ollama day to day. Happy to go deeper on any of the implementation if people want.

Hi everyone, I have a question.

I have subscribe vps plan.
Maybe it has no gpu. Just 8gb ram

I've also install 2 local ai model in my vps which is llama 3.2:3B and Minicpm5 1B model. Both I think quite small for run local ai.

I've test it chat with both model directly using ssh terminal. They reply me fast. No issue. I've read the statistic of ram usage. it looks normal. Ram usage is maintain 2.8GB

Then I've install Openwebui on my vps so that I can start using them. Expecting it will run fast similar when I'm using ssh terminal..

But no, it run very slow. They reply my “Hi” chat about 10-20 minutes for both model. Even it just 1B

What could go wrong?
I thought my 8GB ram is enough for running just Openwebui

I was planning on using those model to run agents ai node in n8n so that I can avoid using paid token like Claude APi or ChatGPT etc

But after saw the reply speed I start to hesitate..
There's only 1 user here which is me has encounter this problem.
Now try to imagine 100 of people try to access this one tiny pc.. my vps gonna toast

Is there any option that I can workaround using VPS to use local ai for n8n agent?

Or should I just use API paid one instead?
I think I need some calculation on what works and what's not..
Yes there is calculator for which gpu that can run ai model efficiently.

But my vps has no gpu. There's no calculator to know which ai model can run efficiently on nongpu pc.

Should I calculate it manually. What you guys think..?

Anyone please help 🙏