PRIVATE BETA
MATE · GITLAB-NATIVE AGENT ORCHESTRATOR

Stop pasting tickets
into chatbots.

Mate is a bot user inside your GitLab. Assign it like any teammate. Get back a merge request — with the permissions you set, the context it needs, and not one new dashboard to log into.

What you get
  • [✓] GitLab.com or self-managed
  • [✓] Hosted or fully on-prem
  • [✓] Your inference endpoint, free tokens
  • [✓] Per virtual coworker, not per dev
gitlab.com / acme / web · issue #482
OPEN BUG AREA:FRONTEND

Pagination breaks past page 10

Opened 4 minutes ago by ondrej


  1. ondrej assigned @mate · just now
  2. M
    AI
    @mate is typing
  3. M
    AI
    @mate commented · 12s

    Reproduced on main@a3f9d1c. The offset is hardcoded to page * 10, but the API expects (page - 1) * size since the v2 cutover. Patch in !1284.

  4. MR · DRAFT !1284 3 files · +12 −4
    Fix pagination offset for v2 list endpoints
    + return (page - 1) * size;
    return page * 10;
↑ Fig. 01 — an issue and its assignee, no compositing
§ 01 / The cost of context loss

The interesting half of your backlog is sitting there because nobody wants to start it.

It isn't because nobody is capable. It's that starting requires reassembling context that's already scattered across four tools. Mate starts from where the context already lives.

№01

Context is everywhere except the code.

Requirements in Jira. Discussion in Slack. Bug report in GitLab. By the time you've reassembled them into a prompt, the bug is older than the sprint.

№02

Every other AI tool wants another tab.

A new dashboard. A new login. A new permission model running outside your repo. The places your team actually works stay where they were — alone.

№03

Most agents work in a sandbox you'll throw away.

Mate works inside your repo's .devcontainer — it compiles with your toolchain, runs your tests, hits your linters, and opens the merge request only after the change actually builds. You review it like any other MR.

A quiet milestone

AI agents just got boring.

Reliable. Industry-ready. An everyday part of the workflow — the way every other piece of your stack got boring once it actually started working. Everyone else is racing to look exciting; that's what demos are for. Mate is what you ship after the demo.

RELIABLE INDUSTRY-READY EVERYDAY
§ 02 / Architecture, plain

Four moving parts. None of them surprising.

One webhook in, one MR out. Between them, a sandbox that can't reach GitLab directly and a permission server that decides what every call is allowed to do.

GitLab webhook │ ▼ ┌──────────┐ mints ┌──────────────────────┐ │ router │────────────►│ per-job permissions │ └────┬─────┘ per-job │ allow / deny · key │ │ token │ scoped to project │ ▼ └──────────┬───────────┘ ┌──────────┐ │ │ sandbox │ authorised │ cached │ container│ ◄─────────────────────┘ │ agent ──┼────┐ ┌──────┐ └──────────┘ │ signed token │ │ ▼ │ │ ┌──────────────┐ filtered │ GitLab │ permission │ API call │ │ │ gate │───────────────►│ │ └──────────────┘ └──────┘
↑ Fig. 02 — data flow, hosted mode (on-prem runs the same flow on a single docker host)
Lifecycle
  1. 01 Webhook

    GitLab fires a webhook the moment you assign @mate, label an issue, or @-mention the bot in a comment. Nothing else triggers a run.

  2. 02 Sandbox

    Mate mints a short-lived clone token and per-job API key, then spins up a container. The agent runs inside with zero persistent state and zero GitLab credentials of its own.

  3. 03 Permission gate

    Every GitLab call exits the sandbox through a permission proxy that checks an explicit allow/deny list — drawn up per job, against the project you're working on. Mate does what you granted, nothing more.

  4. 04 Merge request

    Mate replies through GitLab. A comment with reasoning, a linked MR with a diff, or a question if it needs one. You review it like anything else in your queue.

[†] Your GitLab token never enters the sandbox. Per-job API keys live encrypted at rest, in memory only, inside the permission gate. The agent container never sees a GitLab credential or even your GitLab URL — only a signed, time-boxed token it can present at the gate.

