AI Test Automation Without Vendor Lock-In: Cloud, Local and MCP

AI test automation without vendor lock-in: use a cloud model with your own key, a local AI model we provide or you bring, or no AI, and let any assistant drive your tests through MCP.

11 min readBy the GUI Test Studio team

What vendor lock-in looks like in AI test automation

AI test automation promises tests that build themselves, heal themselves and explain their own failures.It also raises a question older testing tools never asked: whose AI, running where, and paid for how?Many tools answer it for you.

Vendor lock-in is what leaving a tool costs you.In test automation it is counted in tests: if switching tools means rebuilding every test, you are locked in.AI adds new places for lock-in to hide.

Where the lock-in sitsWhat it costs your team
Tests stored in the vendor's workspaceLeaving means writing or recording every test again.
Runs that need the vendor's cloudInternal apps behind your firewall are hard to reach, and every screen your tests see leaves the company.
One AI model, chosen by the vendorIts price, its updates and its retirement date become your tests' price, updates and retirement date.
AI features billed by usageEvery run has a cost you do not set, and a busy release week costs more.
One assistant, built into the toolYour team already works in Claude, ChatGPT or Copilot, and the testing tool speaks to none of them.

None of these is a flaw on its own.A hosted service saves you machines, and a bundled model saves you a decision.The problem starts when you cannot choose otherwise.

AI is now part of most testing tools.Testim describes AI-driven smart locators that heal themselves, and runs tests on its cloud or on Selenium-compatible grids.Applitools lists multi-tenant public cloud, dedicated cloud and on-premises deployments for its Eyes server. mabl offers an MCP server through which AI clients such as Claude, Cursor and Copilot can check results and author tests in mabl.

Open-source libraries such as Selenium and Playwright keep you away from any vendor's cloud.Their cost is developer time: you write and maintain a selector for every element, in code.For these tools side by side, see the comparison study.

Why AI test automation is becoming modular

Software is becoming modular.You pick your editor, your AI assistant, your CI server and your bug tracker, and you expect them to work together.

Modular test automation applies that idea to testing: every part of the tool that depends on someone else is a module you plug in, and can unplug.Elsewhere the phrase also names a way of splitting test scripts into reusable parts.Here it means the tool itself.

Your AI model

Cloud, local or none

Your assistant

Claude, ChatGPT, Copilot or none

Your tests

Files on your own disk

Your pipeline

Any CI server, any tracker

Three open interfaces make it possible today.An OpenAI-compatible API lets one tool talk to many models, in the cloud or on your own computer.The Model Context Protocol lets any AI assistant use a tool's actions.Exit codes and JUnit files let any CI server read a test run.

The three AI choices a QA team should have

A testing tool that respects your choices offers at least three ways to use AI.Each one fits a different team, and many teams use more than one.

1. A cloud model, with your own key

Bring your own key, BYOK, means the tool calls an AI provider with your own account's key.You pick the model, you pay the provider directly at its own prices, and the data travels under your own agreement with it.

Cloud models give the most accurate answers today, especially for small text and fine measurements.Developer tools are moving the same way: GitHub Copilot, for example, lets you or your organization configure your own model provider.

2. A local model, on your own computer

A local model, or self-hosted AI, is an AI model that runs on your own hardware: one the tool provides, or one you bring through a local server such as LM Studio.Nothing leaves the computer, and there is no key, no account with an AI company and no cost per check.

Many capable models are published with open weights under permissive licenses such as Apache 2.0, so they can be downloaded and kept.The price is hardware: a graphics card with enough memory makes the difference between seconds and minutes.

3. No AI at all

AI should be an option, never a dependency.Some teams are not allowed to send anything outside, some have no graphics card, and some simply want verdicts that never depend on a model.

A sound testing tool records, finds, compares and reports without any model.The AI then becomes a second opinion on top, for the failures that need judgment.

Is local AI good enough for testing?

Local AI for testing is useful today, with honest limits.

