TL;DR: Accord GPU is an open beta coordination layer for Windows that stops GPU-heavy creative apps from fighting each other for VRAM. If DAZ Studio, Blender, ComfyUI, or Ollama have ever crashed or OOM'd because something else on the machine grabbed the GPU first, this is built to prevent that.

The primary user base is intended to be creative professionals who frequently run multiple tools on the same system and have to micromanage which apps and jobs are allowed to run on the GPU. A proper system-wide queue for access to the GPU unlocks dramatically higher productivity and keeping the GPU running much more often.

The problem

GPU renderers, image/video generators, and local inference servers all assume they have exclusive ownership of the GPU. Run two of them at once, or even back to back before VRAM actually clears, and you get CUDA OOM crashes, driver resets, or corrupted output. There's no coordination layer between separate applications today, so people end up manually babysitting which app gets to touch the GPU and when.

How it works

A central hub app (Console) runs in the system tray and every plugin talks to it over a local named pipe.

When a component starts GPU work, it writes a small JSON "ticket" to a shared local folder. Every component joins a shared queue and pauses its jobs until the GPU is free.

GPU telemetry (VRAM, utilization, temps) is shown on a convenient appbar you can dock to any edge of any monitor. The queue of jobs appears here so you can see which app is active and what's coming up next.

Coordination is automatic once installed if you use the Accord controls. Kick off a DAZ or Blender render, queue a ComfyUI job or any inference through Ollama, and it waits its turn instead of fighting for the card immediately.

What's available right now (all free during open beta)

• Accord GPU Console - the hub, always installed, manages the queue and GPU telemetry
• Accord for DAZ Studio - a native DAZ plugin that adds a pane you can place wherever you like in your DAZ window setup
• Accord for Blender - a native Blender addon that adds a tab to the N-panel, plus a settings tab
• Accord for ComfyUI - an extension that replaces the Comfy queue with Accord-enabled queueing, and its own settings tab
• Accord for Ollama - a transparent proxy that sits in front of Ollama's API to intercept traffic and help govern behavior like sending inferences into Ollama and when to evict a loaded model
• Accord PRO - additional features that add job history including run time per job, priority rules to put different apps, renders or custom fields first in the queue, Windows power action controls when the queue runs dry, multi-GPU support and more

Roadmap

Accord GPU gains value as it covers more of the applications that heavily utilize your GPU. Which of those ships first is decided by community vote, not internal guesswork - if there's an app you want covered, go add your vote: https://accord-gpu.com/roadmap

Try it

Everything is free and no accounts are required while the open beta runs, PRO features and plugins included. Installer's here: https://accord-gpu.com/download

Accord For ComfyUI features

• Queue survives crashes and restarts - Accord holds your pending jobs in its own store on disk, not in ComfyUI's memory. If ComfyUI crashes we'll restart it for you, and keep your job list alive if we could get it back quickly. Only the one job mid-execution is lost - nothing else.
• Runs without a browser - Once your workflows are queued, Accord manages execution through ComfyUI's server API directly. Close the tab, let the display sleep, go to bed - your generations keep running with no browser connection required.
• Shared GPU queue - ComfyUI workflows join the same queue as Blender and DAZ Studio. Your generation starts only when the GPU is free - and other Accord-enabled apps wait while it runs.
• Thermal protection - Before promoting a job, Accord checks GPU temperature. Configurable warning and critical thresholds pause the queue when the card runs too hot and resume automatically once it cools - protecting hardware during long overnight batches without any manual intervention.
• Error alerts - If too many jobs fail within your configured window of time, Accord pauses the queue and flags the problem in your notifications. No more waking up to discover ComfyUI silently failed 20 jobs in a row on the same broken node.
• Job complete notifications - Windows toast notification when each job completes or the full queue empties. Turn on a sound to play when it finishes, and loop it if you want. Know the moment your generation is done - whether you are at your desk or across the house.
• GPU telemetry widget - VRAM usage, temperature, and GPU utilization displayed directly in the ComfyUI actionbar. The widget lives alongside the queue controls and updates live every few seconds so you can see GPU state at a glance without leaving the interface.
• VRAM eviction between jobs - If configured, after each generation completes, Accord force-evicts loaded models from VRAM before the next app can claim the GPU. Whatever is waiting in the queue - Blender, DAZ, another workflow - starts with a clean card. Turn it off if you prefer faster job-to-job transitions within a single ComfyUI batch.