§ 03 / What it gives you

Built for engineering teams that have to answer to someone.

If you're shipping in a regulated industry, behind a procurement gate, or just sceptical of vendors that hold your code — this is the surface that should matter.

INTEGRATION

Bot user, not bot UI.

Mate appears as a real GitLab user. Assign, mention, @, react, request review — the workflow you already have.


SECURITY

Permission-gated MCP.

Every tool call passes through a server you control. AWS-IAM-style allow/deny resolution computed per job, not per agent.


DEPLOYMENT

On-prem or hosted.

Three containers behind your firewall. Or our managed VPS. Same Go binary, switch behaviour with a config flag.


INFERENCE

Your endpoint, your tokens.

Point Mate at an inference endpoint you already pay for — OpenAI, Anthropic, Azure, Bedrock, vLLM on your GPUs. Code and prompts go straight there. We don't proxy them, log them, or see them.


ECONOMICS

Per coworker, not per dev.

A mate is one concurrent slot — a virtual teammate the whole squad shares. Fixed price per mate, same at any quantity. No per-seat meter, no per-token bill.


COMPLIANCE

Auditable trail.

Every tool call, every diff, every prompt and response — recorded against the job. Persisted in your storage, yours to inspect.


§ 04 / How we differ

Most agents weren't built for your repo.

A quick look at where Mate diverges from the alternatives. Honest — we're new and small. The advantages we list are real, the gaps below are too.

MATE COPILOT WORKSPACE CURSOR AGENT DEVIN ROLL YOUR OWN
GitLab-native (issues, MRs, mentions)
On-prem deployment
Permission-gated tool surface
Pay for capacity, not tokens
BYOK LLM provider
Audit trail per job
Works as a teammate in your existing review flow
Yes Partial No Build it yourself
§ 05 / Pricing

Per virtual coworker.

A mate is one concurrent slot — a virtual teammate, not a per-developer seat. A team of seven typically shares a single mate; buy more when one stops keeping up. Price is fixed, scales linearly, and never depends on how many tokens the agent burned this month.

Fixed price per mate
Same price at any quantity
No per-user, no per-seat, no per-token

Shared

€19
per mate · per month
Multi-tenant infrastructure in the EU

Capacity
1 mate — one concurrent slot
Quantity
Add more mates at the same price
Isolation
Shared workers, isolated container per job
LLM
Bring-your-own endpoint, or pass-through at cost
Notify me at launch

Dedicated

€39
per mate · per month
Reserved performance, no idle billing

Capacity
1 mate — one concurrent slot
Quantity
Add more mates at the same price
Isolation
Dedicated vCPUs + memory whenever your mate runs
LLM
Bring-your-own endpoint, or pass-through at cost
Notify me at launch

On-prem

€299
per month · billed annually
Your hardware, your firewall, your control

Capacity
Unlimited — bound only by your hardware
Quantity
Run as many mates as you want
Isolation
Fully air-gappable, no telemetry home
LLM
Bring-your-own endpoint only
Talk to us
BRING YOUR OWN INFERENCE ENDPOINT FREE TOKENS CODE STAYS PUT

Point Mate at your endpoint. Tokens cost you nothing.

OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Vertex, vLLM on your own GPUs, an internal proxy — whatever your team already pays for, Mate routes through it. Code and prompts go from the job container directly to your endpoint. Mate never proxies or logs LLM traffic; job containers are ephemeral and wiped after each run. The security posture for the LLM hop is the same as if your developers were calling that endpoint themselves.

  • Your tokens, your billing, no markup
  • Your network, no third-party hop
  • Your audit log, your retention

[†] Prices are introductory during public beta and locked-in before GA. Beta participants keep beta pricing for 12 months from GA. All prices ex. VAT. Pass-through LLM at exact provider cost, billed monthly — itemised per job so you see what the model ran on. Or bring your own endpoint and the line item disappears.

§ 06 / Frequently asked

Questions we've been asked enough to put down.

