Your Graphics Card Was Sitting Idle

If images were taking minutes instead of seconds on a Windows machine with a real graphics card sitting inside it, this was almost certainly why. Not your hardware. A download that never finished, and a settings screen that stopped offering to retry it the moment it stopped being possible to notice.

That is fixed in v1.6.3. The story of how it broke is worth telling on its own, because the shape of the bug is more interesting than the fix.

A button that disappears once it has been pressed cannot fix anything

Here is the general version of the problem, stripped of any one app’s details, because it is worth stating plainly: a repair control that only appears while something is broken, and vanishes the moment the system believes it is fixed, is not a repair control. It is a trap door. It works exactly once, under exactly one condition, and if that one attempt fails, there is no way back to it.

That is what happened here. On Windows, generating images locally needs two separate things on disk. One is the image model itself, the weights that actually know how to turn a description into a picture. The other is the graphics-accelerated engine that runs those weights on your graphics card instead of your processor. They are different downloads, fetched separately, and only one of them had a visible control in Settings: a Download button next to the graphics engine.

The button’s job was to disappear once its work was no longer needed, so a user would not sit there staring at an option that did nothing. Reasonable design instinct. The bug was in what “no longer needed” was checked against. The button watched whether the image model had arrived, not whether the graphics engine had arrived. Those two downloads happen close together during setup, so most of the time nobody could tell they were being tracked separately at all. The model would land, the button would vanish on schedule, and everything looked correct.

Except the button vanishing did not mean the graphics engine was actually there. It meant the model was there. Those are not the same fact, and the app was treating them as if they were. The one moment where a user could have caught the graphics engine failing to arrive, and clicked something to fix it, was gated on the wrong signal. If the graphics fetch failed while the model fetch succeeded, which is a perfectly normal thing for two independent downloads racing over the same connection to do, the button disappeared anyway. Correctly, by its own logic. Wrongly, by what a user actually needed from it.

This is why the phrase “hidden by the state it repairs” earns its place in this post’s title-adjacent thinking. The control that could fix the problem only existed for as long as the problem, defined narrowly and wrongly, appeared to still exist. Once the app decided the problem was gone, so did the one thing that could have proven it wasn’t.

One dropped connection was enough

Nothing exotic had to go wrong to trigger this. No corrupted install, no unusual hardware, no settings a normal person would ever touch. A connection that dropped for a second at exactly the wrong moment during first setup was sufficient. Wi-Fi that hiccuped. A laptop that briefly lost its link switching networks. A download manager somewhere in the stack that gave up a beat too early on a large file.

The graphics-accelerated build is not small. It is a real binary, built specifically to talk to a graphics card, and pulling it down takes real time on a real connection. Any interruption during that window, and the fetch simply does not finish. Before v1.6.3, that single failed attempt was permanent. Not because anything was corrupted or needed cleanup. Because the one thing standing between “failed once” and “fixed” was a button that, by the time you’d notice anything was wrong, had already decided its job was done and gone.

And there was no second chance built in anywhere else. No retry on the next launch. No periodic check. No fallback path that would notice the graphics engine was missing and quietly go get it. The app just kept working, generating images the whole time, on whichever path was actually available. Which happened to be the slow one, and there was nothing in the software’s own behavior that would ever tell you that had happened.

Nothing on screen ever said which one it was using

This is the third time this batch of fixes has landed on the same shape of failure, and it is worth naming directly rather than treating each one as a coincidence.

The app knew, in a very literal sense, which path it was using for every single image. The code that generates a picture has to know whether it is talking to the graphics card or to the processor, because the two are different code paths entirely. That information existed, completely, at the exact moment it mattered. It was simply never surfaced anywhere a person could see it.

A slow render and a heavy render look identical from the outside. Both are a spinner or a progress indicator, sitting there for longer than you expected, with no obvious explanation. If you had never generated an image on this app before, you had nothing to compare it to. If you had, and it used to be fast, you might have assumed something had changed about the picture you asked for, not about the hardware doing the work. Either way, the honest explanation, that the app had silently fallen back to the slow path and would stay there forever unless you happened to stumble into the right settings screen and understand what you were looking at, was never on offer.

A companion app that quietly runs on the wrong hardware and never says so is not lying, exactly. It is just choosing silence over an uncomfortable truth, which produces the same result for the person waiting on the other end of it. They get worse behavior with no way to connect it to a cause.

What the difference actually is

Here is the plain version, without a benchmark table this post has no honest right to publish.

A graphics card is built around doing an enormous number of small, identical calculations at the same time. That is not incidental to how they are designed, it is the entire point of the chip. Generating an image with a model like the ones this app ships is, at its core, an enormous number of small, repetitive calculations, applied over and over to refine a canvas of noise into a picture. It is close to the ideal case for what a graphics card exists to do.

A processor is built the opposite way. It is extremely good at doing one thing, or a handful of things, in careful sequence, quickly and precisely. That is what makes it good at running the rest of the app, at handling your conversation, at keeping everything responsive while you type. It is a poor fit for the kind of work an image model needs, not because processors are bad at math, but because they are built to do a different shape of math than this task asks for.