TL;DR: Accord GPU is an open beta coordination layer for Windows that stops GPU-heavy creative apps from fighting each other for VRAM. If DAZ Studio, Blender, ComfyUI, or Ollama have ever crashed or OOM'd because something else on the machine grabbed the GPU first, this is built to prevent that.

The primary user base is intended to be creative professionals who frequently run multiple tools on the same system and have to micromanage which apps and jobs are allowed to run on the GPU. A proper system-wide queue for access to the GPU unlocks dramatically higher productivity and keeping the GPU running much more often.

The problem

GPU renderers, image/video generators, and local inference servers all assume they have exclusive ownership of the GPU. Run two of them at once, or even back to back before VRAM actually clears, and you get CUDA OOM crashes, driver resets, or corrupted output. There's no coordination layer between separate applications today, so people end up manually babysitting which app gets to touch the GPU and when.

How it works

A central hub app (Console) runs in the system tray and every plugin talks to it over a local named pipe.

When a component starts GPU work, it writes a small JSON "ticket" to a shared local folder. Every component joins a shared queue and pauses its jobs until the GPU is free.

GPU telemetry (VRAM, utilization, temps) is shown on a convenient appbar you can dock to any edge of any monitor. The queue of jobs appears here so you can see which app is active and what's coming up next.

Coordination is automatic once installed if you use the Accord controls. Kick off a DAZ or Blender render, queue a ComfyUI job or any inference through Ollama, and it waits its turn instead of fighting for the card immediately.

What's available right now (all free during open beta)

• Accord GPU Console - the hub, always installed, manages the queue and GPU telemetry
• Accord for DAZ Studio - a native DAZ plugin that adds a pane you can place wherever you like in your DAZ window setup
• Accord for Blender - a native Blender addon that adds a tab to the N-panel, plus a settings tab
• Accord for ComfyUI - an extension that replaces the Comfy queue with Accord-enabled queueing, and its own settings tab
• Accord for Ollama - a transparent proxy that sits in front of Ollama's API to intercept traffic and help govern behavior like sending inferences into Ollama and when to evict a loaded model
• Accord PRO - additional features that add job history including run time per job, priority rules to put different apps, renders or custom fields first in the queue, Windows power action controls when the queue runs dry, multi-GPU support and more

Roadmap

Accord GPU gains value as it covers more of the applications that heavily utilize your GPU. Which of those ships first is decided by community vote, not internal guesswork - if there's an app you want covered, go add your vote: https://accord-gpu.com/roadmap

Try it

Everything is free and no accounts are required while the open beta runs, PRO features and plugins included. Installer's here: https://accord-gpu.com/download

Accord For Ollama features

• Transparent proxy - no client changes - Accord installs as a Windows Service and listens on Ollama's default port. Open WebUI, LM Studio, scripts, and any other Ollama-compatible client connect to Accord without any reconfiguration. Accord forwards every request to Ollama unchanged.
• Smart VRAM eviction - Ollama releases the GPU exactly when you need it to. Loose (default) watches VRAM and evicts when an external process starts competing. Tight evicts when another Accord-managed render job is waiting in the shared queue. Immediate clears VRAM after every inference regardless. Off leaves Ollama's built-in hold behavior untouched.
• VRAM headroom reservation - Accord instructs Ollama to treat a configurable buffer of VRAM as unavailable. Brief spikes from Windows, monitoring tools, or another process can push an otherwise-fitting model into OOM territory. The buffer absorbs those spikes before they reach your inference.
• Shared GPU queue - Every Ollama inference joins the same queue as Blender renders, DAZ Iray jobs, and ComfyUI workflows. Your inference runs only when the GPU is free, and other Accord-enabled apps wait their turn while it does.
• Zombie runner auto-recovery - After every eviction, Accord briefly polls Ollama's process list to confirm the model's runner actually exited. If it is still listed after 5 seconds, Accord restarts the Ollama process to forcibly reclaim the held VRAM. No manual intervention required.
• Runaway inference watchdog - Set a maximum inference duration. If a generation is still streaming tokens past that ceiling - a model in a repetition loop, or a prompt gone sideways - Accord kills and restarts Ollama and retries the request. The queue keeps moving.
• Hang detection and auto-restart - If Ollama stops responding mid-inference - no tokens, no error, just silence - Accord detects the hang, kills and restarts the Ollama process, and replays the request. One failed attempt, then Accord surfaces the error to the client.
• Single-model VRAM enforcement - Ollama's default allows it to keep up to three models warm in VRAM at once. Accord configures it to hold only one, so model B cannot quietly load next to an un-evicted model A and double your VRAM usage between jobs.

