GitLab 19.4 adds goal-driven agents and stricter cost controls

GitLab released version 19.4 of its DevSecOps platform on September 17, 2026, according to InfoQ. The main news is a goal-driven mode in GitLab Duo CLI, along with three hosted open-weight models, more tools via Model Context Protocol (MCP), and much more granular spend control. The story matters less for the announcement itself and more for what changes in the routine of those who already use GitLab Duo for code review and dependency remediation: the platform now lets an agent work without line-by-line supervision, but within the same permission and approval rules the project already had.

From a Single Prompt to an Open-Ended Goal

Until now, Duo responded to one-off prompts or followed predefined flows. With 19.4, the new /goal command in Duo CLI accepts an open-ended goal and keeps iterating until it completes the task or hits an iteration limit. The architecture uses two models: one implements the changes, the other checks progress against the goal stated in natural language.

Developers can interrupt execution, change the goal midway, or redirect the agent. Everything runs locally and keeps the context and controls the project already had configured. According to Manav Khurana, of GitLab:

This release takes agentic automation from something individual developers use to something an organization can scale at speed and under the controls already in place.

Manav Khurana, GitLab

A reading caution is worth noting here: the term "verified" used by GitLab is not formal code verification. The second model judges whether the result meets the goal written in natural language, it does not mathematically prove the code is correct. The command can report work it was unable to resolve, and the iteration limit keeps it from running indefinitely. In practice, this means clear acceptance criteria remains the team's job, just described before releasing the agent rather than policed step by step afterward.

Three New Models, No Published Benchmark

Duo Agent Platform gained support for three hosted open-weight models: Kimi K3, MiniMax M3, and GLM 5.3. GitLab states they deliver up to four times more calls per GitLab Credit than many comparable frontier models. Group owners can set a default model per feature and restrict which models each team can use.

In practice, this opens up the possibility of reserving a more expensive model only for tasks where it truly pays off, and using a cheaper model for routine work such as reviewing simple merge requests. The announcement does not include model-by-model benchmark results or an absolute price per call, so the task of comparing real cost against the team's workload remains the customer's, not GitLab's.

MCP: More Tools, Checkpoint Still Default

GitLab expanded the toolset of its MCP server, allowing agents running in third-party clients to trigger and inspect pipelines, open and review merge requests, update work items, navigate repositories, and manage vulnerabilities. The access rule follows a clear pattern:

• Read-only tools come as "Always Allow" by default.
• Write and delete tools come as "Always Ask" by default.
• Administrators can change these rules at the group or project level.

Most MCP tools are available on the Free, Premium, and Ultimate plans; vulnerability management tools require Ultimate. This move follows a broader trend of granting access to external tools without giving up control: InfoQ had already reported in 2025 that Google's Android Studio Agent Mode uses MCP to reach external tools, and GitHub Copilot also supports MCP in its main interfaces, with enterprise policies to control access to servers. GitLab's difference is applying the decision tool by tool and keeping a human checkpoint by default in front of any change.

Cost Becomes the Focus When the Agent Runs on Its Own

When the agent stops depending on a human prompt at every step and starts reacting to events automatically, call volume can scale quickly. ReleaseTEAM, a GitLab partner consultancy, warns about this scenario:

The practical risk is automation.

ReleaseTEAM, GitLab partner consultancy

The consultancy's recommendation is to set usage limits before connecting a flow to a high-volume trigger, such as every pipeline failure or every new merge request, and to measure consumption first in a limited pilot. That makes sense: a flow tied to every CI event can fire hundreds of times a day without anyone noticing until the bill arrives.

To support this control, GitLab now details the credit usage export line by line, per billable event, with user, project, session, flow type, credits, and token count. A new settings page allows setting a default cap per user and adding individual exceptions without needing the GraphQL API. Developers can see their own consumption, while billing managers receive alerts when on-demand usage reaches 50% or 80% of the monthly cap.

Where This Fits in Duo's History

Version 19.4 doesn't appear in isolation. GitLab 19.2 already had agents working on dependency remediation and security reviews, with a person responsible for approving changes. Before that, versions 18.10 and 18.11 introduced automated code review at a fixed price, free access to Duo Agent Platform on the free tier, and monthly credit limits. 19.4 extends that logic to longer development tasks and gives administrators a closer view of the resulting cost.

What Remains Open

The /goal command and the expanded MCP tools remain in public beta; only credit usage visibility has reached general availability (GA). To use /goal, you need to be a Premium or Ultimate customer on GitLab.com, GitLab Self-Managed, or GitLab Dedicated, running GitLab 19.3 or later with Duo CLI 9.17.0 or later. The real cost comparison between Kimi K3, MiniMax M3, GLM 5.3, and frontier models also remains open: without a published benchmark, Brazilian teams that already closely monitor their AI budget will need to run their own tests before switching default models.