Operations | Monitoring | ITSM | DevOps | Cloud

This one is for the curious souls who wonder how somebody actually builds a harness optimizer — and, more to the point, how they know it works. When we launched JFrog Boost into public preview, we told the story of the bill that broke us and the 100 billion tokens we clawed back across JFrog R&D. What that post didn’t cover is the question that consumed most of our engineering time: how do you measure any of this?

Teams running containerized workloads on Google Cloud have long relied on JFrog as their single source of truth for container images. The missing piece has been getting Google Cloud’s own runtime services — like Cloud Run and Google Kubernetes Engine (GKE) — to pull directly from JFrog for every container image pull. I’m happy to say that the gap is now closed. Artifact Registry in Google Cloud has introduced a new repository mode called Connector that addresses this requirement.

Software supply chain engineering has reached a critical inflection point. As autonomous AI coding agents transition from generating autocomplete suggestions to planning, writing, reviewing, and deploying entire software pipelines without humans in the loop, the connection between human intent and production binaries is fracturing.

Model routing promises to cut your AI agent spend by offloading routine tasks to cheaper models like Claude Haiku while reserving frontier models like Claude Sonnet for complex reasoning. In the right configuration, routing strategies can reduce inference costs by 40–85%. But if you implement routing incorrectly in a multi-turn agent, you can end up paying more than if you’d never routed at all. Here’s why and how to fix it.

Using JFrog CLI used to come with a catch. To run a build through it, you had to put it in front of the command. For example, jf npm install instead of npm install or jf mvn package instead of mvn package per the example below: npm install → jf npm install mvn package → jf mvn package Doing that once is easy enough.

AI agents are part of the modern development workflow. They write code, review pull requests, generate tests, call tools, interact with MCP servers, and help developers move faster. But behind every useful agent, there is something just as important as the model itself: the context that tells the agent how to behave. That context can include skills, prompts, instructions, hooks, commands, scripts, references, and MCP server definitions. In a small project, managing these primitives is pretty simple.

Today, we’re excited to announce that Boost is moving out of beta and into public preview. After months of building, breaking, and rebuilding inside JFrog’s own R&D organization, Boost is ready for the world. If you are currently running into token limits, unpredictable costs, or runaway usage from AI agents, Boost was built for you. It has already helped our teams reduce token spend while maintaining performance.

AI agents are changing how software gets built, but the infrastructure around them hasn’t caught up. Agents burn through tokens on noise. They take actions they shouldn’t. Context evaporates between releases. And most delivery pipelines were never designed for the pace and volume of agentic development.

Machine learning models are not like other software artifacts. A single fine-tuned LLM can weigh 70 GB. A model family may share 95% of its weights across dozens of variants. When hundreds of developers, training jobs, and GPU clusters all need the same model at the same time, the infrastructure underneath needs to be built for it.

Your developers install agent plugins every day: pulling from unmanaged GitHub repos, copying Cursor commands out of Slack, pointing Codex at a personal Git fork. Each of those is a new, uncontrolled distribution channel inside your software development lifecycle, and your platform team has zero visibility into any of it. A plugin is not a preference file. It is executable software, and right now it’s arriving on developer machines with no versioning, no provenance, and no audit trail.