A used graphics card changed my buying decision

A few months ago, compact AI workstations looked very appealing. Plenty of memory, a small footprint and models I could run at home were a compelling combination. I covered this in my comparison of DGX Spark, Asus GX10 and GB10 AI mini PCs, then in my analysis of local AI boxes and inference engines.

Today, a used graphics card already covers a large share of my needs. On my RTX 3090, the quality and responsiveness make agents useful in my everyday work. For my tasks, I get a level of quality comparable to what I expected from Opus 4.8.

I recently put that setup to work on a real project. Using an entirely local agent workflow, I built a fullstack web application in three hours, including its interface and server side. It met my quality standards and constraints, particularly my requirements for art direction. Frankly, it worked really well, averaging 120 tokens per second during generation. Tokens are the units of text processed by the model.

What convinced me was the application I had after those three hours. The agent followed my instructions, I got the result I wanted, and the responsiveness let me maintain a productive pace. That is when local AI stopped being an experiment in my daily routine.

In my account of Qwen, Strata and the RTX 3090, I had already described tests with Qwen 3.8 Flash, Strata, an RTX 3090 and 64GB of RAM. Since then, my preference has continued to shift towards this machine.

The €650 paid for the card I added to my existing PC. It was not the cost of an entire workstation. That is exactly why this matters to me. When better software makes hardware you already own more useful, it can change a buying decision as much as a new generation of chips.

Local AI has existed for far longer than a few weeks. What changed for me is how comfortable it has become to use. I now run it to get work done, beyond simply checking that it runs.

October brings open models closer to practical agent workflows

An agent model needs to chain actions, use tools, read their outputs and keep working towards a goal. Producing one good answer is only part of the job. This helps explain the emphasis on coding, long context and execution efficiency in recent announcements.

October's announcements reflect this shift. This October 20 selection was expanded on October 22, 2026 with Recursive Flint. B means one billion parameters.

Model Verified status What stands out to me
Mistral Large 4 API preview announced on October 6; weights expected at the end of the month A large multimodal MoE that brings Mistral back into the conversation about agents and business applications
Nemotron 3.5 Super VL and Bolt Super VL and Bolt 74B-A9B available since October 15; Bolt E4B announced for October 23 A family explicitly targeting different machine sizes, from servers to local workstations
Muse Spark Open Downloadable weights; 816B total parameters, 42B active, a 1-million-token context window An ambitious multimodal offering with integrations across several engines and platforms
DeepSeek V4.1-Flash-1017 Update released under MIT, with an advertised 1-million-token context window Alongside quality improvements, the provider highlights faster task completion and shorter outputs
Beam 1.0 Weights released on October 16 under Apache 2.0 Reflection's coding and agent model, with 501.3B total parameters and 23.4B active according to its model card
Step 5 Preview Weights offered through StepFun's official Hugging Face organization An architecture designed around long tasks and context costs, with 92 Transformer blocks
Ornith 1.5-122B and AtomicChat GGUFs DeepReinforce MoE model under MIT; original weights and quantizations available Another US developer targeting agentic coding and tool use, in a more compact format than MoEs with several hundred billion parameters
Recursive Flint Apache 2.0 weights; 39.8B parameters, approximately 2.5B active per token A local coding MoE accompanied by the rec engine and coordinated work on architecture, quantization and execution kernels

This wave spans several deployment scales, from personal computers to servers with multiple GPUs. That is what interests me: an ecosystem is forming around different needs and budgets.

Mistral's timing also matters. As of October 19, Large 4 remains an API preview with a promised weights release. My analysis of Mistral Large 4, Le Chonk and its MoE architecture already covered this distinction.

Ornith adds a US developer in an intermediate size class

Ornith 1.5-122B deserves a place in this wave. It comes from DeepReinforce, the US team behind the Ornith family. The model uses a Qwen 3.5 MoE architecture, is released under MIT and offers a native context window of 262,144 tokens. Its model card documents tool calling and integrations with Hermes Agent, covered in my Windows installation guide, OpenClaw and OpenCode, putting it directly in the workflows that interest me.

In DeepReinforce's published evaluations, it scores 74.6 on MCP-Atlas and 76.9 on SWE-bench Pro. The appeal is pursuing that level of agent capability with a model in the 122B class, more compact than the very large networks discussed above. This is exactly the kind of candidate I want to test locally.

The AtomicChat repository linked here adds the practical deployment layer. AtomicChat converts Ornith's weights to GGUF, a format used by engines including llama.cpp, with several quantization levels. Its card lists 71.2GB for AD-Q4_K-IQ4_XS and 47.6GB for AD-IQ3_XXS-IQ2_S, before working memory and context. This is an interesting model class for workstations with 64 to 128GB of memory, distributing workloads between GPU memory and system RAM as the machine and engine allow.

