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.
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.
Opened 4 minutes ago by ondrej
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.
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.
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.
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.
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.
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.
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 fires a webhook the moment you assign @mate, label an issue, or @-mention the bot in a comment. Nothing else triggers a run.
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.
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.
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.
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.
Mate appears as a real GitLab user. Assign, mention, @, react, request review — the workflow you already have.
Every tool call passes through a server you control. AWS-IAM-style allow/deny resolution computed per job, not per agent.
Three containers behind your firewall. Or our managed VPS. Same Go binary, switch behaviour with a config flag.
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.
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.
Every tool call, every diff, every prompt and response — recorded against the job. Persisted in your storage, yours to inspect.
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 | ● | ◐ | ○ | ○ | ▸ |
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.
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.
[†] 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.
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.
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.
Got it — we'll reach out when a slot opens.
Something went wrong — please try again.
No newsletter. No upsell. One email when a slot opens.
Already invited? Sign in →
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.