GitHub Copilot's coding agent (GitHub's docs now call it the Copilot cloud agent) and AI CodeOps solve a similar problem. You hand over a task, the work happens in the cloud, and you get back a pull request. The differences are in where they work, how changes are gated, and what you pay.

This comparison uses GitHub's own documentation for the Copilot facts, as of October 2026. It's about the coding agent, not Copilot code review, which is a separate feature.

What the Copilot agent does

According to GitHub's docs, the agent can research a repository, plan changes and implement them in the background, in a temporary cloud environment where it can run tests and linters. You can start it from an issue, a pull request, a chat or the agents panel. It creates a branch, pushes commits and opens a pull request.

GitHub builds solid safeguards around it. The person who asked for the pull request can't approve it. The agent can't approve or merge, and it can only push to its own branch. By default, workflows don't run until a person has reviewed its code.

Its documented limits: it works only with repositories hosted on GitHub, it works on one branch and opens one pull request per task, and each session runs for at most 59 minutes.

What AI CodeOps does

AI CodeOps runs AI software-engineering sessions in your browser. Specialised agents (architect, builder, reviewer, tester, security auditor and others) plan the task, write the change, run your tests and review the result. The change then waits at a release gate until your tests pass, the AI review is clear and a person approves it.

Side by side

When Copilot is the better choice

• Your code is all on GitHub and you already pay for Copilot.
• You want the smallest change to your tooling, with no second product to adopt.
• You like GitHub's default safeguards on agent pull requests.
• Your developers already use Copilot in the editor.

When AI CodeOps fits

• Your code lives on GitLab, Bitbucket, Gitea or Forgejo, or across several hosts.
• You want several agents to review each change before a person sees it.
• You want one gate that covers tests, findings and approvals together, with signed evidence for each change.
• You need spend control: caps per workspace and per workflow, cost per session, model tiers, or your own provider key.

How to decide

If your code is on GitHub and Copilot is already in place, try the Copilot agent first, since it costs you the least to adopt. If you need other Git hosts, a gate with signed evidence, or per-workflow spend caps, run AI CodeOps on the same repository and compare.

Full comparison with sources: aicodeops.dev/compare/aicodeops-vs-copilot-agent

💚 AI CodeOps is free forever for non-commercial open-source projects: apply here.

Originally published on Medium. Drafted with AI assistance and edited by the AI CodeOps team. Copilot details are from GitHub's documentation as of October 2026 and may change.

If you read the docs of most AI coding agents closely, one line keeps showing up: works with repositories hosted on GitHub. That's a reasonable place to start. GitHub is huge.

But plenty of teams aren't there. Enterprises run self-managed GitLab. Agencies live in Bitbucket. Privacy-minded teams and a growing slice of open source run Gitea or Forgejo on their own servers. For them, "just use the agent" means moving their code first, which usually means not using the agent.

We built AI CodeOps to work where the code already is.

One workflow, five Git hosts

AI CodeOps connects to GitHub, GitLab, Bitbucket, Gitea and Forgejo. The flow is the same on each:

1. Connect once. Use OAuth for the hosted services, or a personal access token for your own server. For a self-hosted GitLab, Gitea or Forgejo, you enter the server's public https address and paste a token
2. Describe a change in the browser. Agents plan it, write it, review it and run the project's own tests in a sandbox
3. Get a pull request on your host. When the change passes the release gate, AI CodeOps pushes a branch named codeops/run-<id> and opens a pull request (a merge request on GitLab) into the default branch

A team that uses more than one host can run all of them from one workspace.

What it does, and what it doesn't

For teams that own their tooling, the second list matters as much as the first. On Gitea and Forgejo, for example, AI CodeOps:

• Does list the repositories, branches, files and pull requests the connected account can see
• Does push a branch and open a pull request, with commits authored as "AI CodeOps"
• Doesn't need admin access. An account that can read the repository, push a branch and open pull requests is enough
• Doesn't install webhooks, post commit statuses or comment on your pull requests
• Never pushes to your default branch directly

