You're the Human API Between Your AI Tools

The complaint showed up in a side-project forum, written by someone who doesn't even code for a living:

"I run Claude and Codex on the same project, one writes the spec and the other reviews it, and I'm the one copy-pasting reviews back and forth."

A few weeks later, on a Show HN thread, a builder said the same thing from the other side of the desk:

"AI coding agents learn your project conventions, parameters, and lessons during a session. Then the session ends and it's all gone. Switch to a different agent and you re-explain everything."

Two different people, two different setups, one shared job description. Neither of them applied for it. They set out to build software with AI help and ended up as the integration layer: the human API translating context from one tool into another, one clipboard at a time, every single day.

If you use more than one AI tool, you know this job. You just haven't named it yet.

The switching tax, itemized

The tax has three line items, and only the first one is obvious.

The obvious one is time. Every session starts with a briefing. The project layout, the conventions you settled on, the thing you decided last Tuesday and already forgot you decided. Twenty minutes here, ten minutes there, and by Friday you've spent a full working session just getting your tools up to speed on things they knew last week.

The second is quality. Context doesn't survive the clipboard. You copy the review comments from Codex into Claude, but you leave out the three follow-up thoughts you had while reading them, because who copies their own thinking? The next tool gets a flattened version of the truth and makes decisions on it. Nobody notices until something ships wrong.

The third is the sneaky one: you stop switching. The tax gets high enough that you quietly give up on the multi-tool setup and just use one tool for everything, even the jobs it's worse at. You keep paying for four subscriptions and using one. The tools didn't fail you. The friction between them did.

Workaround 1: the human bridge

This is the default, and it's what both quotes describe. You are the context pipeline. You read the output in tool A, summarize it in your head, and paste a version of it into tool B.

For a single review loop, honestly, this works. It's free, it's immediate, and you stay in the loop on everything. The problem is scale. Two tools and a weekend project? Fine. Three tools, a real codebase, and decisions that need to survive longer than a session? The bridge becomes a full-time job, and it's the most boring job you've ever had: reading, summarizing, pasting. You bought AI to do less of exactly this.

There's also a quieter cost. When you're the bridge, you become the bottleneck for your own judgment. The review that gets pasted is the review you bothered to copy. Your tools never see the parts you decided weren't worth the effort, and you never get a second opinion on the parts you filtered out.

Workaround 2: config files in every repo

The developer answer to the switching tax is files: CLAUDE.md for Claude Code, .cursorrules for Cursor, AGENTS.md for the rest, and bridging setups like the .stato/ modules from that Show HN thread that let you write the conventions once and fan them out to every tool.

This is genuinely good at what it does. Project conventions are the perfect thing to put in a file: folder structure, lint rules, which framework version, "always use strict mode," "the auth middleware lives here." Write it once, every tool reads it, done.

But conventions are not context, and this is where the workaround hits its ceiling. A config file knows your folder structure. It does not know that you tried the Redis cache, hit a cold-start problem, and ripped it out on Tuesday. It doesn't know why the onboarding flow has that strange three-step confirm (because legal asked for it, and you will forget this in a month). It doesn't know which of last week's decisions are still true.

And files drift. You update CLAUDE.md after a refactor, forget the .cursorrules copy, and now your tools are working from two different truths. You have automated the briefing and introduced a new maintenance job: keeping the briefings in sync. Sound familiar? That's the same shape as the original problem, just moved.

Workaround 3: pick one tool and never leave

The nuclear option. One tool, no switching, no tax. Claude for everything, or Codex for everything, or Cursor for everything.

This does kill the tax completely, and some weeks it's the right call. But you're making a tradeoff most people don't price honestly: you're letting the tool choose your workflow instead of the other way around. Codex reviews code better than most. Claude reasons through architecture better than most. Cursor's inline editing is genuinely faster for certain work. The best tool for the job changes by the month in this market, and a one-tool policy means you find out about that six months late.

There's also a subtler version of the lock-in problem that has nothing to do with pricing or features. A founder in one of these threads nailed it: try a new tool and it's noticeably worse, not because the model is worse, but because it doesn't know you yet. The lock-in is context. Staying with one tool because leaving means re-explaining everything is not loyalty. It's Stockholm syndrome with extra steps.

Workaround 4: the kickoff brief

Some people write a big context dump at the start of every session: the current state of the project, the open questions, the decisions so far. Paste it in, work for two hours, done.

This works for about one session. Then the session produces new decisions, new dead ends, new context, and the brief is stale. You're back to being the bridge, except now you're also maintaining a document. The brief rots at exactly the rate your project moves, which is to say: fast enough that maintaining it is a job, slow enough that you keep telling yourself it's fine.

Workaround 5: one memory every tool reads

The last option is the one that actually removes the human from the integration path: a shared memory layer that sits underneath the tools instead of inside any one of them. The idea is simple. Your conversations, decisions, rules, tasks, and reusable procedures live in one place, and every AI client you connect reads the same memory. Plan in Claude, build in Codex, review in Cursor. Nothing gets re-explained because nothing was ever trapped in one tool's session in the first place.

This is the MCP memory approach, and I'll name one product here because it's the one whose tradeoffs I know cold: Vilix AI. It stores your full conversation history, not just extracted facts, plus projects, tasks, rules, and reusable agent skills, all readable from any connected AI client. When two tools save conflicting info, the newest write wins, so correcting something in one place corrects it everywhere.

Now the honest part, because a memory layer is not free in any sense of the word. It's cloud-hosted, which is an instant no if your context legally can't leave your machine. Each client needs its own setup and approval; connecting one doesn't configure the others. It doesn't import your old chat history, so day one is still a blank slate. And past the free plan it's a subscription: Starter at $10 a month, Pro at $20 a month or $200 a year, Power at $49 a month or $469 a year. There is a 7-day Pro trial with no credit card, which is the right way to find out whether the switching tax is actually your problem or whether config files were enough all along.

It's also worth saying what a memory layer doesn't do: it doesn't make your tools smarter, it doesn't write better code, and it won't fix a workflow where the real problem is that nobody knows what the project is supposed to do. It fixes exactly one thing, the context tax between tools, and you should only pay for it if that's the tax you're actually paying.

The honest answer

Match the fix to the pain you're actually feeling.

If the pain is "every tool needs to know my folder structure," config files solve it. Write CLAUDE.md once, bridge it, move on. If the pain is one review loop between two tools on a weekend project, the human bridge is fine, and anyone telling you to buy infrastructure for that is selling you something.

But if you're living across tools every day, re-explaining decisions that were settled weeks ago, copy-pasting reviews like it's 2015 and you're moving Jira tickets by hand: that's the tax. And the only fix that removes it, rather than moving it somewhere else, is getting your context out of the tools entirely and into one place they all read from.

Whatever you do, stop pretending the copy-paste is free. It was never free. You're just the one paying it.