It also adds another dimension to the industrial picture. Value is created at several layers, from the team developing the model to the team preparing quantizations and the software making them usable. An open ecosystem lets other US developers offer local agents alongside established labs and chip manufacturers.

Recursive Flint combines a small MoE with its own local engine

With Flint, Recursive offers an even more compact model for development agents. The weights are open under Apache 2.0, and the model handles reasoning and successive tool calls. Its model card and configuration file explain what the 40B-A2.5B designation means.

Specification Recursive Flint
Total parameters 39.8 billion
Active parameters per token Approximately 2.5 billion, including the output head
Layers 49, including 2 dense and 47 MoE layers
Experts per MoE layer 256 routed experts, 6 selected per token and an always-active shared expert
Attention 35 sliding-window layers with a 513-token window and 14 full-attention layers
Attention heads 32 query heads and 4 key/value heads
Published checkpoint context 262,144 tokens, including input and output
Modalities Text input and output

The launch announcement describes support for up to 512,000 tokens and recommends staying within 256,000 for the best results. In Recursive's published measurements, Flint exceeds 125 tokens/s on an M4 Pro MacBook Pro and 150 tokens/s on a 64GB RTX Spark, at short contexts. The model card also reports 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2 and 74.2% on SWE-bench Verified.

The software is equally interesting. Recursive publishes rec, an Apache 2.0 engine that downloads the model and automatically connects Pi or OpenCode. The current requirements are an M4 Pro, M5 Pro or M5 Max Mac with at least 48GB of unified memory and approximately 30GB of free storage. RTX Spark support for rec is listed as coming soon. The llama.cpp documentation also provides Metal and CUDA paths, the latter on Linux or WSL2, using a compatible GGUF and runtime revision.

What stands out to me is Recursive's work across the stack. Its automated research system, Eureka Machine, contributes to model design and execution optimization. This reinforces the trend I am describing here. An efficient architecture becomes far more useful when it comes with suitable weights, optimized compute kernels and an engine you can actually install on your machine.

What the rankings show today

On Artificial Analysis, I chose a selection of the open models discussed here and added GLM-5.3 and Kimi K3 to place this wave in a wider context. For comparison, I kept the two highest-ranked models, Claude Opus 5.5 and Sonnet 5.5, alongside GPT-6 Astra and GPT-6.1 Sol.

Artificial Analysis Intelligence Index, fourteen-model selection on October 20, 2026
Artificial Analysis screenshot taken on October 20, 2026. Intelligence Index v4.3.2, with 14 models selected. Reasoning variants appear below the bars; Mistral Large 4 is still in preview.

Opus 5.5 and Sonnet 5.5 score 58 and 56 respectively, ahead of GPT-6 Astra at 53. DeepSeek V4.1 Flash 1017 and GLM-5.3 score 45, while Step 5 Preview and Kimi K3 reach 44. Qwen3.8-Flash-Next scores 40, Muse Spark Open 39 and Mistral Large 4 Preview 38. Beam and the Nemotron models occupy other positions in this selection, offering different balances of capability and efficiency.

The gap to the most capable closed models remains visible. But my daily decision involves more than buying the highest score. Speed, availability, cost and quality on my own tasks determine what I can actually do with a model. These also guide my comparison of LLMs for coding and agents.

Intelligence Index cost per task for the selected Artificial Analysis models
Artificial Analysis screenshot taken on October 20, 2026. Weighted average cost per Intelligence Index task, in US dollars through APIs. Thirteen models have a displayed value; Bolt remains selected but has no cost bar. These amounts describe the evaluated APIs.

The second screenshot shows another dimension of competition. In this selection, Nemotron 3.5 Super VL and DeepSeek V4.1 Flash 1017 cost $0.19 and $0.26 per task, compared with $5.46 for Sonnet 5.5 and $5.98 for Opus 5.5 in the configurations shown. Their intelligence levels also differ. For the companies building them, improving the balance between results and resources consumed opens a much broader market than the race for the highest score alone. I explored this cost-per-task approach in my analysis of DeepSeek V4 Flash for business agents.

MoE reduces compute while memory remains a constraint

Many announcements share a mixture-of-experts, or MoE, design. A routing mechanism selects a subset of the network to process each token, rather than activating every parameter at each step.

Thinking of this as a collection of small models can be helpful, with one caveat. An expert is not necessarily an independent assistant with a recognizable specialty such as law or accounting. It is a part of the network learned during training.

This architecture partly separates the model's total capacity from the computation needed to run it. The expert weights still need to remain accessible somewhere. GPU VRAM, system RAM, storage and transfers between them all retain their limits.

Consider a simple calculation. A network with 500 billion parameters takes approximately 250GB at four bits per parameter, before metadata, buffers and context memory. A low active-parameter count does not make it a 24GB model.