TL;DR: Accord GPU is a free, open beta coordination layer for Windows that stops GPU-heavy creative apps from fighting each other for VRAM. If DAZ Studio, Blender, ComfyUI, or Ollama have ever crashed or OOM'd because something else on the machine grabbed the GPU first, this is built to prevent that.

The primary user base is intended to be creative professionals who frequently run multiple tools on the same system and have to micromanage which apps and jobs are allowed to run on the GPU. A proper system-wide queue for access to the GPU unlocks dramatically higher productivity and keeping the GPU running much more often.

The problem

GPU renderers, image/video generators, and local inference servers all assume they have exclusive ownership of the GPU. Run two of them at once, or even back to back before VRAM actually clears, and you get CUDA OOM crashes, driver resets, or corrupted output. There's no coordination layer between separate applications today, so people end up manually babysitting which app gets to touch the GPU and when.

How it works

A central hub app (Console) runs in the system tray and every plugin talks to it over a local named pipe.

When a component starts GPU work, it writes a small JSON "ticket" to a shared local folder. Every component joins a shared queue and pauses its jobs until the GPU is free.

GPU telemetry (VRAM, utilization, temps) is shown on a convenient appbar you can dock to any edge of any monitor. The queue of jobs appears here so you can see which app is active and what's coming up next.

Coordination is automatic once installed if you use the Accord controls. Kick off a DAZ or Blender render, queue a ComfyUI job or any inference through Ollama, and it waits its turn instead of fighting for the card immediately.

What's available right now (all free during open beta)

• Accord GPU Console - the hub, always installed, manages the queue and GPU telemetry
• Accord for DAZ Studio - a native DAZ plugin that adds a pane you can place wherever you like in your DAZ window setup
• Accord for Blender - a native Blender addon that adds a tab to the N-panel, plus a settings tab
• Accord for ComfyUI - an extension that replaces the Comfy queue with Accord-enabled queueing, and its own settings tab
• Accord for Ollama - a transparent proxy that sits in front of Ollama's API to intercept traffic and help govern behavior like sending inferences into Ollama and when to evict a loaded model
• Accord PRO - additional features that add job history including run time per job, priority rules to put different apps, renders or custom fields first in the queue, Windows power action controls when the queue runs dry, multi-GPU support and more

Roadmap

Accord GPU gains value as it covers more of the applications that heavily utilize your GPU. Which of those ships first is decided by community vote, not internal guesswork - if there's an app you want covered, go add your vote: https://accord-gpu.com/roadmap

Try it

Everything is free and no accounts are required while the open beta runs, PRO features and plugins included. Installer's here: https://accord-gpu.com/download

Accord For DAZ Studio features

• Spawn new instance - DAZ enforces a singleton by default. Accord adds a one-click button to launch a second instance - no manual profile copying.
• Queue across instances - Iray renders on multiple DAZ Studio instances are automatically queued and protected. If another app holds the GPU, DAZ waits its turn. No manual coordination needed.
• Auto-saving - When anything from a single frame to a multi-hour video render completes, save it instantly using your chosen name and codec. Your GPU is free to move on to the next queued item.
• GPU telemetry panel - VRAM usage, temperature, and utilization shown directly in the DAZ Studio panel before and during every render. Preflight protection can warn you if GPU usage is unsafe or the temperature is too high before you start.
• Multiple GPU uses - DAZ Studio calls on the GPU for both Iray renders and dForce simulations. Accord wraps both activities safely.
• Render type scope - Control exactly which render types participate in the queue. Iray is always protected. Viewport and OpenGL renders can opt in when you need them to.
• Render Queue capable - For DAZ Premier members, Render Queue job files can be loaded to the Accord queue. Each item is treated like a single job unit, allowing you to merge your existing workflows into a wider world of GPU coordination.
• Crash recovery - If your application crashes with Render Queue work left, Accord saves the work, restarts the application, and moves the queued items to the new process so you can continue where you left off.
• Render notifications - Windows toast notification and configurable sounds on render complete. Know the moment it finishes even from another room.

[Self-Promotion] Following the 1/10th rule. This is a promotional post for a paid tool that I released publicly today.

If you are running local generation and you use more than one model for different purposes, the time to reload a different model becomes a problem. It can be anything from a minor inconvenience to a major delay in your workflow depending on the model sizes and the speed of your storage. Normally, there's no way to guarantee that Windows can't page out the files and cold reloads are unpredictable.

