Models Expire Every Quarter: Building a Model-Agnostic Local AI Stack

Look back at your own tool history for a moment. The model you were excited about eighteen months ago is retired. The "state of the art" coding assistant from last year is now the mid-tier option. The prompt tricks that felt like secrets are baked into every new model and mostly stop mattering. Meanwhile the plugin you wrote for yourself, the eval suite you built, and the folder of context files on your disk still work with every model you've installed since.

That's the pattern nobody prices in: AI tooling has a half-life, and it's short. Models turn over in months. The interfaces built around them turn over almost as fast. If your workflow is welded to any one of them, you're rebuilding your workflow every quarter — learning new menus, re-doing integrations, rewriting prompts against a moving target.

The alternative isn't predicting winners. It's architecture: build your stack so the perishable parts are thin and swappable, and the durable parts are yours. Local-first setups make this easier than cloud ones, because a local stack is already a pile of files and local servers you control — you just have to arrange them deliberately.

The Half-Life Table

Start by sorting your stack by how long each piece stays useful:

Two zones emerge: everything in the top three rows you should assume will be replaced; everything in the bottom three is where your investment compounds. Most burnout in AI-assisted work comes from spending effort in the wrong zone — re-mastering a new interface every quarter while the durable assets never get built.

Rule 1: Prompts Are Files, Not Chat History

If your best prompt lives in a past conversation, it's already half-lost. The durable home for prompts is the file system, where every model — current and future — can read them:

# prompts/review-pr.md
You are reviewing a pull request for a payments service.
Check: error handling on network calls, currency rounding,
secrets in logs. Output: findings list ordered by severity.
Never rewrite the code yourself; describe the fix.

The same file works with any model you point at it. When a new model lands, you don't rewrite the prompt; you test whether the new model follows it better (more on that in Rule 4). Personas and standing rules live the same way — in profile files and Modelfile SYSTEM blocks, not in muscle memory of what this month's chat product calls a "Project."

Rule 2: One Door to the Models

Vendor apps come and go; your pipeline shouldn't notice. Keep a single stable entry point to every model — Ollama's local OpenAI-compatible API is the practical standard — and make every workflow, script, and automation speak to that, never to a specific vendor's interface:

# every workflow speaks to one address; models rotate behind it
provider:
  base_url: "http://localhost:11434/v1"
  model: "{{MODEL_TAG}}"     # llama3.2 today, whatever wins tomorrow

The payoff shows up on release day for any new model: pull it, change one tag, and your entire automation estate — drafts, triage, reports, evals — is running on the new engine. No re-integration, no re-learning where the buttons moved. Cloud models can join the same way, as occasional exceptions behind the same door, with sanitized context — the architecture doesn't care where the engine lives, only that the door stays constant.

Rule 3: Tools Connect Through a Protocol, Not a Plugin

The year's most durable idea in AI tooling is the connection layer: protocols like MCP that let a model reach your databases, files, and APIs through standard interfaces instead of per-vendor plugins. The distinction matters for half-life reasons:

• A plugin built for one assistant's plugin system inherits that product's churn.
• An MCP server you run locally — a file-reader, a database connection, a webhook sender — serves any model that speaks the protocol, this year's and (in all likelihood) next year's.

{
  "mcpServers": {
    "local-files": { "command": "mcp-server-filesystem", "args": ["/workspace/projects"] },
    "postgres": { "command": "mcp-server-postgres", "args": ["--read-only"] }
  }
}

Write your tool connections once, against the protocol. When the model changes, the tools don't — which is exactly the inversion that makes a stack durable.

Rule 4: The Eval Suite Is the Shock Absorber

Swappable models are only safe if swapping is measured. This is where the eval habit pays for the whole architecture: a small promptfoo suite — a handful of prompts with assertions, run against the local API — turns "the new model feels sharper" into "34/34 assertions pass, promote":

# the swap ritual, every time
ollama pull newmodel:7b
npx promptfoo@latest eval -c evals/core-tasks.yaml \
  --provider openai:gpt-4o-mini:http://localhost:11434/v1:newmodel:7b
# green -> flip MODEL_TAG; red -> stay, with a list of exactly what broke

The suite itself is a durable asset: it encodes what "working" means for your tasks, in a form no vendor controls. Models improve underneath it; the definition of done stays yours.

Rule 5: Buy Hardware, Rent Models

The bottom row of the half-life table is the safest investment in the stack. RAM and a decent GPU outlive every model that will ever run on them — the machine that ran last year's 7B runs this year's 12B and will run next year's whatever. The economics mirror the developer-hardware shift of the past couple of years: people stopped renting tokens for daily repetitive work and started buying machines, because repetitive local inference at scale costs electricity while the capability keeps arriving on the used-market-friendly side of hardware.

The rule of thumb: buy the boring layer (compute, storage), rent the exciting layer (frontier capability for the rare task that needs it). A machine sized for a 14B model covers ninety percent of daily work forever; the occasional frontier-quality reasoning task justifies a few dollars of API spend through the same door — a deliberate exception, not a subscription-shaped lifestyle.

What a Quarterly Model Release Looks Like

The architecture earns its keep on release day. Compare the two workflows:

Make It Practical This Month

• Rescue your three best prompts from chat history into files tonight.
• Point every recurring automation at one local API address with a single MODEL_TAG variable.
• Move one per-vendor integration to an MCP server you run yourself.
• Build the ten-minute eval suite before the next model you're tempted by — it's the piece that makes swapping safe.

The tools will keep expiring; that's the one reliable prediction in this space. The stack that treats churn as a constant — thin doors, fat files, measured swaps — stops caring about the prediction. New model? Pull, evaluate, flip the tag. That's the whole ceremony.

Frequently Asked Questions

Doesn't locking into one local API just move the lock-in problem? OpenAI-compatible APIs are the closest thing the space has to a neutral socket — nearly every model, local or hosted, speaks it, and it's trivially proxied if it ever shifts. The insurance is structural: your prompts, evals, and tools are files that work with any provider, so even a hypothetical protocol collapse costs you a weekend of adapter work, not a workflow.

What about features only the big hosted assistants have? Use them — as exceptions, through the same door, with context you'd be comfortable shipping to that vendor. Artifacts, deep research modes, and frontier reasoning are genuinely excellent at the rare tasks that need them. The architecture doesn't forbid renting capability; it just keeps the rented parts from becoming the load-bearing walls.

How do I stop prompt files from rotting as models change? That's the eval suite's second job: it detects when a model change quietly broke a prompt that used to work. A failing test on an old prompt file tells you exactly which durable asset needs a touch-up — file-by-file, not workflow-by-workflow. Treat prompt files like code: owned, versioned, tested.

Is this overkill if I only use AI casually? Scale it down, keep the shape. Casual users still benefit from the two cheapest rules: prompts as files, and one door to the models. That's a folder and a habit, not infrastructure — and when the next model lands, you'll be the person spending ten minutes while everyone else relearns an interface.