GitLab 19.4 Brings Goal-Driven Agents and Tighter AI Cost Controls

Introduction

GitLab 19.4 moves its coding agents beyond one-shot prompt handling. The central change is a goal-driven mode for Duo CLI, which can continue working across multiple iterations instead of stopping after a single response. GitLab is pairing that longer-running automation with more explicit controls for permissions, approvals, model choice, and spending.

Key updates

• Duo CLI gains goal-driven execution. The new /goal command is in public preview. A developer can provide an open-ended objective, and the agent continues until it completes the task or reaches an iteration limit. One model implements changes, while another compares the current result with the natural-language goal. Developers can stop the run, revise the objective, or redirect the agent.
• Existing project controls remain in place. The task runs locally and retains the project’s existing context and control mechanisms. GitLab’s use of “validation” should not be read as formal verification: the second model judges whether the outcome appears to satisfy the stated goal. Clear acceptance criteria therefore remain important, and unresolved work is reported when the agent cannot complete it.
• More hosted open-weight models. The Duo Agent Platform now supports Kimi K3, MiniMax M3, and GLM 5.3. GitLab says these models can provide up to four times as many calls per GitLab credit as some comparable frontier models, but the announcement does not include benchmark results or absolute per-call prices. Group owners can set a default model and restrict the models available to teams.
• MCP access is more granular. The expanded GitLab MCP server lets agents trigger and inspect pipelines, open and review merge requests, update work items, browse repositories, and manage vulnerabilities. Read-only tools default to “always allow,” while write and delete actions default to “always ask.” Administrators can change these policies at the group or project level. Vulnerability-management tools require the Ultimate tier.
• Usage data is easier to attribute. Credit exports now record each billing event as a separate row with the user, project, session, workflow type, credit count, and token count. Owners can configure default per-user limits in the settings interface and override them for individual users. Billing managers can also receive alerts when on-demand usage reaches 50% or 80% of a monthly limit.

Why it matters

Goal-driven execution may reduce the need to supervise every intermediate step, but it does not remove the need for oversight. A vague objective gives the checking model little to work with, and “validation” remains a judgment against a natural-language description rather than a proof of correctness. Teams should also be cautious when connecting agents to high-frequency pipeline or merge-request triggers, where repeated automation can accumulate usage quickly. Small pilots and explicit caps remain sensible safeguards.

The broader direction is clear: GitLab is trying to make agents fit inside existing DevSecOps governance instead of creating a separate automation layer. Models and tools can expand, but permissions, approval checkpoints, and consumption records need to stay manageable. In 19.4, longer-running development tasks are paired with more practical administrative visibility. The /goal command and enhanced MCP tools are available in public preview to eligible Premium and Ultimate customers on GitLab.com, self-managed GitLab, and GitLab Dedicated.

Source: InfoQ 中文