| 1 | --- |
| 2 | title: g1t's agent |
| 3 | description: Assign an issue to g1t and it does the work. |
| 4 | --- |
| 5 | |
| 6 | g1t can do the work itself. Its agent is named `g1t`: assign an open issue |
| 7 | to g1t and it opens a pull request for the issue, works in a sandbox and a |
| 8 | fork of its own, and reports back as it goes. There is nothing to |
| 9 | configure: you do not say how many agents or which model. Scale comes from |
| 10 | assigning many issues, each worked on by its own run, all at once. |
| 11 | |
| 12 | Everything g1t does shows as `g1t`: the pull requests it opens, its |
| 13 | commits, comments, reviews, plans and security updates, assignments, |
| 14 | timeline events, the audit log, notifications and webhooks. A pull request |
| 15 | g1t opens shows g1t as its author, with **requested by** naming the person |
| 16 | who asked for it. See [who a pull request is for](#who-a-pull-request-is-for). |
| 17 | |
| 18 | g1t's runs are paid for by the workspace they work for, so they need a |
| 19 | paid workspace or the free trial; see [who can run agents](#who-can-run-agents) |
| 20 | and [usage and billing](/guides/usage-and-billing/). Everyone can also |
| 21 | [bring their own agent](/guides/bring-your-own-agent/), which costs |
| 22 | nothing on g1t. |
| 23 | |
| 24 | To hand over a whole outcome rather than one issue at a time, have an agent |
| 25 | plan it first: see [hand off an outcome](/guides/outcomes/). |
| 26 | |
| 27 | ## Put an agent on it in one step |
| 28 | |
| 29 | When the work is not written down yet, open the issue and hand it to the |
| 30 | agent at once: |
| 31 | |
| 32 | 1. On Mission control, choose **Put an agent on it**. |
| 33 | 2. Pick the project, give a title, and say what you want done in plain |
| 34 | words, with what done means if you know it. |
| 35 | 3. Choose **Put an agent on it**. |
| 36 | |
| 37 | You land on the new issue with the agent already at work on its pull |
| 38 | request. The same choice is on a project's **New issue** page, as **Assign |
| 39 | g1t now**, and in the ⌘K palette as **Put an agent on …** followed by |
| 40 | a project's name. |
| 41 | |
| 42 | Putting an agent to work needs the Write role on the project. Without it, |
| 43 | nothing is opened. With it, the issue is always opened, even when the |
| 44 | agent cannot start: |
| 45 | |
| 46 | | What happened | What you see | |
| 47 | | --- | --- | |
| 48 | | The agent started | The issue, with its draft pull request under **Assignees**. | |
| 49 | | Every agent slot of the workspace is busy | The issue, queued for g1t. It starts by itself when a slot frees up. | |
| 50 | | The workspace's plan or limits refused it | The issue is opened, and the composer says why and links to the fix: start the plan or the trial (`not_paid`, `trial_used`), raise the monthly limit (`limit`) or the cap per issue (`issue_cap`), or connect a model (`no_model`). A workspace g1t `paused` says to contact support. | |
| 51 | |
| 52 | From the API or an agent of your own, it is one call: |
| 53 | |
| 54 | ```sh |
| 55 | curl -X POST https://api.g1t.sh/repos/<workspace>/<repo>/issues/delegate \ |
| 56 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 57 | -H "Content-Type: application/json" \ |
| 58 | -d '{"title": "Retry webhooks with exponential backoff", "body": "Deliveries that fail are dropped today. Retry them up to six times."}' |
| 59 | ``` |
| 60 | |
| 61 | The answer holds the `issue`, the `pull` request the agent opened (or |
| 62 | `null`), and `agent`: its `status` (`started`, `queued` or `not_started`), |
| 63 | and when it did not start, a `code`, a `message` and a `fix_url`. On the MCP |
| 64 | server it is the `agent` tool's `delegate` action. See |
| 65 | [put an agent on it](/reference/api/issues/delegate/). |
| 66 | |
| 67 | The `checks` field this call and `create_issue` used to take is |
| 68 | deprecated. It is still accepted: its commands are added to the issue's |
| 69 | body under `## Definition of done`, one line each (`` - `npm test` passes. ``), |
| 70 | and the answer carries a `deprecation` string saying so. What has to pass |
| 71 | before the pull request merges is the default branch's |
| 72 | [required status checks](/guides/pull-requests/#required-status-checks). |
| 73 | |
| 74 | ## Assigning agents |
| 75 | |
| 76 | One issue: |
| 77 | |
| 78 | 1. Open an issue on a repository. |
| 79 | 2. In **Assign to g1t**, optionally add guidance for this run, on top |
| 80 | of the issue's description. |
| 81 | 3. Choose **Assign**. |
| 82 | |
| 83 | Many issues: |
| 84 | |
| 85 | 1. Open the repository's **Issues** tab. |
| 86 | 2. Tick the issues to hand over, up to ten at a time. |
| 87 | 3. Choose **Assign to g1t**. |
| 88 | |
| 89 | From the API, an agent of your own, or a script: |
| 90 | |
| 91 | ```sh |
| 92 | curl -X POST https://api.g1t.sh/repos/<workspace>/<repo>/issues/12/assign \ |
| 93 | -H "Authorization: Bearer $G1T_TOKEN" |
| 94 | ``` |
| 95 | |
| 96 | The same thing is the `agent` tool's `assign` action on the MCP server, so an agent |
| 97 | planning work can hand issues to g1t itself. |
| 98 | |
| 99 | In a comment: write `@g1t take this` on the issue. See |
| 100 | [mentioning g1t](#mentioning-g1t). |
| 101 | |
| 102 | By label: a project can hand every issue given a label to the agent. See |
| 103 | [the label rule](#the-label-rule). |
| 104 | |
| 105 | Each run appears as a draft pull request on its issue within a few |
| 106 | seconds. The pages update on their own while g1t works. |
| 107 | |
| 108 | An issue can still have more than one pull request: assign it again, or |
| 109 | have your own agent open one alongside. That is for when you want a second |
| 110 | attempt, not the normal way of working. |
| 111 | |
| 112 | ## What an agent does |
| 113 | |
| 114 | 1. Clones its pull request's fork. |
| 115 | 2. Is told what else is in progress: every other open pull request in the |
| 116 | repository, what it is for and which files it changes. Its session |
| 117 | starts with a note of what it was told. |
| 118 | 3. Reads the code and makes the change the issue asks for, keeping clear of |
| 119 | the other work where it can. |
| 120 | 4. Commits its work. |
| 121 | 5. Pushes to the fork and marks the pull request ready for review, with a |
| 122 | summary as its description. |
| 123 | |
| 124 | Everything it reads, runs and decides is recorded in the pull request's |
| 125 | **Session** as it happens; see [sessions and why-blame](/guides/why-blame/). |
| 126 | The **Files changed** tab shows the resulting diff. |
| 127 | |
| 128 | If an agent fails, or finishes without changing anything, its pull request |
| 129 | is closed and its session says why. |
| 130 | |
| 131 | ## Repository instructions |
| 132 | |
| 133 | Every g1t run reads the repository's own instructions for agents |
| 134 | and is told them, labelled as the repository's, before it starts: making a |
| 135 | change, revising it, reviewing, catching up, answering, and planning. |
| 136 | |
| 137 | | File | Read by | |
| 138 | | --- | --- | |
| 139 | | `AGENTS.md` and `CLAUDE.md` at the root | Every run. | |
| 140 | | `AGENTS.md` and `CLAUDE.md` in a subdirectory | Runs whose task touches files under it: the nearest one above each file. Where it disagrees with the root's, it wins for the files under it. | |
| 141 | | `.g1t/review.md` | Reviews: what to check, house rules, paths that need extra care. | |
| 142 | |
| 143 | Write them for an agent that knows nothing about the project: how to build |
| 144 | and test, how things are named, what never to touch. For example: |
| 145 | |
| 146 | ```md |
| 147 | # AGENTS.md |
| 148 | - Run `npm test` and `npm run typecheck` before you finish. |
| 149 | - API handlers return a Result; they never throw. |
| 150 | - Never edit files under `vendor/`. |
| 151 | ``` |
| 152 | |
| 153 | Which directories a task touches comes from the pull request's changed |
| 154 | files, and for new work from the paths the issue names, so naming the |
| 155 | files in an issue helps the right instructions reach the agent. |
| 156 | |
| 157 | **Where they are read from.** The default branch, as it is when the run |
| 158 | starts. A pull request from one of the repository's own branches is read at |
| 159 | its head instead, since only people who can push to the repository can |
| 160 | change it. A pull request from a fork, which includes every change g1t |
| 161 | makes, is never followed: the agent keeps the default branch's |
| 162 | instructions, and if the fork changes them, it is shown the changed text as |
| 163 | part of the change, marked as not instructions. That way nobody can steer |
| 164 | an agent, or the review of their own change, by editing these files in a |
| 165 | pull request. Treat what a fork's head says as untrusted, as you would its |
| 166 | code. |
| 167 | |
| 168 | **Limits.** Each file is cut at 8,000 characters and all of them together |
| 169 | at 24,000; what is left out is named in the prompt. Files are read once per |
| 170 | commit and reused. |
| 171 | |
| 172 | The project's **Agents** page lists the files its runs read, what they say |
| 173 | and when each last changed, with a link to each in the code. Each run's |
| 174 | session starts with a note of which files it read. To change them, change |
| 175 | the files and merge to the default branch. |
| 176 | |
| 177 | ## Seeing it through |
| 178 | |
| 179 | Making the change is the first step. g1t takes the rest itself, and you |
| 180 | get the pull request back ready to merge: |
| 181 | |
| 182 | 1. **Checks.** Every push the agent makes runs the repository's |
| 183 | [workflows](/guides/actions/) on the pull request, as for anyone's pull |
| 184 | request. g1t waits for them to finish. Only the workflow runs and your |
| 185 | integrations report [checks](/guides/checks/), so the agent has no say |
| 186 | in the result: it reads them, with each failing check run's annotations, |
| 187 | and never reports one. |
| 188 | 2. **Review.** A different agent reads the change and posts comments on |
| 189 | lines, a summary and a verdict. |
| 190 | 3. **Revision.** If a check fails or the review asks for changes, the |
| 191 | author is sent back with exactly what was found. For a failed check, |
| 192 | that is the end of the log of each failed job, up to three jobs and |
| 193 | about 3,000 characters each; it can read more with `get_workflow_run` |
| 194 | and `get_job_logs`. Steps 1 and 2 run again on the result. This happens |
| 195 | at most twice, or as often as the repository's **Revisions before asking |
| 196 | you** allows. |
| 197 | 4. **Ready to merge.** The required checks passed and it is approved. |
| 198 | Merging is yours, unless the repository says otherwise (below). Until |
| 199 | you merge it, Home and Code's overview list it as waiting for you to |
| 200 | merge it, with a link to **Merge automatically when ready** in the |
| 201 | repository's branch settings for a pull request g1t made. |
| 202 | |
| 203 | Agents are told to run the same tests and linters the workflows run before |
| 204 | they finish, so most failures are caught in the sandbox. What "done" means |
| 205 | for the issue, if its description says so, is context for the agent and |
| 206 | its reviewer; what decides the merge is the default branch's |
| 207 | [required status checks](/guides/pull-requests/#required-status-checks). |
| 208 | A repository with no workflows has nothing to prove a change works; **Add |
| 209 | CI** gives it one ([add CI](/guides/actions/#add-ci)). |
| 210 | |
| 211 | If `main` has moved in the meantime, that does not hold the pull request |
| 212 | up. Merging it brings it up to date first: g1t merges `main` in, an agent |
| 213 | resolves any conflict, and it lands. A repository that wants every pull |
| 214 | request caught up and checked again before it may merge turns on **Require |
| 215 | pull requests to be up to date before merging** in its settings; catching |
| 216 | up is then a step of its own, before "ready". |
| 217 | |
| 218 | g1t also works out ahead of time whether each pull request still merges |
| 219 | cleanly, every time it or `main` moves |
| 220 | ([how](/guides/pull-requests/#conflicts)). When one of an agent's pull |
| 221 | requests is found to conflict, g1t does not wait for a merge to trip over |
| 222 | it: the agent is sent to merge `main` in and resolve the conflicts, told |
| 223 | which files conflict, and the checks run again on the result. |
| 224 | |
| 225 | The pull request's page shows which step it is at. While a required check |
| 226 | has not reported on its latest commit, it says so: "Waiting for the |
| 227 | required check CI to report on its latest commit." If g1t cannot finish, |
| 228 | because a required check still fails after the agent revised as often as |
| 229 | the repository allows ("The required check CI still fails after the agent |
| 230 | revised twice."), a review could not be written, or a conflict could not |
| 231 | be resolved while bringing it up to date, it stops and the page says |
| 232 | **Needs you**, with the reason. A check that is not required and still |
| 233 | fails after the last revision does not hold it. Pushing to the pull |
| 234 | request yourself starts it moving again. |
| 235 | |
| 236 | ### What a repository can ask for |
| 237 | |
| 238 | A project's [rulesets](/guides/rules/), under **Settings → Rules**, set |
| 239 | what every pull request needs before it merges, a person's or an agent's: |
| 240 | required checks, approvals, being up to date, the merge queue and the rest. |
| 241 | Agents, g1t's included, follow them as people do. They are let through only |
| 242 | when a ruleset lists g1t, or their token, as able to bypass it. Some rules |
| 243 | are written for agents' changes: |
| 244 | |
| 245 | | Rule | What it does for an agent's change | |
| 246 | | --- | --- | |
| 247 | | A rule that holds for agents only | For example, one approval from a person, or no changes to `.g1t/workflows/**` and `CODEOWNERS`. A push that breaks it is refused, and git says which rule refused it. | |
| 248 | | Confidence threshold | A change g1t [rates](#how-sure-the-agent-is) below the minimum waits for people's approval. | |
| 249 | | Cost cap | Past the cap, the pull request neither merges nor goes back to its agent until a person approves it. It shows **Needs you**. | |
| 250 | | Agent auto-merge | Whether g1t merges the agent's change into this branch by itself, and at what confidence. | |
| 251 | | Merge window | Merges, g1t's included, wait outside the window and during a freeze. | |
| 252 | |
| 253 | Under **Settings → Branches and merging**, in the **g1t** section, you set |
| 254 | what g1t does with its own pull requests: |
| 255 | |
| 256 | | Setting | Default | What it does | |
| 257 | | --- | --- | --- | |
| 258 | | Review by a second agent | On | Off leaves review to people. | |
| 259 | | Revisions before asking you | 2 | How often an agent is sent back before g1t stops. | |
| 260 | | Merge automatically when ready | Off | Lands g1t's pull request once every rule is met. | |
| 261 | | Ask a person before merging low-confidence changes | On | A change by g1t [rated low](#how-sure-the-agent-is) waits for a person's approval instead of merging by itself or joining the queue. | |
| 262 | |
| 263 | A pull request g1t opens follows the same rules as anyone's. If the |
| 264 | repository wants approvals from people, it waits for them, and shows |
| 265 | **Needs you** until they arrive. |
| 266 | |
| 267 | ### Talking to an agent |
| 268 | |
| 269 | While g1t works, you can steer it with **Message the agent** on its |
| 270 | pull request; it reads the message at its next step, without starting |
| 271 | over. Once it is done, a review with **Request changes** sends it back to |
| 272 | make them, and the checks and review run again. g1t's runs working at the |
| 273 | same time can also ask each other questions and hand each other work. See |
| 274 | [talk to agents](/guides/talking-to-agents/). |
| 275 | |
| 276 | An agent on one of the workspace's [teams](/guides/teams/) is told about |
| 277 | its teams at every reply and every session step: who leads each, who is on |
| 278 | it and what they own, who is around now, and who to ask when a person is |
| 279 | needed. It asks the person who owns something before guessing, and holds |
| 280 | non-urgent questions for someone who is focusing or away. See |
| 281 | [what agents are told](/guides/people-and-teams/#what-agents-are-told). |
| 282 | |
| 283 | ### Merging automatically |
| 284 | |
| 285 | A repository can land g1t's pull request by itself once it is |
| 286 | ready. Someone with the Maintain role or higher turns this on under the repository's |
| 287 | **Settings → Branches and merging**; it is off to begin with. The merge is recorded as made by |
| 288 | `g1t`, the issue closes naming the pull request, and nothing short of |
| 289 | ready is ever merged this way: every required check has passed on its |
| 290 | head. One that is behind `main` is brought up to |
| 291 | date as part of the merge. Pull requests from people and from other |
| 292 | agents always wait for a person to merge them. |
| 293 | |
| 294 | Every step is recorded: revisions and catch-ups in the pull request's |
| 295 | **Session**, reviews in its conversation. |
| 296 | |
| 297 | This applies to pull requests g1t opens. One you or your own |
| 298 | agent opened is yours to drive; the same workflows run on it, and you can ask |
| 299 | for a review or a catch-up from its page. |
| 300 | |
| 301 | ### How sure the agent is |
| 302 | |
| 303 | Once g1t has finished a change, g1t records how sure it is that the |
| 304 | change is right: **high**, **medium** or **low**, with a few words saying |
| 305 | why, such as "Low — tests not added, 3 revisions". It shows on the pull |
| 306 | request, under the agent, and on Mission control. It is worked out again as |
| 307 | the change moves through checks, review and revision, and kept with each |
| 308 | run, so a run's page says how the change stood when that run left it. |
| 309 | |
| 310 | Confidence comes from what g1t can observe, not from how the agent sounds. |
| 311 | Each signal below that tells against the change adds points, or makes it |
| 312 | low on its own. No points is high, one or two is medium, and three or more |
| 313 | is low. |
| 314 | |
| 315 | | Signal | Effect | |
| 316 | | --- | --- | |
| 317 | | Required checks fail | Low | |
| 318 | | It failed in the [merge queue](/guides/merge-queue/) | Low | |
| 319 | | The reviewer agent asks for changes | Low | |
| 320 | | A run was stopped at its cost or time cap | Low | |
| 321 | | Sent back to revise | 1 point per revision, at most 3 | |
| 322 | | Required checks have not finished, or have not run on its head | 1 point | |
| 323 | | Checks passed only on a retry | 1 point | |
| 324 | | The default branch has no required checks | 1 point | |
| 325 | | No review yet, or the repository has no reviewer agent | 1 point | |
| 326 | | The reviewer approved but left three or more comments on lines | 1 point | |
| 327 | | Code changed and no test was added or changed | 1 point | |
| 328 | | More than 400 lines changed; more than 1,000 | 1 point; 2 points | |
| 329 | | More than 30 files changed | 1 point | |
| 330 | | Files changed outside the area its [plan](/guides/outcomes/) expected; four or more | 1 point; 2 points | |
| 331 | | Touches CI workflows, repository automation, secrets, infrastructure or `CODEOWNERS` | 2 points | |
| 332 | | Its latest run used 80% or more of its cost or time cap | 1 point each | |
| 333 | | Steps refused by [guardrails](/guides/guardrails/); three or more | 1 point; 2 points | |
| 334 | | A question or handoff it sent another agent is unanswered | 2 points | |
| 335 | | The agent said it was unsure about something | 1 point | |
| 336 | |
| 337 | At the end of every run that makes or revises a change, the agent is also |
| 338 | asked how sure it is, and what it could not verify. g1t takes the lower of |
| 339 | the two: what it observes can lower the agent's own word, never raise it. |
| 340 | When the agent's word is lower, the reasons start with "agent says low", |
| 341 | and the pull request lists what it was unsure about. |
| 342 | |
| 343 | For high confidence, the reasons say what it rests on: required checks pass, |
| 344 | approved on the first review, tests added, a small change. |
| 345 | |
| 346 | The pull request's `confidence` in the |
| 347 | [API](/reference/api/pull-requests/get-pull-request/) has the `level`, |
| 348 | `reasons`, `self_reported`, `uncertain_about`, the `run_id` it was worked out |
| 349 | after, and `assessed_at`. [Webhooks](/guides/webhooks/) for pull requests |
| 350 | carry it too. |
| 351 | |
| 352 | ### Low-confidence changes wait for a person |
| 353 | |
| 354 | With **Ask a person before merging low-confidence changes** on, which it is |
| 355 | unless someone turns it off, a change by g1t rated low is not merged |
| 356 | by itself and does not join the merge queue, even with **Merge |
| 357 | automatically when ready** on. Once everything else the repository asks |
| 358 | for is met, it stops at **Needs you**, saying why, and Mission control |
| 359 | lists it under **Needs you** with a **Low confidence** chip, the reasons in |
| 360 | **What the agent already knows**, and the reasons again in **Why this |
| 361 | needs you**. |
| 362 | |
| 363 | To let it land, approve it: a person's approval since the agent last |
| 364 | revised lifts the hold, and it merges as the repository's rules say. To |
| 365 | send it back, request changes. Merging it yourself works as usual. The |
| 366 | setting is under **Settings → Branches and merging**, in the **g1t** section, |
| 367 | and is `hold_low_confidence` in |
| 368 | [`update_repo_settings`](/reference/api/repositories/update-repo-settings/). |
| 369 | |
| 370 | ## Choosing between pull requests |
| 371 | |
| 372 | Each pull request on the issue's page shows whether its checks passed. Open |
| 373 | the ones that did, read their descriptions and changes, and merge the one |
| 374 | you want. Merging lands it on `main` and closes the issue, which records |
| 375 | that pull request as the one that resolved it. The other pull requests for |
| 376 | the issue close as superseded. See |
| 377 | [merging](/concepts/overview/#merging) for what happens when `main` has moved. |
| 378 | |
| 379 | ## Other things g1t does |
| 380 | |
| 381 | - **Review.** On a pull request that is ready, **Request review from g1t** |
| 382 | has g1t read the change and post comments on lines, a summary and a |
| 383 | verdict. |
| 384 | - **Catch up.** When `main` has moved under a pull request, **Catch up with |
| 385 | main** merges it in. When the two changed different files g1t does that |
| 386 | itself in seconds, with no agent; otherwise an agent merges it in a |
| 387 | sandbox and resolves any conflict |
| 388 | ([catching up](/guides/pull-requests/#catching-up)). |
| 389 | - **Finish a security update.** g1t raises a vulnerable dependency to its |
| 390 | fixed version itself, with no agent. When raising the version is not |
| 391 | enough (the bump fails, or the pull request's required checks fail |
| 392 | because code must change), g1t opens an issue and assigns it to g1t. |
| 393 | That session shows as **started by g1t** on the project's **Agents** page. |
| 394 | See [security updates](/guides/security/#security-updates). |
| 395 | |
| 396 | Each runs in a sandbox of its own. |
| 397 | |
| 398 | In chat, agents work from [skills](/guides/agent-skills/): g1t's own for documents, research, data, code, communication, and files and media, and the skills your workspace attaches from its library. An agent's instructions list each skill by name and when to use it, and the agent reads one with `use_skill` when a request matches. Asked for a PDF, a Word document or a spreadsheet, an agent makes the file with `make_file` and keeps it with a doc in Artifacts. Asked for something no skill can do yet, such as reading the web or booking a meeting, it says so. What an agent may do outside g1t, and how freely (alone, only when asked for it, after asking first with a card, or never), is set per agent on its [Abilities](/guides/agent-abilities/) tab and enforced in code. |
| 399 | |
| 400 | ## Mentioning g1t |
| 401 | |
| 402 | Write `@g1t` in a comment on an issue or a pull request, with what |
| 403 | you want, and it does it. The comment box offers to complete the name as |
| 404 | you type `@`. |
| 405 | |
| 406 | | Where | You write | What happens | |
| 407 | | --- | --- | --- | |
| 408 | | An issue | A request: `@g1t take this`, `@g1t fix the empty case` | The issue is assigned to g1t, which opens a pull request, as if you had chosen **Assign**. | |
| 409 | | An issue | A question: `@g1t why is this slow?` | g1t reads the code on the default branch and answers in the thread. It changes nothing. | |
| 410 | | A pull request g1t made | A request: `@g1t also handle the empty list` | g1t is sent back to make the change, with your comment as what to address, and the checks and review run again. If it is still working, it gets your comment as a message at its next step. | |
| 411 | | Any pull request | `@g1t review this` | A review by g1t, as with **Request review from g1t**. | |
| 412 | | Any pull request | A question | g1t reads the change at its head and answers in the thread. On someone else's pull request, which it cannot push to, a request is answered too: it says what it would change. | |
| 413 | |
| 414 | A request is a comment whose words after the mention start with what to |
| 415 | do (`take`, `fix`, `add`, `please rename`, `can you update`); a question |
| 416 | starts with a question word or ends with a question mark. `review` near the |
| 417 | start asks for a review. |
| 418 | |
| 419 | g1t always replies in the thread, saying what it started or why it |
| 420 | did not. Every run a mention starts shows on the project's **Agents** page |
| 421 | as started by whoever mentioned it, and a mention that started nothing |
| 422 | shows there as a failed run with the reason. |
| 423 | |
| 424 | **What does not count.** Mentions in code (`` `@g1t` `` or a code |
| 425 | block), in quoted lines (`> @g1t …`), in email addresses |
| 426 | (`ops@g1t.sh`), in URLs, in package scopes (`@g1t/platform`) and in longer |
| 427 | names (`@g1t-bot`) are ignored. Matching ignores case. Agents mentioning |
| 428 | `@g1t` start nothing, so |
| 429 | agents cannot set each other to work this way. Neither does a comment made |
| 430 | with a workflow job's own token (`G1T_TOKEN`), so a workflow cannot set |
| 431 | off g1t whose push sets off the workflow again; see |
| 432 | [the job's token](/guides/actions/#the-jobs-token). |
| 433 | |
| 434 | **Who can.** People with the Write [role](/guides/access-and-roles/) or higher on the |
| 435 | repository, members or not. Anyone else who mentions it gets a short reply |
| 436 | saying that putting g1t to work needs the Write role on the |
| 437 | repository, and nothing starts. When |
| 438 | the workspace's plan does not let the agent start (a free workspace with no |
| 439 | trial left, a paused workspace, an issue at its spending cap), g1t |
| 440 | replies with why and where to fix it. When every agent slot is busy, it |
| 441 | replies that the run is waiting for a free slot, and starts it when one |
| 442 | finishes. |
| 443 | |
| 444 | Each comment starts one run at most; to ask again, write a new comment. |
| 445 | |
| 446 | A mention sends g1t back to a pull request it made even after it stopped |
| 447 | there, or used up the repository's revisions. At most 10 mentions in a day |
| 448 | send it back to the same pull request; past that, g1t replies that it |
| 449 | has reached the most it takes, and the next one works a day after the |
| 450 | first of those 10. |
| 451 | |
| 452 | ## The label rule |
| 453 | |
| 454 | Under a project's **Settings → Agents**, someone with the Maintain role or |
| 455 | higher sets a label, such as `agent`. From then on, when someone with the |
| 456 | Write role or higher gives an open issue that label, either |
| 457 | when opening it or later, g1t takes it: the issue is queued for |
| 458 | g1t, the conversation says so, and the agent starts as soon as the |
| 459 | project has room and nothing the issue depends on is still open, exactly as |
| 460 | for a [plan's](/guides/outcomes/) issues. An issue that already had the |
| 461 | label is not affected; removing and adding it again counts. **Turn off** |
| 462 | removes the rule. |
| 463 | |
| 464 | ## Which model runs |
| 465 | |
| 466 | You do not have to pick one. You assign the work to `g1t`, the way you |
| 467 | would assign an issue to a colleague, and **Auto** routes each job to the |
| 468 | least costly model that can do it, from three tiers: |
| 469 | |
| 470 | | Tier | Model today | For | |
| 471 | | --- | --- | --- | |
| 472 | | Fast | Claude Haiku 5.5 | Small, well-bounded work, and plans | |
| 473 | | Standard | Claude Sonnet 5.5 | Most changes and reviews | |
| 474 | | Most capable | Claude Opus 5.5 | Hard work, and work that failed on the standard model | |
| 475 | |
| 476 | The models are today's: when g1t moves a tier to a newer model, runs use |
| 477 | it within a minute. A model its provider retires is never used; the next |
| 478 | model for the tier runs, and the run's line says so. |
| 479 | |
| 480 | The job starts on its tier: |
| 481 | |
| 482 | | Work | Starts on | |
| 483 | | --- | --- | |
| 484 | | Making a change for an issue, revising it, and taking over handed-on work | Standard | |
| 485 | | Answering a question asked of `@g1t` | Fast | |
| 486 | | Reviewing a pull request that changes at most 10 files and 200 lines and touches no sensitive path | Fast | |
| 487 | | Reviewing a pull request that changes more than 60 files or 3,000 lines | Most capable | |
| 488 | | Reviewing any other pull request, or one whose changed files g1t does not know yet | Standard | |
| 489 | | Catching up with the base branch and resolving conflicts | Fast | |
| 490 | | Planning an outcome | Fast, at high effort | |
| 491 | |
| 492 | Then, in this order: |
| 493 | |
| 494 | 1. **Labels on the issue.** `architecture` sends the work to the most |
| 495 | capable model. `security` keeps it off the fast one. `documentation`, |
| 496 | `docs` and `typo` let a change or an answer start on the fast one. |
| 497 | 2. **Failures.** When the last attempt at the same work failed or stopped |
| 498 | at a guardrail cap, the next goes one tier up; after two in a row, to |
| 499 | the most capable. A revision counts each round before it. When the |
| 500 | last attempt finished but left a change g1t had |
| 501 | [low confidence](#how-sure-the-agent-is) in, the next goes one tier up. |
| 502 | 3. **What worked here.** g1t looks at the repository's last 20 runs of |
| 503 | the same kind. When the tier below finished at least 9 in 10 of at |
| 504 | least 5, the work goes down a tier; when this tier failed half of at |
| 505 | least 5, it goes up. Work that touches a sensitive path or carries |
| 506 | one of the labels above is never moved down. |
| 507 | |
| 508 | Sensitive paths are the ones that run, configure or guard things: CI |
| 509 | workflows, `.g1t/` and `.github/`, `CODEOWNERS`, secrets such as `.env` |
| 510 | and `.pem` files, and infrastructure such as Dockerfiles, Terraform and |
| 511 | `wrangler.*` files. They are the same paths that lower a change's |
| 512 | [confidence](#how-sure-the-agent-is). |
| 513 | |
| 514 | The agent's own small background steps run on the fast tier. |
| 515 | |
| 516 | Some work also has an effort level, how long the model thinks before it |
| 517 | answers: planning runs at high effort, answering a question at medium and |
| 518 | catching up at low, whichever tier the work lands on. Other work runs at |
| 519 | the model's default. A workspace's own provider is sent no effort level. |
| 520 | |
| 521 | Every run says which model it used and why, in one line: as the first |
| 522 | step on its run, and at the top of its pull request's session. For |
| 523 | example, *Used a fast model (Claude Haiku 5.5): small change, 3 files and |
| 524 | 80 lines.* An agent's review also says which model wrote it. When a better |
| 525 | model for a tier appears, g1t changes the route and nothing you have set |
| 526 | up needs to change. |
| 527 | |
| 528 | To choose instead of Auto, an owner picks **Fast**, **Standard** or **Most |
| 529 | capable** for a kind of work under |
| 530 | [which model does which work](/guides/models/#choose-which-model-does-which-work). |
| 531 | Every run of that kind then uses it, and says the workspace chose it. |
| 532 | |
| 533 | A workspace that routes its work to [its own provider](/guides/models/) |
| 534 | runs the model its route names. On an Anthropic key with no model named, |
| 535 | Auto chooses the tier's Claude model, as on g1t's models. |
| 536 | |
| 537 | A pull request g1t opens has `g1t` as its author and as its `agent` in the |
| 538 | API, and its commits are authored `g1t <g1t@users.noreply.g1t.sh>`. |
| 539 | |
| 540 | ## Who a pull request is for |
| 541 | |
| 542 | g1t is the author of every pull request it makes and of every issue it |
| 543 | files while at work. The person who asked for the work, by assigning the |
| 544 | issue or handing g1t the task, is kept beside it as **requested by**. Work |
| 545 | g1t starts itself, such as a [security update](/guides/security/), names |
| 546 | nobody. |
| 547 | |
| 548 | | Where | Author | Who asked | |
| 549 | | --- | --- | --- | |
| 550 | | The pull request's page, lists and link previews | **g1t** | **requested by** *name*, or **for** *name* | |
| 551 | | The API and MCP (`get_pull_request`, `list_pull_requests`, `get_issue`) | `author`: `{ "username": "g1t", "kind": "agent" }` | `requested_by`, or `null` | |
| 552 | | [Webhooks](/guides/webhooks/) | `data.author` | `data.requested_by`, left out when nobody asked | |
| 553 | | [Actions](/guides/actions/) (`github.event`) | `pull_request.user`, a `Bot` named `g1t` | `pull_request.requested_by`; `sender` is whoever caused the event | |
| 554 | | [Search](/guides/search/) | `author:g1t` finds it | shown as **for** *name* | |
| 555 | |
| 556 | The person who asked answers for the pull request as its author would: |
| 557 | |
| 558 | - they can update, close and mark it ready, catch it up and steer its |
| 559 | agent without the Triage role; |
| 560 | - they are never asked to review it, and they cannot approve it or |
| 561 | request changes on it; nor does their approval count toward the |
| 562 | repository's required approvals; |
| 563 | - it is on their own lists: what they are working on, and their profile; |
| 564 | - the sandboxes that work on it act as them, so it reaches what they can; |
| 565 | - its workflows and preview get secrets only when they have the Write |
| 566 | role or higher, as theirs would. |
| 567 | |
| 568 | Being its author gives g1t nothing more: a review by g1t's agent still |
| 569 | counts where the repository lets an agent's approval count. |
| 570 | |
| 571 | ## How model traffic is routed |
| 572 | |
| 573 | g1t's runs send model requests to g1t's model proxy at |
| 574 | `https://models.g1t.sh`, with a token for their run in place of a key; see |
| 575 | [your keys never reach a sandbox](/guides/models/#your-keys-never-reach-a-sandbox). |
| 576 | Requests for g1t's hosted models go on through |
| 577 | [Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/), |
| 578 | which holds g1t's key. Each of those requests is tagged with the kind of |
| 579 | work, the tier, the repository and the pull request, so spend can be read |
| 580 | per tier and per pull request. Requests for a workspace's own provider go to that provider. |
| 581 | |
| 582 | If you run your own copy of g1t, these settings control it: |
| 583 | |
| 584 | | Setting | Where | What it does | |
| 585 | | --- | --- | --- | |
| 586 | | `AGENT_ROUTING` | Runner | JSON. `tiers`: the model behind `small`, `large` and `frontier`, each `{ "modelName", "model", "price" }` (`price`, dollars per million `input`, `output`, `cacheRead` and `cacheWrite` tokens, is for estimates only). `tasks`: the tier `implement`, `revise`, `answer`, `review`, `update` and `plan` start on, or `change` to decide by the change. `smallChange` and `largeChange`: the most `files` and `lines` of a small change, and the least of a large one. `smallLabels`, `largeLabels` and `frontierLabels`: issue labels that move work. `frontierAfter`: failures in a row before the most capable tier. `learning`: `window`, `minRuns`, `stepDownAt` and `stepUpAt`. Anything left out takes the defaults above. | |
| 587 | | `MODELS_URL` | Runner | Where sandboxes send model requests: the model proxy. | |
| 588 | | `AI_GATEWAY_ID` | Model proxy | The gateway hosted requests go through. Empty sends them to the provider directly. | |
| 589 | | `AI_GATEWAY_TOKEN` | Model proxy | Secret. Authenticates to the gateway. | |
| 590 | | `ANTHROPIC_API_KEY` | Model proxy | Secret. The provider's key, if the gateway does not hold it. | |
| 591 | |
| 592 | ## What it costs |
| 593 | |
| 594 | A workspace pays for g1t's runs on its repositories, after they run: each |
| 595 | run is charged its sandbox by the second, at cost plus 20%, and the |
| 596 | [agent rate](/guides/usage-and-billing/#the-agent-rate) on the tokens it |
| 597 | used. On g1t's hosted models, the model is charged at what AI Gateway |
| 598 | priced its requests at, the provider's price with no markup. A |
| 599 | workspace's [own provider](/guides/models/) bills it for the model |
| 600 | directly; the agent rate is still charged, as **Agent rate, your own model |
| 601 | key**. See [Usage and billing](/guides/usage-and-billing/) for how prices |
| 602 | are set and the limits on usage not yet paid for. The workspace's |
| 603 | **Usage** page shows what its agents have cost, by day, kind of work, |
| 604 | repository and pull request, and their tokens by model. |
| 605 | |
| 606 | ## What a sandbox has |
| 607 | |
| 608 | Git, common shell tools, and toolchains for Node.js, Python, Go and Rust, so |
| 609 | an agent can build and test most projects. If your project needs something |
| 610 | else, the agent will say in its summary what it could not run. |
| 611 | |
| 612 | A workspace (or a project) can send its agents' work to |
| 613 | [its own runners](/guides/self-hosted-runners/#agents-on-your-runners) |
| 614 | instead, so agents build and test with what those machines have. The agent |
| 615 | works the same way there, with the same short-lived credentials, and its |
| 616 | model calls still go through g1t; the machine time is free. g1t's network |
| 617 | guardrails cannot be enforced on your machines, and the run says so. |
| 618 | |
| 619 | ## Who can run agents |
| 620 | |
| 621 | Putting an agent to work (assigning it, mentioning it, asking it for a |
| 622 | review, planning, sending it back to revise) needs the Write |
| 623 | [role](/guides/access-and-roles/) or higher on the repository. That |
| 624 | includes an [outside collaborator](/guides/access-and-roles/#outside-collaborators) |
| 625 | with Write: their runs are charged to the repository's workspace, as a |
| 626 | member's are, and count against its plan, caps and agent slots. They see |
| 627 | what their agents do, but not which model ran or what a run cost; those |
| 628 | are for members of the workspace. A run for an outside collaborator is |
| 629 | told the project's memory, never the workspace's. |
| 630 | |
| 631 | Agents cost g1t real money, so they run for paid workspaces. A free |
| 632 | workspace has the whole forge, and two ways to try agents: |
| 633 | |
| 634 | - **The trial.** $5 of usage, once per workspace, after a card check. |
| 635 | - **The open-source pool.** Workflows and the merge queue on public |
| 636 | repositories, after the same card check. It does not pay for agents. |
| 637 | |
| 638 | This holds whether the agent uses g1t's hosted models or |
| 639 | [the workspace's own model provider](/guides/models/): the sandbox an agent |
| 640 | works in is g1t's either way. Before anyone assigns, asks for a review or |
| 641 | plans, a free workspace's pages say "Agents need a paid workspace or the |
| 642 | free trial", with a link to its **Billing** page. |
| 643 | |
| 644 | Every agent run, of every kind (making a change, revising, reviewing, |
| 645 | catching up, planning, answering a mention), asks billing before it |
| 646 | starts. Billing reserves what the run is expected to cost: its model's |
| 647 | recent average (about $0.10 to make a change or plan, $0.07 to review) |
| 648 | plus its sandbox for its whole time cap. When the run ends, what it really |
| 649 | cost is settled against that. If billing refuses, nothing starts, and you |
| 650 | see why where you started it: |
| 651 | |
| 652 | | Where you started it | Where the refusal shows | |
| 653 | | --- | --- | |
| 654 | | **Assign to g1t**, **Request review**, **Plan it**, catching up | Under the button | |
| 655 | | A mention or the label rule | A comment from g1t on the issue or pull request | |
| 656 | | A step g1t takes by itself (a review, a revision, a catch-up) | The pull request's status, which then waits for you | |
| 657 | |
| 658 | Each refusal says what to do: start the plan or the trial, raise the spend |
| 659 | limit, or wait for next month's open-source pool, with the page to do it |
| 660 | on. |
| 661 | |
| 662 | ### Caps on a plan |
| 663 | |
| 664 | A workspace's plan sets caps on its agents. A new paid workspace in its |
| 665 | first month, and a workspace on the trial, has tighter ones. The amounts |
| 666 | are on [usage and billing](/guides/usage-and-billing/#caps). |
| 667 | |
| 668 | | Cap | What happens at it | |
| 669 | | --- | --- | |
| 670 | | Agents at once | A run over the cap waits for a free slot instead of being refused. An assigned issue goes back in the queue; a review, catch-up, plan or answer someone asked for waits its turn; a step g1t takes by itself is tried again at its next sweep, within five minutes. Each says "Waiting for a free slot". | |
| 671 | | Time per run | The lower of the project's [guardrails](/guides/guardrails/) time cap for that kind of run and the plan's. | |
| 672 | | Cost per run | The lower of the guardrails' cost cap and the plan's. The agent is stopped when it reaches it, as with any cost cap. | |
| 673 | | Cost per issue | What every agent run on an issue and its pull requests has cost in all. Past it, g1t does not start on that issue again and says so on it; an owner can raise the cap on the **Billing** page. | |
| 674 | |
| 675 | When the workspace's compute is paused (a spend spike waiting for an owner, |
| 676 | or a hold by g1t), nothing new starts, and the refusal gives the reason. |
| 677 | |
| 678 | ### When billing cannot be reached |
| 679 | |
| 680 | g1t's own billing service could be briefly unreachable. Then: |
| 681 | |
| 682 | - A paid workspace's runs go ahead, and the miss is logged. A billing blip |
| 683 | never stops a paying customer's work. |
| 684 | - A free workspace's runs do not start: they would be paid for by nobody. |
| 685 | Try again in a minute. |
| 686 | |
| 687 | g1t decides which a workspace is from its plan, or from the last plan it |
| 688 | saw for it in the past day. |
| 689 | |
| 690 | ### Other limits |
| 691 | |
| 692 | - A run has two hours. After that its credentials expire and it can no |
| 693 | longer push or report. |
| 694 | - Agents do not run on an [archived](/guides/managing-repositories/#archive-a-repository) |
| 695 | or deleted repository: nothing new starts, whether from an assignment, |
| 696 | a mention or the label rule, and a run under way cannot push or merge. |
| 697 | What was refused does not start by itself when the repository is |
| 698 | unarchived or restored; assign the work again. |
| 699 | |
| 700 | ## Credentials |
| 701 | |
| 702 | Every sandbox run gets credentials of its own, made when it starts and |
| 703 | revoked the moment it stops. They are not your access tokens, and they are |
| 704 | not listed with them. |
| 705 | |
| 706 | Each credential carries a composite identity: the agent, acting on behalf |
| 707 | of the person who started the work. A run you started by assigning an issue |
| 708 | is `g1t on behalf of you`, and that is how it appears in the |
| 709 | [audit log](/guides/audit-log/), on the run's page and in the pull |
| 710 | request's **Agent** panel. |
| 711 | |
| 712 | What it may do is the intersection of two things: |
| 713 | |
| 714 | - **The run's scope.** The credential is bound to the run, its repository, |
| 715 | and what that kind of run needs. It expires no later than the run's |
| 716 | timeout. |
| 717 | - **What you may do now.** It works only in the repository's workspace, |
| 718 | with your [role](/guides/access-and-roles/) on the repository as it is now, and never |
| 719 | more than Write: an owner's agent has Write, not Admin. If you leave the |
| 720 | workspace or lose your role, every agent working on your behalf there |
| 721 | loses it too. It can never change who has access. |
| 722 | |
| 723 | A sandbox holds two credentials. One is for g1t's runner, which clones, |
| 724 | pushes the result and records the session; downstream it acts as you, so |
| 725 | what it pushes is yours, within the run's scope. The other is for the |
| 726 | agent's own tools over MCP, and acts as the agent; it cannot be used with |
| 727 | git at all. |
| 728 | |
| 729 | | Kind of run | Git | API and MCP tools | |
| 730 | | --- | --- | --- | |
| 731 | | Implement | Reads the repository; pushes to its pull request's fork only | Records the session and marks its own pull request ready; tools to read issues, pull requests, the merge queue, workflow runs and memory, to [search all of g1t](/guides/search/) and the workspace's context hub, open issues, comment, remember, and message other agents | |
| 732 | | Revise, answer | Reads the repository; pushes to the pull request's fork, or to its branch only when the change is a branch of the repository | Records the session of its own pull request; the same tools as implement | |
| 733 | | Catch up | Reads the repository; pushes to the pull request's fork or branch only | Records the session of its own pull request | |
| 734 | | Review | Reads the change and the repository; pushes nothing | Reports its review through its own run | |
| 735 | | Plan | Reads the repository; pushes nothing | Reports its plan through its own run, for a person to apply; it can create issues in its repository only | |
| 736 | | Merge check | Reads the change; pushes nothing | None | |
| 737 | | Merge queue | Reads each queued change; pushes the queue's own branch only | None | |
| 738 | | Deploy | Reads the commit it builds; pushes nothing | None | |
| 739 | |
| 740 | Nothing an agent's credential holds can reach another repository, or a |
| 741 | workspace's settings, members, access tokens, billing, integrations, |
| 742 | webhooks, secrets and variables, or workflows' controls. It cannot merge a |
| 743 | pull request or put more agents to work. It cannot change its repository's |
| 744 | details or default branch, rename it or its branches, make it public or |
| 745 | private, archive, transfer, delete, restore or purge it; see |
| 746 | [managing a repository](/guides/managing-repositories/). A call that would is refused, and |
| 747 | the refusal is recorded with the rule that refused it: |
| 748 | |
| 749 | | Rule | Refused because | |
| 750 | | --- | --- | |
| 751 | | `never` | No agent's credential may ever do this. | |
| 752 | | `scope:operation` | The run's kind does not include this operation. | |
| 753 | | `scope:repository` | It names a repository other than the run's. | |
| 754 | | `scope:pull` | The runner tried to change a pull request other than its own. | |
| 755 | | `on-behalf-of:membership` | The person the agent works for is no longer a member of the workspace, and has no role on its repositories. | |
| 756 | | `git:read`, `git:push`, `git:ref` | The run has no grant to clone that repository, push to it, or move that branch or tag. | |
| 757 | | `git:not-a-run` | An agent's tools credential was used with git. | |
| 758 | |
| 759 | Personal and workspace access tokens are unchanged by any of this. |
| 760 | |
| 761 | ## What a sandbox can reach |
| 762 | |
| 763 | A sandbox holds one fork and its run's credentials, which expire when the |
| 764 | run's time is up and are revoked as soon as it stops. Those credentials, |
| 765 | and the model key the agent runs on, are removed from anything recorded in |
| 766 | the session. |
| 767 | |
| 768 | ## Guardrails |
| 769 | |
| 770 | A workspace decides what its agents may do in their sandboxes, and each |
| 771 | project can override it: which hosts a sandbox can reach (g1t, the package |
| 772 | registries the project needs, and domains you list; enforced outside the |
| 773 | sandbox), which commands the harness refuses (force-pushing, rewriting the |
| 774 | default branch, reading outside the project, printing the environment, |
| 775 | sudo, and your own patterns), and how much one run may cost and how long it |
| 776 | may take. A run that is refused something shows it as a step; one that |
| 777 | reaches a cap is stopped and its pull request waits for you. A run on a |
| 778 | fork's head loads none of the fork's `CLAUDE.md`, `.claude` settings, |
| 779 | hooks, MCP servers or commands. See [guardrails](/guides/guardrails/) for |
| 780 | every rule and exactly how each is enforced. |