GitLab 19.4 made per-user credit caps generally available and added a trigger that starts an agent flow whenever a human opens a merge request. Budgets and automation shipped in the same release.
Triggered flows run under a composite identity, a human plus a service account. The credits docs attribute usage to "the subject who performs the action," which can be a service account. Nothing in the docs says which cap a triggered flow counts against.
Before you rely on per-user caps, fire one test trigger and find its row in the new per-event export. Then treat the subscription-level cap as the ceiling that actually holds.
What shipped on 17 September
GitLab 19.4 is mostly a cost release for the Duo Agent Platform. Three GitLab-hosted open-weight models arrived, GLM 5.3, Kimi K3 and MiniMax M3, pitched as up to four times more calls per credit than frontier models. Admins can now pick a separate model for the Developer Flow. And the credits dashboard went GA with two things finance teams have been asking for since credits replaced seats.
The first is a Credit caps page. Group Owners on GitLab.com and admins on Self-Managed set "the flat cap that applies to every user by default," then add per-user overrides. When a user burns through their included credits and hits the cap, the dashboard flips them to "Blocked usage" and they lose Agent Platform features until the cap is raised or the month rolls over.
The second is the export. It now returns a ZIP with the daily summary plus "a per-event file with one row for each billable event," with product, flow type, session, user, namespace, project, credits used and token counts per row. That file matters more than the caps, for reasons below.
The same release quietly added a new trigger action: Merge request, Created. Pick a flow, pick a service account, and every new MR in that project starts it.
Two identities, one bill
Triggered flows don't run as you. They run as a composite identity. GitLab's docs describe a token built from two parts, the human who kicked it off and a service account with the Developer role, with access limited to whichever of the two is more restrictive. Commits and audit entries are attributed to the service account. The MR the flow creates still shows the human as author.
That design is good for permissions. It is ambiguous for money.
The credits page says usage "is attributed to the subject who performs the action," and defines a subject as "either a human user or a non-human subject (for example, a service account or a bot running an automated flow)." The caps page talks about users. The triggers page doesn't mention credits at all. I read all three and could not find a sentence that says whether a flow fired by Priya opening an MR draws down Priya's cap, the service account's cap, or neither.
Each answer has a different failure. If it lands on Priya, a busy week of MRs can lock her out of Agentic Chat on a Thursday, for work she never asked an agent to do. If it lands on the service account, one account now carries every developer's triggered spend, and a flat default cap sized for a human either blocks it in week one or you raise it and it stops being a cap. If it lands on neither, the per-user caps you just configured don't bound the most automated part of your usage.
GitLab did close the obvious loop. The triggers doc says every event type needs "a human user to perform the triggering action," and that a bot, a service account or another flow "cannot activate a trigger." So a flow that opens an MR won't fire the MR-created flow again. The spend scales with your humans, not recursively. It still scales with every MR your humans open, including the one-line dependency bumps.
The price per call is not the price per task
The four-times claim checks out against GitLab's own multiplier table. MiniMax M3 gets 8 calls per credit, GLM 5.3 gets 5, Kimi K3 gets 1.82. Claude Opus 4.8 is 1.1, Claude Sonnet 4.6 is 2, GPT-5.5 is 1, and 0.57 in long-context mode. On-demand credits list at $1 each.
Those are per model call. GitLab defines a request as the billable thing a user does and a model call as what the agent does to fulfil it, and "a single user request might trigger multiple model calls." The agent decides how many. A cheaper model that needs three extra loops to get the same MR review right has not saved you much, and you only find out in the export.
Some flows skip this entirely with flat pricing. The Code Review Flow costs a quarter credit per execution on GitLab-managed models, regardless of how many calls it makes inside. Put that on the MR-created trigger and the math is simple: 25 cents per merge request. A team opening 400 MRs a month spends $100 on reviews, which is fine. The same trigger wired to a custom flow on variable pricing has no such floor or ceiling.
One more promo to watch: Gemini 3.6, 3.7 and 3.8 Flash sit at 6.7 calls per credit "through December 31, 2026," then drop to roughly 3.3. If you pick your Developer Flow model on today's table, put a reminder in January.
Caps lag, by design
GitLab is upfront about this one. "Caps are enforced using the most recent usage data available. Because data is not real time, limited additional GitLab Credits usage may occur before enforcement takes effect."
For a developer chatting with an agent, that overshoot is noise. For a trigger attached to a busy repository, it is a window where flows keep starting after the budget says stop. The subscription-level cap has the same delay, but it suspends credit-based features for everyone on the instance, so it is the one number that genuinely bounds the month.
What I'd do this week
Fire one test. Create a throwaway project, attach a cheap flow to Merge request, Created, open an MR as a normal developer, and wait for the next export. Look at the user column on that row. That tells you, for your instance and your version, whose budget triggered flows spend. It beats waiting for the docs to say it.
Set the subscription cap first. Per-user caps are for fairness between people. The subscription cap is what stops a surprise invoice. Size it from the per-event export, not from seat count.
Give triggers their own service accounts. One service account per triggered flow, or at least per team, turns the user column in the export into a cost line per automation. If attribution does land on the service account, you can then cap each one on purpose.
Prefer flat-priced flows on high-volume triggers. A quarter credit per review is a number you can put in a budget. A custom flow on variable pricing attached to every MR is a number you learn after the fact.
Check the new tool rules while you're in settings. 19.4 also moved GitLab MCP server tools under the same allow and ask controls as internal tools. Read-only tools default to Always Allow, write and delete tools default to Always Ask. A triggered flow has no human watching for the ask, so decide what that default means for flows that run on their own before you turn the trigger on.
The caps are real progress. Until this release, agent spend on GitLab was a single number at the end of the month. Now it is a row per event with a user on it. Make sure the user on your triggered rows is the one you meant to budget.