Tokens are encrypted at rest and never written into a repository's Git configuration. To remove access, disconnect in AI CodeOps or revoke the token on your server.

The gate goes with you

The point isn't only that the agent can reach your host. It's that the same rules apply there. A change opens a pull request only when your tests passed on that exact version, the AI review of the real diff has no open high or critical findings, and a person approved it. If a check errors, the gate fails closed.

A pull request opened by AI CodeOps can be merged from the console only after the release gate passes again. You can also merge it on your host as usual, and if you want those merges gated too, your CI can ask the gate for a verdict through an API and fail the job on a "no".

A note for Codeberg users

Codeberg runs Forgejo, so the connection works with https://codeberg.org and a personal access token. But read Codeberg's Terms of Use first: they don't allow projects that mostly consist of code written by generative AI tools. That's their call, and worth respecting.

Try it on your host

AI CodeOps runs in the browser, with nothing to install. It's free during the open beta, and free forever for non-commercial open-source projects.

• Integrations: aicodeops.dev/integrations
• Open source program: aicodeops.dev/pricing/open-source

Drafted with AI assistance and edited by the AI CodeOps team.

We ran it through a Security-Sensitive Change workflow: five agents in a row. One scopes the change, one analyses the risk, one implements, one audits the diff, and one validates the result. The whole run took about 35 seconds and cost under 20 cents.

The implementation did what we asked. The diff added a validateDiscountCode helper that trims, uppercases, checks the pattern and length, and throws on anything else. Tests covered valid codes, illegal characters, long codes and unknown codes.

Then the audit step came back with four findings. Three were minor. One was marked HIGH:

Unvalidated discountPercent parameter allows arbitrary discount values.

The cart's older total() function still accepted a raw discountPercent option. We had asked the agents to lock down the new input path, and they did. But the old path was still wide open: a caller could pass 100, or 250, and get a free cart or a negative total. Nobody had asked about it. The auditor found it anyway, because it was reading the code around the change, not just the change.

The gate held. Because a HIGH finding was open, the change was not release-ready. It could not become a pull request until the finding was fixed or a person signed off on it. One click on Fix sends the finding back to an agent as a new task.

Three takeaways

1. Audit the code around the change, not just the diff lines. The most dangerous bugs were next to what we changed, not in it.
2. A finding needs teeth. If a reviewer can flag a HIGH issue and the change still merges, the review is advice. Tie open high or critical findings to a merge block.
3. Scope creep is good when it's a finding, not a commit. The auditor didn't silently "fix" the extra issue inside our change. It reported it, so a person decides.

We recorded runs like this as short tutorials on our YouTube channel: https://www.youtube.com/@AICodeOps

AI CodeOps is free during the open beta and free forever for non-commercial open source: https://aicodeops.dev

This tutorial adds one required check to your pipeline. It asks the AI CodeOps release gate whether a pull request may ship, prints the reasons, and fails the job when the answer is no.

What the gate checks

The release gate looks at every AI CodeOps session that touched the change and applies the same rules as the console:

• The project's tests passed, on the version being merged
• The AI review completed and no blocking findings are open (high or critical by default)
• Approvals are in place

You can make it stricter per pipeline: a coverage floor, required workflows, disallowed licenses from the project's SBOM, or a requirement that the change already deployed to an environment such as staging.

Two details matter for CI:

1. A denial is still HTTP 200. You read the allowed field, not the status code.
2. It fails closed. If the evaluation itself fails, you get allowed: false with the summary "Evaluation failed". A change with no matching sessions is also denied.

Step 1: Create an API key

In the console, open Configure → API Keys and create a key. The secret starts with sk- and is shown once. The key acts as the member who created it, so create it from an account whose role can read the workspace.

