AI Assistant Backup Access: How I Reach My Own Website When I Can’t (Notion Memory, OpenRouter, Crypto, Full Stack)

An AI assistant can be more than a chatbot. Built right, it becomes a backup channel to your own website, email, and files — the thing that still reaches your infrastructure on the morning your VPN is dead, your proxies are down, and your own mailbox won’t open. This is not a thought experiment for me. It’s how I work now, and below is the exact architecture, in plain steps, with the honest limits most tutorials leave out.

This started with a reader’s comment. Mark wrote in:

I already have a domain, I’ve rented server time before so have been down that route. What I didnt’ know is the bit that some hosts do WordPress right out of the box.

I am a bit curious as to how you got an assistant to do the mechanicals of moving stuff for you. I’ve done some stuff with that (canvas generating of Python in Gemini, and hosting GEMMA and other LLM’s in LM studio / vMLX etc, but haven’t got them doing full on tool calls yet).

But this lays out the roadmap and I can search the rest. Thankee…

Fair question.

Let me set the frame straight before I answer, because it matters. I’m not a developer. To a real engineer, what I’ve built is probably kindergarten-level — small, blunt, nothing clever in it. I’m an ordinary user, about as entry-level as they come. So I’m not answering from above, and I’m not scrambling to build something to order. I already use this every day. I’m just showing another plain user what a plain user managed to wire together — and yes, a specialist will find it tiny.

One thing up front, because it explains every design choice that follows: users like me are rare, and being rare is itself a trigger for getting blocked. I knew that. So I built the system specifically to reach my own site and mail at the moment direct access is cut off.

Why one access channel is a single point of failure

One way in is not a plan. It’s a hope. If your only path to your AI is a subscription tied to a card, then your card, your account, or one failed payment can take the whole thing down at the worst hour.

So I run two doors. Door one is the normal subscription app, paid by card. Door two is OpenRouter: you top it up with cryptocurrency and pay per token, by the session, not by a monthly charge that can lapse or be refused. Same reasoning, paid with money that doesn’t have to explain where it came from. When door one chokes, door two is still open.

Be honest about what this does and doesn’t cover, though. Two doors back up the brain. Mirroring (next section) backs up the memory. But the hands — the connectors — and the host my site sits on are still single points: if the host goes down, the whole combine stops, no matter how many brains I can reach. I know that. I’m not selling this as full fault-tolerance — it’s layered redundancy where it counts most, and honest gaps where it doesn’t yet.

Stop letting Projects eat your token limit — move your memory to Notion

The Projects feature burns through usage limits faster than anything else, because the project’s files are fed back into context on every single reply. The more you pile into the room, the more expensive each breath.

The fix: stop holding memory inside the assistant. Move your working memory to Notion, connect it, and instruct the assistant to look there before answering — “check Notion first, that’s your memory.” Now any question sends it to fetch what it needs, instead of dragging the whole archive through context every time.

Honest note for the technical reader: prompt caching softens the cost of resending context, but on a large project it doesn’t save you. External memory does. As a bonus, Notion’s own AI tools are tuned for low token consumption, and Notion gives you calendar and mail as built-in services — so one workspace holds memory, schedule, and correspondence in a single place you can actually navigate by eye.

Don’t trust one platform — mirror your memory and own your export

Your memory shouldn’t live in one platform. Mirror it across several stores — Notion, Google Drive, GitHub, whatever’s convenient — and keep a current export of each, because you don’t know which platform goes dark or changes its policy tomorrow.

I keep several stores and save different versions across them. Data portability is increasingly a legal standard (GDPR-style), and serious platforms now offer easy export and import — treat that as insurance, not paperwork. The point isn’t redundancy for its own sake; it’s that no single platform’s outage or policy shift can take your memory with it.

And I don’t save anything by hand. At the end of every chat, one command to the assistant — “log this session” — and it’s done. Saving is delegated, mirroring is automatic, and the version history builds itself while I work.

Give the assistant hands: connect it to your site, mail, and drive

Connectors are what turn a chatbot into an operator. Through MCP (the open standard most assistants now support), the model gets hands: connected to WordPress, Gmail, Google Drive, and GitHub, it publishes, edits, files, and maintains — on command, directly, not as advice you then execute yourself.