Why GitLab? Why not GitHub?
Two reasons. First, the GitHub agent space is already crowded — Copilot Workspace, Cursor's agents, Cody, etc. GitLab is where the same people work but the tooling lags. Second, GitLab's permission model is coarser than GitHub's, which forced us to build our own per-job permission layer instead of leaning on the platform. That design works on either side; we'll add GitHub once GitLab is solid.
What permissions does the bot user actually need?
At the GitLab level: a service account (or bot user) with access to the projects you let it touch. At the per-job level: every action passes through a permission gate that filters against the allow/deny list you set — write on one project, read-only on another, no write on a third. Approving a merge request is intentionally never grantable, regardless of role. Separation of duties is the one thing we won't let you turn off.
Can I run this entirely on-prem?
Yes — under an enterprise contract. We deliver signed container images and an install guide; you run them on your hardware behind your firewall. A YAML config, fully air-gappable, no telemetry, no calls home. It's the same product as the hosted version, just running inside your network instead of ours. We don't open-source the code — on-prem is for sale, the source code is not.
Where does my code go during inference?
Wherever you point Mate. If you bring your own inference endpoint — OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, or a self-hosted vLLM / Ollama on your GPUs — code and prompts go from the job container directly to that endpoint. Mate never proxies or logs LLM traffic. Job containers are ephemeral and wiped after each run. The security posture for the LLM hop is the same as if your developers were calling that endpoint themselves. As a bonus: if it's an endpoint you already pay for, the LLM token cost on top of Mate is zero.
What happens to my code and my prompts?
Job metadata (which issue, which agent, exit code, duration, tool-call summary) lands in our hosted database, scoped to your account and exportable on request. The agent container itself is ephemeral and wiped after the job. Transcripts are not used for training. In on-prem mode, none of it ever leaves your network in the first place.
Why are mates priced per coworker, not per developer?
Because a mate is a coworker, not a tool. One concurrent agent slot runs one task at a time — the throughput a small engineering team actually needs. A team of seven shares one mate the same way they share one CI runner. If your queue grows past what one mate can chew through, you buy a second at the same price. There's no upsell when you hire your eighth engineer.
Which models can I use?
Whatever your inference endpoint exposes. Most teams use Claude, GPT, or DeepSeek; some run a fine-tuned Llama on their own GPUs. Model choice is per-trigger — your auto-triage agent can use a cheap model, your 'ship a patch' agent can use a strong one. You change it in YAML, not a checkout flow.
What if Mate writes a bad MR?
You close it. The bot is constrained to draft MRs by default — they don't auto-merge, they don't bypass your review, they don't ping reviewers unless you tell them to. Bad output costs you one click. It does not cost you a deploy.
Is this another vendor I have to trust forever?
Two safety nets for on-prem customers. First, the licence on the version you installed is perpetual — if we vanish, your installation keeps running, you just stop getting updates. Second, for critical-path deployments we offer source escrow with a neutral third party as part of the enterprise contract; the escrowed copy is released to you under defined trigger conditions (insolvency, acquisition, end-of-life). The hosted version is for teams who'd rather not run yet another service in the first place.
When is GA?
Implementation is well underway (closed source). Private beta is live now with a small waitlist — join it and you'll get a slot as they open. GA follows once beta users have shipped enough real Mate-authored MRs that we're confident in the system under real conditions.
§ 07 / Get started

Two ways in.

One path if you'd rather we run it for you. One path if it has to live inside your firewall. Same product, two operating models.

FOR TEAMS WHO DON'T WANT ANOTHER THING TO RUN

Hosted, private beta (waitlist).

Drop your email. Beta is live but capped at a small number of users while we prove the system — we'll send you the sign-up link when a slot opens.

No newsletter. No upsell. One email when a slot opens.

Already invited? Sign in →

FOR TEAMS THAT NEED IT BEHIND THEIR FIREWALL

Enterprise on-prem.

Annual contract, your hardware, your network. We deliver signed container images, an install playbook, and a person to call when something breaks. Fully air-gappable. No telemetry, no calls home.

  • Signed container images — not source code distribution
  • Quarterly updates, email support, named contact
  • Source escrow with a neutral third party on request
  • Perpetual licence on the version you install
Talk to us