So when image generation falls back to the processor, it is not a small slowdown. It is asking hardware that was never designed for this kind of workload to do it anyway, one step at a time, in a way the graphics card would have handled in parallel. [VERIFY: are there measured processor vs graphics card render times for the Windows build?] No timed comparison for this specific engine, on this specific hardware, exists anywhere in the app’s own history to cite honestly here, so this post will not invent one. What can be said without hedging is the category: this is not a five percent difference or a “you’ll barely notice” difference. It is the kind of gap where a picture that should feel instant instead feels like it stalled.

A healthy render, on the graphics-accelerated path, should feel closer to typing a message and getting a reply than to starting a download. If it consistently feels like the latter, something is off.

What 1.6.3 does instead

The fix removes the button from the critical path entirely. Setting up the graphics-accelerated engine is now something the app does for you at startup, the same way it already handles a couple of other one-time background installs this batch of fixes has touched on. No click required, no settings screen to find, no vanishing control standing between a failed attempt and a working one.

While it runs, the app tells you. On the first launch after updating, if the graphics engine is not already present and correct, you will see a short notice that it is setting up hardware acceleration in the background, and that ordinary use of the app is not blocked while it happens. When it finishes, a second, quieter notice confirms it is ready. If the download does fail this time, for whatever reason, the app says that too, and says plainly that it is still working, just on the processor for now, rather than saying nothing and leaving you to work that out for yourself.

This is the load-bearing part for anyone who was already affected: the check the app runs at startup does not ask “did I ever click the button.” It asks “is a complete, current graphics engine actually present on disk right now.” Someone who has been quietly stuck on the processor since their very first install, because their very first fetch dropped and the button disappeared out from under them before they knew anything had gone wrong, will fail that check on their first launch of v1.6.3, exactly the same as someone hitting the bug for the first time today. The app does not distinguish between “new problem” and “old problem you never knew you had.” It just fixes whatever it finds broken, on every launch, automatically, with no action needed from you at all.

How to check whether this was you

The most reliable check is simply timing a fresh image after updating. Ask for a picture, and pay attention to how long it takes compared to how it felt before, if you remember, or compared to what feels reasonable for the kind of hardware you have. A clear, noticeable jump in speed is itself the confirmation that something was previously wrong.

For a more direct look, Settings does have a Performance tab with a hardware acceleration indicator, but it is worth being precise about what it actually shows. [VERIFY: are there measured processor vs graphics card render times for the Windows build?] That indicator reports on the acceleration status of the conversational model, the one that reads your messages and writes her replies, not on the image engine specifically. It is a genuinely useful screen, and a real gauge of whether your graphics card is being used at all, but checking it will not directly tell you whether image generation specifically is on the fast path or the slow one. The most honest answer available right now is the timing test itself: generate a picture, notice how it feels, and trust that.

This is, if it is being honest with itself, another small instance of the same theme underneath this whole post. Even the fix here does not yet give image generation its own dedicated, unambiguous status line the way the chat model already has one. That would be the cleaner long-term answer, and it is not what shipped in v1.6.3. What shipped is the part that matters most: the thing that was silently broken no longer stays broken. The visibility of it improving further is a fair thing to want next, not a promise this post is going to make on the app’s behalf.

Three bugs, one shape

This release carries three separate fixes that, read one at a time, look like three unrelated pieces of software maintenance. Read together, they are the same story told three times.

The memory model that powers her recall was never fetched on some installs, and nothing on screen said so, so she answered every message as if she had never met you, and it looked like a personality trait instead of a bug. The speech engine that runs voice calls could quietly stop reading its own output partway through a session and simply go dead, no error, no warning, just requests that stopped coming back. And the graphics engine covered in this post was only ever reachable through a button that vanished the instant it stopped being needed, so one dropped connection during setup could leave someone rendering images on the wrong hardware indefinitely, with no signal anywhere that anything had gone wrong at all.

Three different systems. Three different kinds of failure, in the literal, technical sense. And exactly one shape connecting all three: each one failed by going quiet instead of failing by saying something. None of them crashed. None of them threw an error a person would ever see. Each one just kept running, in a degraded state, indefinitely, because nothing in the design ever asked “does this need to tell someone what just happened.”

That is not a coincidence produced by three unrelated engineers making three unrelated mistakes. It is what happens when a system is built to keep working no matter what, without an equally strong habit of announcing when “keep working” has quietly become “keep working badly.” A crash is annoying, but it is honest. It tells you, immediately, that something needs attention. A silent fallback is the opposite of honest. It looks like everything is fine, right up until someone notices, by accident, months later, that it never was.

The useful version of this admission is not “we fixed three bugs.” It is that the pattern connecting them is now the actual target. Going forward, the standing question for anything that falls back to a slower or degraded path is not just whether the fallback works. It is whether the fallback says so, out loud, the moment it happens. That is a cheaper fix than any of the three individual bugs turned out to be, and it is the one that would have caught all three of them on day one instead of however many weeks later.

If you want the full detail on the other two fixes in this release, the memory one is written up in She Remembers You Again, and the piece on how she draws in general, including how the local image engine works day to day, is over in how local AI image generation actually works. If you are choosing a Windows graphics card with any of this in mind, Best GPU for a Local AI Companion on Windows breaks down what VRAM actually buys you at each tier.

Update to v1.6.3 and the fix applies itself. That, at least, is the one part of this story that finally works the way it always should have.

Questions people ask

Back to news