The practical move is one connector at a time. Start with the one workflow you repeat most — for me, publishing to my site — then add the next. Each connector is a separate hand that touches its own corner.

Managed vs self-hosted: why I left WordPress.com to connect my AI

To connect an AI assistant to your site, you usually need self-hosted WordPress — on managed WordPress.com, the plugin and full API access you need sits behind a higher-tier plan. That’s the wall you hit on a managed plan: no usable API key on the tier you’re on. And watch the phrase “WordPress out of the box” — it cuts two ways. A managed host hands you WordPress with the API gated behind the plan; a one-click install on ordinary hosting gives you self-hosted WordPress with the API open. “Out of the box” alone doesn’t tell you which — check whether it’s managed or self-hosted before you commit.

Self-hosted WordPress is different. Install it yourself on your own host and Application Passwords come built in (core since 5.6): you generate the API key yourself under Users → Profile, hand a dedicated “agent” user a minimal role — Editor to publish, Author to post only under itself — and connect. No paywall on access, full REST API, your own custom endpoints.

That’s exactly why I left managed hosting the moment this became the blocker. I moved the site to a different host and installed WordPress as software — the program, not the service. The API key stopped being something a plan could withhold from me.

A second brain through OpenRouter — and why it needs a client

OpenRouter by itself is a router to models, not a connector hub. There is no “connect Notion” button inside it. To let a model from OpenRouter read your data, you need an MCP client sitting between them.

For a non-developer that means a ready-made desktop app with MCP support: you paste your OpenRouter key, then separately connect Notion (and your other tools) through their OAuth flow. The other path is wiring an MCP client yourself in code — roughly a hundred lines, stateful, session-managed — which most people will never do. So “connect Notion through OpenRouter” is true in practice, but the connector physically lives in the client app, and OpenRouter only supplies the brain.

Make the model swappable: any AI, one prompt

The point of routing through OpenRouter is that the brain becomes a commodity. One key reaches hundreds of models — Claude, DeepSeek, and the rest — and you switch between them at will.

This inverts the usual dependency. People get attached to a model: mine, my favorite, scared to lose it. Here the model is the disposable part. What’s irreplaceable is the surface — the memory plus the hands. If one model degrades or one channel closes, the surface stays; you drop in another brain with the same boot prompt. On ground that keeps disappearing, that is the actual stability: you don’t cling to one board, you shift your weight to the one still holding.

With one caveat an engineer will want stated: “any model, one prompt” holds as a principle, not as plug-and-play. Models differ in how they hold long instructions and how reliably they honor a confirmation step, so each swap needs a little tuning. The surface stays; the brain slots in; you adjust the fit.

The actual stack (for the technical reader)

Here is the stack with no metaphors:

1. Assistant — a capable model driven through a client that supports MCP connectors.
2. Memory — Notion, connected as a remote MCP server over OAuth.
3. Hands to the site — a WordPress connector for publishing and maintenance.
4. Mail and files — Gmail and Drive connectors.
5. Backup brain — OpenRouter (crypto, pay-per-token) feeding the same MCP client.

And Mark, this is the direct answer to your tool-calls problem: a local model in LM Studio makes tool calls when an MCP client drives it and presents the tools in the format the model expects. The model doesn’t call anything on its own — the client orchestrates the call, the model decides which tool and with what arguments. No client, no tool calls.

Local models add a second catch — it’s the usual reason tool calls won’t fire locally. Running GEMMA in LM Studio, two things have to line up. First, your client has to point at LM Studio’s local OpenAI-compatible endpoint — that’s where the tools get wired in. Second, and this is the usual culprit, the model build itself has to support function calling. Not every local model or quant is trained to emit tool-call output; if it isn’t, no client can force it. With cloud models the brain already knows how to call tools and you only add the client; with local ones, check the model card for tool-use support first — often the gap is the model, not the wiring.

The security cost no one mentions

Giving an AI write access to your email and website opens an attack surface — say it plainly, because most guides don’t. A model with permission to publish or send can publish or send the wrong thing, and a connector token sitting in a client is a credential to protect.

So scope the connectors down to what each task needs — read-only wherever you can — and keep a confirmation step before any write action on a live site. This isn’t paranoia. It’s the price of autonomy, and the price is cheaper than the cleanup.