Which is why I made Extended Weights Exchanger or EWE. This application can pre-load the files you need into RAM and then pin them there using Windows VirtualLock to prevent the pages from being evicted to disk. Every time your host app calls for the locked models, Windows serves it from the copy in RAM, saving the read from disk.

EWE with a number of model files 'warmed' in RAM

For ComfyUI users or other diffusion model users, image and video checkpointing models are supported, as are Ollama-managed models with a manifest and hashed filename.

The most dramatic speed up reported during beta use was from a ComfyUI user who saved an hour a day on model reloads across their generation checkpoints. While this is a staggeringly useful improvement, even a more modest return on investment means lower delay on inference or generation, better handoff between multi-model workflows, and accumulates substantial time saved.

RAM disks solve this problem, but introduce problems of their own. The disk starts empty on every boot and must be loaded with files manually or by setting up your own script. The memory used for that drive is locked in whether it is empty or full. Changing files on disk is a delete and/or copy operation.

And for advanced users who write their own scripts and tools that might want to preload or swap between files in VRAM, EWE has LIVE mode, which turns the app into a local HTTP server to accept claims on files from various clients and allow locking/releasing files for any purpose from 3D rendering to integration with your own llama.cpp fork or whatever you need.

LIVE mode hosting claims from several different clients

EWE is online and for sale after receiving a solid round of beta feedback.

[Self-Promotion] Following the 1/10th rule. This is a promotional post for a paid tool that I released publicly today.

If you are running local inference and you use more than one model for different purposes, the time to reload a different model becomes a problem. It can be anything from a minor inconvenience to a major delay in your workflow depending on the model sizes and the speed of your storage. Normally, there's no way to guarantee that Windows can't page out the files and cold reloads are unpredictable.

Which is why I made Extended Weights Exchanger or EWE. This application can pre-load the files you need into RAM and then pin them there using Windows VirtualLock to prevent the pages from being evicted to disk. Every time your host app calls for the locked models, Windows serves it from the copy in RAM, saving the read from disk.

EWE with a number of model files 'warmed' in RAM

Model files on disk under a normal file extension are supported, as are Ollama-managed models with a manifest and hashed filename. (And for ComfyUI users or other diffusion model users, image and video checkpointing models are just as supported.)

The most dramatic speed up reported during beta use was from a ComfyUI user who saved an hour a day on model reloads across their generation checkpoints. While this is a staggeringly useful improvement, even a more modest return on investment means lower delay on inference, better handoff between multi-model workflows, and accumulates substantial time saved.

RAM disks solve this problem, but introduce problems of their own. The disk starts empty on every boot and must be loaded with files manually or by setting up your own script. The memory used for that drive is locked in whether it is empty or full. Changing files on disk is a delete and/or copy operation.

And for advanced users who write their own scripts and tools that might want to preload or swap between files in VRAM, EWE has LIVE mode, which turns the app into a local HTTP server to accept claims on files from various clients and allow locking/releasing files for any purpose from 3D rendering to integration with your own llama.cpp fork or whatever you need.

LIVE mode hosting claims from several different clients

EWE is online and for sale after receiving a solid round of beta feedback.

How much space are you using for local model files? No, no, how much space are you actually USING for local models? The rest of them are just bloating your drive, aren't they?

Time to dump the stuff you're not using any more. Post the amount of space you just reclaimed.

I just saved back 178GB of older models and random test versions I picked up over the last few months and have absolutely no reason to keep any more.

If you run Ollama with multiple models and you are used to paying a reload price every time you have to evict one from VRAM to make room for another, this post is for you. If you trade off GPU time between Ollama and other VRAM-hungry tools, this post is also for you.

---

tl;dr: EWE is a Windows tool that pins files in RAM so you can load them from RAM to VRAM reliably and avoid cold loads from disk. Faster, easier and less maintenance than a RAM disk. I am giving away beta licenses for it.

---

EWE - Extended Weights Exchanger

The problem space

The problem that my utility solves is that the LLM files have to travel from disk to RAM to VRAM when they load. If you use more than one of these, the last one may not be able to stay loaded, meaning it has to be evicted from VRAM to make room for the next thing that runs. This problem compounds when you have other apps that also consume GPU and are VRAM hungry (ComfyUI, Blender, etc.). Different use cases, but all need exclusive access to the GPU.