Progress comes from several techniques working together. MoE reduces some of the computation. Quantization reduces the precision and storage footprint of weights. The inference engine manages loading and execution. Attention architectures and context management reduce other memory and compute costs.

The goals are converging, while the implementations differ. StepFun describes a combination of local attention and sparse global attention. NVIDIA uses components including Mamba in Bolt. The MoE label covers several architectural approaches.

NVIDIA is designing the model around the machine

Nemotron 3.5 Bolt 74B-A9B 24GB makes this convergence tangible. NVIDIA describes architecture compression and quantization designed for a memory target below 24GB.

The technical details go beyond calling it a two-bit model. Much of the relevant weight storage uses very low precision, while other components retain different formats. The model is then tuned to preserve its capabilities.

For me, this is the industrial signal. The manufacturer now designs a model for a specific hardware envelope and use case, alongside the chips developers will run it on.

Compute owners also want the ecosystem

NVIDIA's overall strategy is becoming clear. Hardware, CUDA, optimized engines, Nemotron models and agent integrations reinforce one another. An open model can drive platform adoption even when downloading it is free.

Openness can reduce our dependence on an API while increasing the appeal of a hardware and software ecosystem. Both effects can happen together.

Mistral is taking another path. It says it trained Large 4 in its own European data centers and serves the preview from there. This brings research, infrastructure and distribution together. Meta, meanwhile, is supporting Muse Spark Open with integrations involving several hardware vendors and engines. Its business model differs from that of a GPU manufacturer.

All of them want influence beyond the weights file. Tools, deployment convenience, use cases and developer habits are becoming part of the competition.

Licensing is part of the decision too. Downloadable weights do not automatically grant the same freedoms. DeepSeek lists MIT, Beam uses Apache 2.0, and Muse Spark Open is governed by the Muse Model License. The term open-weight describes this selection more accurately than applying open source to every entry.

PCs and compact workstations become deployment targets

DGX Spark and partner machines powered by GB10 have established a compact AI workstation category. RTX Spark extends that ambition to Windows laptops and small desktops, with up to 128GB of unified memory depending on configuration.

RTX Spark uses N1/N1X variants, distinct from DGX Spark's GB10, following the same approach of combining Grace and Blackwell.

I see two paths to local AI. One involves buying a new machine with substantial memory and a more integrated software stack, as explored in my analysis of the 256GB Mac Studio M5 Ultra as a DGX Spark alternative. The other involves getting more out of existing hardware, as I am doing with my RTX 3090.

The first can simplify setup. The second can sharply reduce the entry cost. Either way, the model you actually use, its response time, power consumption and the machine's place in your daily routine matter.

Software changes the economics of existing hardware

llama.cpp develops inference across different hardware, quantized formats and CPU/GPU configurations. Strata specifically targets workloads including Qwen3.8-Flash-Next on consumer hardware. Its documentation describes expert placement across several memory tiers.

That explains why a configuration can become far more appealing without replacing the graphics card. Software improves how available resources are used. Expert placement and reduced data transfers become key performance levers.

Include NVMe storage and RAM in the budget

You still need room for weights, different quantizations and working files. I favor an NVMe SSD with plenty of free space, to load models quickly and reduce waiting when the engine needs to read data from disk. Strata's technical documentation strongly recommends NVMe storage and 64GB of RAM for its reference configuration. Keeping several large models quickly adds up to hundreds of gigabytes.

When the budget allows, more RAM also improves the experience. It can hold weights that do not fit in graphics memory and avoid some disk reads. Speed therefore depends on the GPU, RAM, storage, quantization and engine working together. That is how you get more from a graphics card you already own.

Context windows from 512,000 to one million tokens also enable new workflows, keeping more files, instructions and history in a single working session. Using that capacity depends on available memory and how the engine processes inputs and retains context.

To assess my setup, I look at whether the agent completes my work correctly, how long I wait and how often I need to intervene. Tokens per second provide useful information, alongside the wider working experience.

As quotas drain, local AI becomes a FinOps ally

Over the past few days, I have been seeing more accounts from people whose quotas are running out much faster. I share that feeling. My Claude Max allowance is draining before my eyes, even without using Fable or taking on particularly complex projects. This week, I am consuming more than last week, and I find myself watching a meter when I just want to get work done.

The screenshot below captures that disconnect. On October 22, Priya describes Opus 5.5 usage that felt almost unlimited the previous week, then shows a weekly allowance already 90% consumed despite what she describes as no heavy use. That account closely matches my experience right now.

Priya's October 22, 2026 X post about Opus 5.5, showing 90% of the weekly allowance used and describing faster consumption than the previous week
Screenshot supplied by Ruben, showing an X post by Priya (@Priyannkaaaa) dated October 22, 2026. The visible meter reads “This week” and “90% used.” The author reports rapid consumption despite what she considers moderate use.

