In public sector and government projects one question comes up again and again: can we do this without sending anything to a cloud AI provider? With Infinity 26 and the new agentic authoring capabilities, that question now extends to development itself. So I spent an evening testing how far you get with a local open-source model, a local coding agent and Pega’s own Infinity AI Plugins.
Short answer: it works. A local model running on a laptop can read a live Pega application through the official MCP server and change a rule in it, through a proper ChangeRequest with branch isolation and human approval. Everything in the chain can be open source or free of charge.
My laptop was just the smallest possible version of the setup. In a real government deployment the models would sit on properly dimensioned GPU servers inside the organisation, published through an open-source LLM gateway over the same OpenAI-compatible API this test used locally. The wiring below does not change — only the address the agent points at, and the size of the model behind it.
Starting point
A MacBook Pro (M1 Pro, 32 GB unified memory), a Pega Infinity 26.1 environment, and no prior experience installing a local LLM. Budget: zero — free tools only. The Infinity environment ran on Pega Cloud, but could equally run fully on-premise; this test was only about the other end of the chain.
1. Choosing a model
Research pointed consistently at the Qwen family as the strongest open-weights option here — good tool-calling and MLX builds optimised for Apple Silicon. I installed three, all 4-bit: Qwen3.5 4B for fast drafts, Qwen3.5 9B as the everyday default, and Qwen3.8 27B for accuracy — the one that did the Pega work.
2. Using an AI assistant to do the install
I used Claude Code to drive the installation and configuration. Not a requirement — every step below can be done by hand, and if the point is to avoid cloud AI entirely you would do exactly that. But it removed a lot of trial and error.
3. Choosing a runner: LM Studio
The real choice here is the inference runtime, not the app. On Apple Silicon two matter: Apple’s MLX, built for unified memory, and llama.cpp, the portable GGUF workhorse — almost everything else wraps one of them.
I chose LM Studio: free for personal and commercial use, ships both runtimes, and exposes an OpenAI-compatible server on port 1234 — so any tool that speaks the OpenAI API can talk to it, with a GUI for the settings that are genuinely fiddly. The trade-off is that it is closed source.
Ollama is the main alternative: open source, one-line install, the largest model library, also OpenAI-compatible. On Apple Silicon you give up the MLX speed advantage, but for government customers it is very likely the better choice — being open source, it can be reviewed and approved in a way a closed binary cannot.
4. Choosing a coding agent: opencode
Any terminal coding agent that speaks the OpenAI API can be pointed at a local model — but the choice of agent matters a great deal when the model runs locally. Agent frameworks are designed against hosted models, where a large system prompt costs a few cents. Locally it costs you most of your working memory. Qwen Code, which I started with, sends roughly 26,000 tokens before you type anything, and hides MCP tools from the model once they grow past a share of the context window — which the 29 Pega tools did. The model therefore never saw them, and reached for shell commands instead.
opencode — fully open source, provider-agnostic, with first-class local-model support — hides nothing and its base prompt is far leaner: 16,533 tokens with all 29 Pega tools visible, against roughly 35,400 for Qwen Code with the tools forced visible. Same model, same tools, same machine — and half the window now stays free for the actual conversation.
That constraint is a property of running at the smallest possible scale: with a model configured for a bigger context window — which simply means more memory — the Pega tools would have stayed visible in Qwen Code as well.
Wiring it up is a few lines in ~/.config/opencode/opencode.jsonc: opencode already ships an lmstudio provider pointed at 127.0.0.1:1234, so you only declare the model, set a realistic context limit and raise the request timeout. No API key, no account, no traffic leaving the machine.
5. Installing the Pega Infinity AI Plugins
Pega publishes infinity-ai-plugins on GitHub: an MCP server that exposes Pega authoring as tools any MCP-capable agent can call. It is a Java stdio server, so the integration is one entry in the agent’s config plus a Java 21 runtime.
The repository ships parallel folders for Claude Code, Codex, Copilot and opencode. A few points are worth noting before you start:
· Only the Claude folder contains the substantial resources — the MCP jar and the skill packs — so the opencode configuration has to reach across into claude/resources.
· PEGA_BASE_URL must be the environment root without /prweb — with it, every remote call returns 404. And carry PEGA_OAUTH_CLIENT_ID over from the Claude or Codex variant: it is absent from the opencode config, and without it every call is unauthorised.
· Raise the MCP start timeout, and set PATH explicitly in the server’s environment block — agents spawn the server with a bare environment, so it otherwise finds the system Java stub instead of your JDK.
6. Connecting to Pega Infinity 26 and first tests
With that in place the connection came up: 29 Pega tools exposed and the skill payload for Infinity 26.1 loaded. In a single turn the model issued three calls in parallel against the live environment — get-application, get-rule and list-rules — and read back real application data.
opencode connected to a local Qwen model and the Infinity AI Plugins MCP server
Then the real test: change the goal on a service-level rule in a running application. The model ran that end to end — 43 tool calls, one user decision in the middle, one human approval at the end — following Pega’s own ChangeRequest workflow in an isolated branch. Three things are worth reporting:
· It loaded the methodology before it touched anything. Nine skill lookups — the ChangeRequest workflow, the rule schema, a worked example — before it went looking for the rule. That is what the skill payload is for: the discipline lives in the documents, not in the model.
· It found a problem nobody asked it to look for, and stopped. The rule was internally inconsistent, and the change as requested would have put the soft goal after the hard deadline. It said so and asked for confirmation instead of doing the literal thing.
· It did not stop at “done”. Afterwards it checked whether the change was really in the application and reported the branch as uncommitted rather than declaring success — approving a ChangeRequest completes the case but does not promote the branch.
Learnings and recommendations
· Tool design matters more than model size. Given generic filesystem tools, the same model narrated a plan and called nothing. Given 29 well-named, single-purpose Pega tools, it chained three correctly in one turn.
· Restrict the blast radius, not the model. A small local model could safely rewrite a rule in a live enterprise system because of the ChangeRequest workflow: branch isolation, required human approval, full audit trail. That is the pattern to insist on, whatever model you run.
· This was about feasibility, not performance. The point was to show that local open-source models and a local open-source coding agent can drive Pega authoring at all. Model quality and the hardware behind it turn that into something a development team would actually work with.
Conclusion
Agentic development of Pega applications with a fully local, fully open-source stack is possible today: an open-weights model on your own infrastructure, an open-source coding agent, Pega’s official Infinity AI Plugins as the MCP server, and a real Infinity 26 environment on the other end. For customers who cannot use a cloud AI provider — in the public sector often a requirement, not a preference — that is a meaningful result.