Model-free browser automation: never rebuild because a vendor changed
Why a browser agent should treat the model as a setting, how to keep a workflow portable across cloud and local models, and what vendor lock-in actually costs.
Model-independent browser automation keeps the workflow, tools, context and approvals separate from the model that reasons over them. The model becomes a per-task setting rather than the architecture, so a price change, a rate limit, or a deprecated API cannot force a rebuild. Melaya supports connected cloud providers, local Ollama and LM Studio models, and CLI subscriptions such as Claude Code and Codex.
What vendor lock-in costs in practice
A browser agent bound to one model inherits that vendor’s pricing, rate limits, regional availability, content policy and roadmap. None of those are under your control, and all of them change. The workflow is the asset; the model is a component that should be replaceable.
The cost is rarely the licence. It is the rebuild: when the terms change, the integration, the prompts, the tool wiring and the approvals all have to be redone against a different surface.
- Price rises apply to work you already built
- Rate limits stop a workflow that used to run fine
- A deprecated model version changes behaviour you had tuned
- Regional or policy restrictions can remove access entirely
Separating the workflow from the model
Keep four things independent of the model: the tools an agent may call, the context it operates with, the approval points, and the record of what happened. If those live in the runtime rather than in a vendor’s product, changing model is a dropdown rather than a project.
Melaya is built that way. The same browser task runs on a connected cloud provider, on a local model through the Melaya Runner, or through a Claude Code or Codex route, with the same connectors, standing context, tab scope and approvals around it.
When local models make a workflow free at the margin
A local model on your own machine has no hosted per-message meter. For recurring browser work this changes the economics: the marginal cost of a run is your electricity, not a per-token bill. Local inference is still bounded by your hardware, the model’s context window, its speed, and your Melaya plan entitlements, so it is not literally unlimited.
The practical pattern is mixed: a fast hosted model for routine extraction, a stronger hosted model for a difficult page, and a local model for the repetitive job that runs every day.
Frequently asked questions
Can I run browser automation with a free local model?
Yes. Connect the Melaya Runner and select a model served by Ollama or LM Studio. There is no hosted per-message meter, though runs are still bounded by your hardware, the model context, and your plan.
Can I switch model without rebuilding the task?
Yes. The tools, connectors, standing context and approvals live in the runtime, so the model is a per-task choice.
Does model choice change what the agent can do in the browser?
The available browser actions are the same. A stronger model handles ambiguous pages and long multi-step tasks more reliably.