Anthropic documents session and weekly usage limits. Consumption depends on factors including the model, effort level, conversation length and features used. Claude, Claude Code and Claude Desktop share the same allowance, so switching tools does not give my subscription a fresh budget.

This tension between a subscription and the capacity actually available extends beyond Claude. My article on ChatGPT Pro, new quotas and the end of unlimited expectations examines that trade-off at OpenAI.

Save the largest models for the decisions that matter

A first response is to distribute the work more carefully. Fable or Opus can clarify requirements, challenge the architecture and produce a precise plan. Once constraints and acceptance criteria are set, Sonnet can handle implementation and Haiku can take well-defined subtasks. Haiku at max effort is another option to test where the task warrants it, bearing in mind that higher effort consumes more tokens.

Smaller models have a strong case. In Anthropic's published evaluations, Sonnet 5.5 scores 70.6% on Terminal-Bench 4.0 and Haiku 5.5 scores 39.2% on the same agentic coding benchmark. Haiku is also positioned as a coding subagent. That provides a basis for an effective workflow without calling the most expensive model for every change.

A local API gives organizations more control over task costs

For an organization, a local API adds a concrete FinOps lever, a way to manage the cost of computing workloads. An agent can send routine implementation, fixes, documentation and repeated iterations to it, then return to a cloud model when a difficult decision requires it. Each loop executed locally preserves subscription capacity or avoids metered API consumption.

When a reasonably priced gaming PC can run a model with roughly 120 to 125 billion parameters, using quantization and distributing weights between system RAM and graphics memory, that strategy gains a new dimension. Ornith's 122 billion parameters illustrate this model class. The hardware and inference engine become productive capacity you own and can put to work across several workflows.

I therefore look at cost per completed task, waiting time and rework, including hardware depreciation, electricity and maintenance. My account of unpredictable everyday costs with GitHub Copilot shows why this matters even for routine tasks. Local APIs are an important FinOps ally for organizations using agents every day. They let work continue as the cloud meter approaches its limit and give teams a choice about where to spend their budget.

NVMe storage and RAM cost money, and a comfortable setup is a real investment. But that investment makes sense when the machine replaces regular paid API consumption. In intensive agent workflows, calls, context and iterations add up quickly, while the hardware keeps working. The equipment can pay for itself quickly as actual API spending is avoided. Alongside the financial benefit comes sovereignty, with weights, an engine and data that can stay in your own environment. This is one of the choices to address in an enterprise AI strategy covering governance, sovereignty and FinOps.

The fallback can become the everyday choice

This shift is happening while centralized infrastructure faces physical constraints. In its 2025 Energy and AI report, the International Energy Agency estimated that around 20% of planned data center projects risked delays unless grid constraints were addressed.

Outages, service saturation and subscription limits add further constraints. Their causes differ, but the result for someone working with an agent is the same: work stops.

An installed local model addresses part of that dependency. It can keep processing files, drafting or working on a repository stored on the machine when the remote provider is unavailable. Web research and connected tools still depend on the network and their own services.

After using it as a fallback, you may find that it also handles ordinary working days. That is what interests me about moving from plan B to plan A. I can reserve the cloud for tasks where it offers a clear advantage, instead of automatically sending every operation there.

The absence of a provider quota also changes the experience. I can retry, experiment and leave an agent working without watching a subscription meter. Hardware, electricity and maintenance still cost money, and the machine has a finite capacity.

My next purchase can wait

For my current needs, I do not need a DGX Spark costing around €7,000. My second-hand RTX 3090 is enough. Bought for €650 and installed in a PC I already owned, it delivers a working experience and quality that continue to impress me.

Quantization and distributing workloads between graphics memory and RAM give me access to a very wide range of models, including MoEs in the 125-billion-parameter class such as Qwen3.8-Flash-Next with Strata. Larger models require choosing a suitable format and arranging the available memory. What I can do on this machine already covers the vast majority of my needs, with the responsiveness I need for everyday work.

October's releases reinforce that conviction. Models are improving, machines are becoming more varied, and engines are extracting more from available hardware. At the same time, companies are competing to become the natural connection between all three.

My decision now comes down to a concrete question. How much of my work can I complete properly, at a manageable cost, using capacity I control? Today, the answer is enough to put my DGX Spark plans on hold. And enough for a €650 used graphics card to play a much bigger role in my work than I expected.

Sources and methodology

Article finalized on October 20, 2026, using sources consulted on October 19, 2026 and screenshots taken on October 20, 2026. Specifications and availability come from the providers; the industrial interpretation is my analysis.

Article expanded on October 22, 2026 with Recursive Flint, its technical sources, and an account of Claude Max quotas and local APIs as a FinOps tool.