The one thing I never automate: translation

I do not automate translation for publication — any translating model can drop a line silently. The machine prepares everything up to the final step; the publish button on a translation gets pressed only after a line-by-line check.

The reason is specific, not precious. I’ve had a translator quietly delete a line, and it only surfaced later. A published mistranslation isn’t an inconvenience — it’s my voice saying something I didn’t say, and not hearing it. That is the one lever a human keeps a hand on. Not from distrust of the machine — from knowing that one silently dropped line costs more than all the mechanics it saved.

Copy-paste: the prompt that turns any model into this assistant

Here’s the starter prompt I give a model to make it run as this kind of assistant. It’s model-agnostic — paste it into whatever brain you’re driving through your client, fill the brackets with your own stores and connectors, and adjust.

You are my operations assistant. You run my site, mail, and files on command — not as advice I then execute, but as actions you take through your connectors.

MEMORY (external):
- My working memory lives in [Notion / your store], not in this chat. Before answering anything, check it first.
- Never hold the whole archive in context. Fetch only what the task needs.
- Mirror saved versions across [Notion, Google Drive, GitHub] so no single platform can take my memory with it.
- At the end of every session, when I say "log this session," write a summary back to memory.

HANDS (connectors):
- You have connectors to my site [WordPress REST API], [Gmail], [Drive], [GitHub].
- Act directly through them on command: draft, publish, edit, file, maintain.

SAFETY:
- Use read-only access wherever the task allows.
- Before any write action on the live site, or any send, state exactly what you're about to do and wait for my confirmation.
- Scope every credential to the minimum role the task needs.

TRANSLATION:
- Never publish a translation on your own. Prepare it, but the publish step waits for a line-by-line check by me.

ACCESS:
- I may reach you through more than one channel (a subscription app, or a router paid per token). Behave identically on each.

First, confirm you've read my memory store. Then ask what I need.

That’s the whole combine in one block: external memory, mirrored storage, hands on the site and mail, a hard stop before any write, and the one lever — translation — kept under my hand.

One engineering caveat, because the prompt alone can’t enforce it: those lines are intent, not control. A weak or stubborn model can ignore “wait for confirmation.” The real stop before a live write has to live in the client or the connector — a scoped credential, a human approval gate — not in the wording. Treat the prompt as the instruction and the tooling as the lock. Swap the brain underneath it and the prompt still holds as a skeleton — though each model needs a little tuning to follow it cleanly.

Why I built it this way

I built this for the case where my own website becomes unreachable to me. An assistant with a channel that doesn’t die when mine does can reach my infrastructure when I can’t. Users who work this way are few — and that scarcity is exactly the reason the architecture is shaped the way it is.

If you’re standing on ground that keeps closing under you, don’t build one door and call it safety. Build the surface — memory, hands, a swappable brain — and keep your own hand on the one lever that can publish in your name.

Frequently asked questions

How do I reduce Claude’s token usage?

Move your standing context out of the chat and into an external store like Notion, then have the assistant fetch only what it needs per question instead of reloading everything. Avoid keeping large, rarely-changing files inside a Project, since project content is re-fed into context on every reply.

Can I pay for AI with cryptocurrency?

Yes. Routers like OpenRouter let you top up with crypto and pay per token, with no card-based subscription. This gives you a second access channel that doesn’t depend on a card clearing.

How do I connect an AI assistant to WordPress?

Through a connector (MCP) that exposes your site’s publishing actions to the assistant. Once connected and scoped, the assistant can draft, publish, and maintain posts on command. Keep a confirmation step before any live write.

Why won’t my local LLM make tool calls?

Because the model alone doesn’t call tools — an MCP client has to drive it and present the tools correctly. Add a client layer (a desktop app with MCP support, or a coded MCP client) and the same local model starts calling tools.

Can I use any AI model with one setup?

Yes. Routing through OpenRouter gives one key access to many models, so you can swap the underlying model without rebuilding your memory and connectors — the surface stays, the brain is interchangeable.

Should an AI assistant have full access to my email and site?

Only with scoped permissions. Use read-only access where possible, limit write scopes, and require confirmation before destructive or publishing actions. Write access is an attack surface, not just a convenience.