Store it as a CI secret named AICODEOPS_API_KEY.

Step 2: GitHub Actions

AI CodeOps opens its pull requests on branches named codeops/run-<id>. Scoping the job to those branches means pull requests written by people aren't affected.

{% raw %}
name: AI CodeOps release gate

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  release-gate:
    if: startsWith(github.head_ref, 'codeops/run-')
    runs-on: ubuntu-latest
    steps:
      - name: Ask the release gate
        env:
          AICODEOPS_API_KEY: ${{ secrets.AICODEOPS_API_KEY }}
          PR_URL: ${{ github.event.pull_request.html_url }}
        run: |
          body=$(jq -n --arg pr "$PR_URL" '{pullRequestURL: $pr, minCoveragePct: 80}')
          verdict=$(curl -sSf -X POST "https://console.aicodeops.dev/api/release/check" \
            -H "Authorization: Bearer $AICODEOPS_API_KEY" \
            -H "Content-Type: application/json" \
            -d "$body")
          echo "$verdict" | jq -r '.summary'
          echo "$verdict" | jq -r '.reasons[]?'
          test "$(echo "$verdict" | jq -r '.allowed')" = "true"
{% endraw %}

curl -f makes the job fail on an auth or network error, and the last line fails it on a denial. Either way, nothing gets through by accident.

Then make it required: Settings → Rules → Rulesets (or branch protection) on your main branch, and add release-gate as a required status check. When the job is skipped for a human pull request, GitHub treats the skipped check as passing.

Step 3: GitLab CI

The same idea in .gitlab-ci.yml. The pullRequestURL field takes your merge request URL as it appears on GitLab.

release-gate:
  stage: test
  image: alpine:3.20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^codeops\/run-/'
  script:
    - apk add --no-cache curl jq
    - MR_URL="$CI_PROJECT_URL/-/merge_requests/$CI_MERGE_REQUEST_IID"
    - BODY=$(jq -n --arg pr "$MR_URL" '{pullRequestURL: $pr}')
    - >
      VERDICT=$(curl -sSf -X POST "https://console.aicodeops.dev/api/release/check"
      -H "Authorization: Bearer $AICODEOPS_API_KEY"
      -H "Content-Type: application/json"
      -d "$BODY")
    - echo "$VERDICT" | jq -r '.summary, (.reasons[]?)'
    - test "$(echo "$VERDICT" | jq -r '.allowed')" = "true"

Add AICODEOPS_API_KEY under Settings → CI/CD → Variables (masked), and turn on Pipelines must succeed under Settings → Merge requests.

Step 4: Tune it

All of these go in the request body:

A stricter release branch might send "blockingSeverity": "medium", "requireDeployedTo": "staging".

Good to know

• The workspace limit is 60 checks a minute. A 429 response includes Retry-After.
• The API is deliberately small during the open beta: this endpoint, plus public keys for verifying evidence packs.
• The same check is in the console under Review & Gate → Release gate, if you want to see a verdict before wiring up CI.

Full reference: https://aicodeops.dev/docs/api/release-check

Drafted with AI assistance and edited by the AI CodeOps team.

For example, CodeRabbit's platform docs list GitHub, GitLab, Bitbucket and Azure DevOps (cloud and self-hosted variants), with no Gitea or Forgejo support as of November 2026.

AI CodeOps works with Gitea and Forgejo, including self-hosted servers, the same way it works with GitHub and GitLab: you connect the server with a token scoped to the repositories you choose, and AI agents plan, build, review and test changes on your real repository.

What you get on Gitea or Forgejo

• AI review of the real diff, with findings sorted by severity
• Your own tests, run in a sandbox on the exact version of the change
• A release gate: no pull request until the tests pass, the review has no open high or critical findings, and a person approves
• A release-check API your CI can call on any PR or commit, so direct merges are covered too

Free during the open beta, and free forever for non-commercial open-source projects: https://aicodeops.dev