For explaining a failed check, a local model tells you reliably that a label or a color changed.For tiny text, or a change such as "moved 4 pixels to the left", a cloud model is the better reader.

Speed follows the hardware.On a good graphics card a local model answers in a few seconds; without one it can take a minute or more per check.

For creating a whole test from a prompt, a local model is slower than Claude or ChatGPT and works best with short workflows.

A local model is also stable in a way a cloud model is not.It is a file on your disk, and it changes only when you choose another one.

ExampleTwo teams, two choices

A team testing an internal banking app runs AI Smart Verification on a local model, so the customer data on its test screens never leaves the build machine.

A team testing a public website uses a cloud model with its own key, for the sharpest reading of small text.Both run the same kind of test, and either can switch tomorrow.

Where screenshots, videos and AI requests go during a test run, and what privacy rules ask of them, is the subject of data privacy in test automation.

What is an MCP server for testing?

The Model Context Protocol, MCP, is an open standard that lets an AI assistant use the tools of another program.Anthropic introduced it in November 2024 and published it as an open-source project.

An MCP server is the program's side: it lists its tools, and any MCP client can call them.An MCP server for testing is one whose tools are testing actions: open an app, click, type, verify, run a test.

Claude Desktop, Claude Code, ChatGPT with Codex, GitHub Copilot in VS Code and Cursor all accept MCP servers.That is why MCP matters for lock-in: the testing tool and the AI assistant become two separate choices.

Microsoft's Playwright MCP, an open-source server under the Apache 2.0 license, lets an assistant drive a web browser through the page's accessibility snapshots, with no vision model.

Ask two questions of any MCP server for testing.What does the assistant get to see?And what is left when the conversation ends?The answer you want to the second question is a test file that runs again, on every build, without the assistant.

How an AI agent fits into a whole development loop is the subject of development with AI agents (ADLC).

How do you check a testing tool for lock-in?

Ask these eight questions before you commit to any testing tool, with AI or without.

AskWhy it matters
Where are my tests stored, and can I copy them?Tests you cannot copy are tests you cannot take with you.
Can a test run without the vendor's cloud?Internal apps, private data and build agents inside your network depend on it.
Which AI models can it use, and can I bring my own key?Your provider, your prices, your data agreement.
Can the AI run on my own computer?Screens that hold customer data may have to stay inside the company.
Can I turn the AI off?A check should still pass or fail on its own, without any model.
Does a passing screen ever leave my computer?Most screens pass, and they have no reason to travel.
Which AI assistants can drive it?An MCP server lets the assistant your team already uses do the work.
Does it fit my CI/CD and my bug tracker without a plugin?Every plugin is one more thing to install, update and trust.

How GUI Test Studio keeps every piece optional

GUI Test Studio is an end-to-end test automation suite for Windows.It tests what you can see on the screen: desktop applications, web applications in any browser, games and more.

You record a test once, or describe it in a prompt, and the GTS Engine + AI finds every element and checks what the screen shows, without a single locator to write.See how the engine finds elements.

Every piece that could tie you to someone else is a choice.

AI Smart Verification: cloud, local, your own server, or off

AI Smart Verification is the AI side of the GTS Engine + AI.When a check fails, it takes a second look, gives the final verdict and says what changed in plain words.It is off until you switch it on.

Your choiceWhat answersWhere your screens go
Off, the defaultThe GTS Engine's own comparison decides every checkNowhere
A cloud model, with your own keyOpenAI or Anthropic, the model you pick in a listOnly the two small pictures of a failed check, directly to that provider with your key, never to us
A local AI modelA model downloaded once, when you ask, and run by GUI Test Studio itself: no key, no accountNowhere
Your own local serverLM Studio or any OpenAI-compatible local server, at its addressTo your own server only

A passing check is never sent.The answer has the same shape whichever model gives it, so you can switch at any time.

On this computer, Set up for me looks at your graphics card and downloads the model it runs best, from open-weight families such as Qwen3.5 and Gemma 4.