Windows will try to keep a file loaded to RAM in memory, but if there is pressure on RAM, it will pick a page file to swap out to disk, so even if you have an app that has a 'touch' on a file, it's not guaranteed to keep it warm in RAM, which means some of these file loads will have to travel all the way back to disk and cold load the contents again.

The worse your hardware storage, the slower this is; HDD is terrible, SATA SSD is better, NVMe is best but still slower than RAM. RAM -> VRAM over PCIe moves 20GB files in no more than a few seconds.

There's an existing solution to this: RAM disks permanently segregate a part of your RAM and treat it like a disk drive. But you have to elect the size in advance, so it's eating RAM even if it's empty. It starts empty every time the computer boots and has to be loaded with files by a script or something, so there's constant maintenance of what goes in it. And the path used by your apps to those files has to be set to the RAM drive's path instead of the actual path on disk.

My solution

So what I did instead is map these files and pin them in memory using Windows VirtualLock, which directs the OS that these files are not allowed to be paged out. They stay warm in RAM at all times. For someone hot-swapping LLMs constantly or using multiple apps and needing their VRAM clean for each use, having the files at the ready to jump back into VRAM when needed is a huge savings.

And then there's LIVE mode. This makes EWE run as an local server (127.0.0.1:5235) that can accept claims from any other app/script. So you could write something that needs files loaded and wants to make sure they stay ready, or a pre-loader that anticipates when to load files earlier than they are needed to save that load time happening when the actual GPU call gets made. At that point, it just becomes a host for memory claims and opens up for use by anyone/anything that wants to keep a file ready.

HuBrIS - Human Brain Inference Storage

v0.1.0

An open source agentic memory system for local AI (MCP server hybrid, SQLite-backed, fully inspectable)

I have been building and polishing this and just pushed it public. Figured this was the right crowd to share it with.

It is designed to be very modular so that the models you use to drive it, the behaviors themselves, the connections and even the storage system can be updated over time.

The AI development world is moving fast, so it seemed like a better idea to build a framework that performs understandable, discrete actions rather than a monolithic, well-tuned machine that breaks as soon as the model changes or the the next tech upgrade comes out.

---

Overview

HuBrIS is a Python MCP server that gives your local AI agent a persistent, structured memory. It runs alongside Ollama (or any OpenAI-compatible endpoint), connects to your chat front end via adapter, and stores everything in a plain SQLite database you can open in any SQLite browser.

Every memory is a row in a table. All work done is in daemon files you can see and edit. Nothing is hidden, and anything can be turned off at will to limit its behavior. New pieces can be ingested and added to its behaviors by writing your own daemon files or your own frontend/backend adapters.

When it starts, an actual UI for configuration pops up to let you specify what to turn on and where to connect it to your chat system (frontend) and the inference engine you're using (backend). Once you inspect and configure what you need, you save and finish loading to turn on all your selected pieces (or everything).

---

Functionality

It maintains two tiers of memory:

Autobiographical (AB) - a faithful log of every message from your live sessions

Semantic (SM) - structured notes synthesized from AB records by a local LLM. Facts, preferences, patterns - the things your agent should actually remember across sessions.

Ten daemon processes run in the background handling classification, synthesis, compaction, escalation, splitting, and more. Each one is an independent Python file you can read, modify, or replace without touching anything else.

There are 11 MCP tools for recall: vector similarity search, range queries, exact match, catalog browsing, subject-based recall, and more. Session filtering is built in so you can scope recall to a single conversation.

---

Honest caveats

• You need a real reasoning model for the meta agent. Some daemons will require time for reasoning between your chat turns. Small models may produce garbage subject recognition.
• Vector search requires sqlite-vec to be installed separately and an embed model pulled in Ollama.
• It is a workbench, not a finished appliance. The prompts inside each daemon are the thing most likely to need tuning for your specific setup.
• It is v0.1.0. I use it daily and it works well for me, but I have one GPU and one workflow. I can't tell how it will work for anyone else who hooks it up differently until I get feedback.

---

Break it. Run it on a weird model, a weird front end, a weird machine. Tell me which daemon produces bad output and what prompt you used to fix it. The daemon architecture is specifically designed so you can make granular updates and the system will intake changes to the daemons without any full MCP restart.

The full documentation and download link are at libra-logic.com/hubris

I'm working on a hybrid MCP server/session manager that interacts directly with the session context/state of a chat so that it can run two kinds of memory association on each message:

1. Semantic memory (pure knowledge, facts and skills, and links to Autobiogrpahical memory for where that data came from)
2. Autobiographical memory (ordered history of what was said, with links to where things landed in Semantic memory)

It includes a logging layer to show how the meta-cognition and memory events are interacting with the context window. And because it stashes a copy of the context outside the "live" one, any changes by compaction or truncation can be evaluated to see what was removed. The better solution is to proactively detect several kinds of data that can be pruned, compacted or promoted to "do not forget this" memories.

• Dross: zero-value words, phrases, acknowledgements, polite terms, etc. Just eliminate this on every pass
• Subject matter: tag it with one of a growing set of subjects that expand like the Dewey decimal system
• Key info: move to a protected region of the context that is never allowed to drift or be removed (the watcher ensures it is restored if removed)

When a subject is stale and that knowledge is detected as wasting context space, it can be marked dormant and removed from context. The chat agent can proactively request this with close_subject(ID) to eject a dead topic from the session (for now).

The chat partner's other MCP tools include recall_subject(id) to allow it to pull up structured memory of the past when things get knocked out of context but become useful again. The recall system pierces layer-by-layer through the tree, meaning a quick call chain to delve to a deeper topic within a broad heading, or a shallow one-call for simple, easily accessible topics.

Memory persists across sessions, so even a fresh session can recall things from any other session pulled into the HuBrIS memory system. You could start a session with "Remember three weeks ago when we built that function for reloading a file?" and it would have the tools to:

1. Look at three weeks ago and find the message history where it was built
2. Cross link to the semantic memory and find that the original build was superceded a week ago
3. Look at the session a week ago to learn what the change was

And then reply "Yes, I remember that, but we changed directions a week ago and rebuilt it because..."

That's the goal.

The downside is that a second layer of meta-cognition about memory states means inferences running behind the chat turns you actively need. On local inference, this keeps your GPU running between turns pretty constantly. Meta-cognition quality is dependent on the model driving it, so subject identification, when to drop a subject that is no longer being talked about, and summarization of subject data relies on a good model running it.

I know there are others working in this space, but I had an itch and I had to scratch it on this subject because I want to play with having a coding partner that actually remembers what the eff we are doing.

Right now I'm building it to work with Continue and any OpenAI back end that is plugged into it (I'm using Ollama right now). Then I'm going to make an adapter for GHCP so I can give Copilot a proper cross-session memory system and have the memory calls run just as fast as the mainline chatting. Then I might see about adapters for some other extensions/systems it could run with.

I intend to have this tool out on a public github for people other than myself to play with by the end of the week.

Ask me anything. Either I did it, or I can put it on the roadmap. Can't wait to share this with everyone.

If you run multiple models in the same session, be it a coding LLM, a reasoning LLM, different ComfyUI checkpoints depending on what you're generating, you already know the problem. Every swap loads gigabytes off disk. Fast NVMe makes it bearable. SATA or spinning rust makes it genuinely painful. And Windows will evict those file cache pages whenever something else needs memory, so you can't count on the OS keeping them warm for you.

I wrote a Windows app called EWE (Extended Weights Exchanger) that addresses this directly. You add your models to a "warm map," set a RAM budget, and EWE pins the weights using Windows memory APIs so they can't be evicted. The next time any application loads that model, it reads from RAM instead of going back to disk. On my setup, swaps that were taking 60-90 seconds now take under 5 seconds.

https://preview.redd.it/q6t7o1nqr42h1.png?width=900&format=png&auto=webp&s=bf4eae93cbb1254fb759a28410db9004d2b4d691

It's not magic - you need enough system RAM to hold what you want to keep warm. But if you have spare RAM sitting idle while you work, this is a pretty direct use for it.

The app is at https://accord-gpu.com/ewe/ if you want to look at what it does. Currently collecting free early access accounts and enrollments for beta access to the products I'm building. EWE is going to be a one-time purchase (no subscription), and I want to get real users on it before setting the price.

A few things I'm genuinely curious about from this community:

• I wrote this for Ollama and ComfyUI specifically on my box. It reads the Ollama blob manifests and loads .gguf, .safetensors, .ckpt and .pth files so far. What other model formats should it support, and what other applications should I be checking against for compatibility?
• Is this a workflow pain you actually have, or do most people just absorb the downtime between model uses?
• Is there an obvious feature I'm missing?
• What would a fair one-time price look like for something like this for a perpetual license?

Honest feedback is more useful than encouragement here. If this solves a problem you don't actually have I'd rather know now.