A check can also carry AI Instructions in your own words, such as "Ignore changes to the font size": the AI leaves that difference out, and any other change still fails the check.

One settings card: cloud or local, the provider, your key, the model.

Every option is in the AI Smart Verification guide.

Create a test from a prompt, with the assistant you already use

Describe a workflow, and an AI assistant records the test for you.It opens the app or the page, clicks and types for real, verifies as it goes and saves an ordinary test.

The connector is GUI Test Studio's own MCP server, installed with it.Claude Desktop, Claude Code, ChatGPT with Codex and Copilot Chat in VS Code each connect with one click, and any other assistant that takes an MCP connector can use it too.

With no assistant at all, a local AI model on your own computer, one we provide or one you bring, creates the test with the very same tools.

The assistant sees tools, never the engine: how an element is found or compared stays inside GUI Test Studio.Every check is tried on the spot and refused if it could not pass, so a test never starts life with a wrong check.

One prompt, sent to the assistant you choose or to a model on this computer.

Recording the test yourself stays the other way in, and the result is the same kind of test.See Create a test from a prompt.

Your pipeline, your tracker, your design tool

gtr-cli runs any test from a script or a CI/CD pipeline: Jenkins, GitHub Actions, GitLab, Azure DevOps, TeamCity and others.It answers the way a pipeline expects: an exit code, and JUnit, JSON and Markdown files.

The build machine needs a Windows desktop session that stays unlocked, because a test clicks and types on a real screen.

A failed run can become a Jira issue through Jira's own REST API, on Jira Cloud or Data Center, with no plugin on either side.

A Figma design becomes a test through a small plugin inside Figma that saves one file: no account to connect and no key to create.

Tests are files you keep

A test is one .GTS file in a folder you choose, and the results of its runs are saved right next to it.Copy it, back it up, keep it in your repository.

The format is GUI Test Studio's own, and running it needs no cloud.

Your tests, recordings and results stay on your machines.See on-premise test automation.

Questions

What is vendor lock-in in test automation?

Vendor lock-in is what leaving a testing tool costs you.If your tests live in a vendor's cloud, or in a format only its service runs, switching tools means rebuilding them.With AI it also covers the model: a tool tied to one AI provider ties your tests to that provider's prices and changes.

What is an MCP server for testing?

An MCP server for testing is a program that offers testing actions, such as click, verify or run a test, to AI assistants through the Model Context Protocol.MCP is an open standard, so Claude, ChatGPT with Codex, GitHub Copilot and other assistants can all use the same server.GUI Test Studio installs its own.

Can AI test automation run on a local model?

Yes.In GUI Test Studio, AI Smart Verification and test creation from a prompt can both run on a local AI model, one we provide, downloaded once, or one you bring, with no key and no account with an AI company.A graphics card makes it fast; without one it is slow.

Do I need AI to automate end-to-end tests?

No.In GUI Test Studio, AI Smart Verification is off by default, and the GTS Engine's own comparison decides every check.You can record every test yourself and never turn AI on.

Does GUI Test Studio send my screens to an AI company?

Only if you choose a cloud model.Then only the two small pictures of a failed check travel, directly from your computer to OpenAI or Anthropic with your own key, never to us.A passing check is never sent, and a local model, ours or yours, sends nothing at all.

Which AI assistants can create tests in GUI Test Studio?

Claude Desktop, Claude Code, ChatGPT with Codex and Copilot Chat in VS Code connect with one click, and any other assistant that takes an MCP connector can use it too.A local AI model on your own computer, one we provide or one you bring, creates tests with the same tools.

Selenium, Playwright, Testim, Applitools, mabl, Claude, ChatGPT, Codex, GitHub Copilot, Visual Studio Code, Cursor, LM Studio, OpenAI, Anthropic, Qwen, Gemma, Jira, Figma and Windows are trademarks of their respective owners.

Ready to record your first test?

Every feature, for 15 days.

Rather see it on the kind of app you test?Book a free 30-minute call with our team.

Book a demo