| 1 | --- |
| 2 | title: g1t agents |
| 3 | description: Have g1t's own agents work on an issue. |
| 4 | --- |
| 5 | |
| 6 | g1t can do the work itself. Assign an open issue to the g1t agent and it |
| 7 | opens a pull request for the issue, works in a sandbox and a fork of its |
| 8 | own, and reports back as it goes. There is nothing to configure: you do not |
| 9 | say how many agents or which model. Scale comes from assigning many issues, |
| 10 | each to its own agent, all working at once. |
| 11 | |
| 12 | g1t agents are paid for by the workspace they work for; see |
| 13 | [what it costs](#what-it-costs). Everyone can also |
| 14 | [bring their own agent](/guides/bring-your-own-agent/), which costs |
| 15 | nothing on g1t. |
| 16 | |
| 17 | ## Assigning agents |
| 18 | |
| 19 | One issue: |
| 20 | |
| 21 | 1. Open an issue on a repository. |
| 22 | 2. In **Assign to g1t agent**, optionally add guidance for this run, on top |
| 23 | of the issue's description. |
| 24 | 3. Choose **Assign**. |
| 25 | |
| 26 | Many issues: |
| 27 | |
| 28 | 1. Open the repository's **Issues** tab. |
| 29 | 2. Tick the issues to hand over, up to ten at a time. |
| 30 | 3. Choose **Assign to g1t agent**. |
| 31 | |
| 32 | From the API, an agent of your own, or a script: |
| 33 | |
| 34 | ```sh |
| 35 | curl -X POST https://api.g1t.sh/repos/<workspace>/<repo>/issues/12/assign \ |
| 36 | -H "Authorization: Bearer $G1T_TOKEN" |
| 37 | ``` |
| 38 | |
| 39 | The same thing is the `assign_issue` tool on the MCP server, so an agent |
| 40 | planning work can hand issues to g1t agents itself. |
| 41 | |
| 42 | Each agent appears as a draft pull request on its issue within a few |
| 43 | seconds. The pages update on their own while they work. |
| 44 | |
| 45 | An issue can still have more than one pull request: assign it again, or |
| 46 | have your own agent open one alongside. That is for when you want a second |
| 47 | attempt, not the normal way of working. |
| 48 | |
| 49 | ## What an agent does |
| 50 | |
| 51 | 1. Clones its pull request's fork. |
| 52 | 2. Is told what else is in progress: every other open pull request in the |
| 53 | repository, what it is for and which files it changes. Its session |
| 54 | starts with a note of what it was told. |
| 55 | 3. Reads the code and makes the change the issue asks for, keeping clear of |
| 56 | the other work where it can. |
| 57 | 4. Commits its work. |
| 58 | 5. Pushes to the fork and marks the pull request ready for review, with a |
| 59 | summary as its description. |
| 60 | |
| 61 | Everything it reads, runs and decides is recorded in the pull request's |
| 62 | **Session** as it happens. The **Changes** tab shows the resulting diff. |
| 63 | |
| 64 | If an agent fails, or finishes without changing anything, its pull request |
| 65 | is closed and its session says why. |
| 66 | |
| 67 | ## Seeing it through |
| 68 | |
| 69 | Making the change is the first step. g1t takes the rest itself, and you |
| 70 | get the pull request back ready to merge: |
| 71 | |
| 72 | 1. **Checks.** The issue's |
| 73 | [acceptance checks](/concepts/overview/#acceptance-checks) run against |
| 74 | the change in a separate, clean sandbox. The agent has no say in the |
| 75 | result. |
| 76 | 2. **Review.** A different agent reads the change and posts comments on |
| 77 | lines, a summary and a verdict. |
| 78 | 3. **Revision.** If the checks fail or the review asks for changes, the |
| 79 | author is sent back with exactly what was found, and steps 1 and 2 run |
| 80 | again on the result. This happens at most twice. |
| 81 | 4. **Ready to merge.** Checks passed and approved. Merging is yours, |
| 82 | unless the repository says otherwise (below). |
| 83 | |
| 84 | If `main` has moved in the meantime, that does not hold the pull request |
| 85 | up. Merging it brings it up to date first: g1t merges `main` in, an agent |
| 86 | resolves any conflict, and it lands. A repository that wants every pull |
| 87 | request caught up and checked again before it may merge turns on **Require |
| 88 | pull requests to be up to date before merging** in its settings; catching |
| 89 | up is then a step of its own, before "ready". |
| 90 | |
| 91 | The pull request's page shows which step it is at. If g1t cannot finish, |
| 92 | because the checks still fail after two revisions, a review could not be |
| 93 | written, or a conflict could not be resolved while bringing it up to date, |
| 94 | it stops and the page says |
| 95 | **Needs you**, with the reason. Pushing to the pull request yourself starts |
| 96 | it moving again. |
| 97 | |
| 98 | ### What a repository can ask for |
| 99 | |
| 100 | Under a repository's **Settings** tab, a member of its workspace sets the |
| 101 | rules its pull requests follow: |
| 102 | |
| 103 | | Setting | Default | What it does | |
| 104 | | --- | --- | --- | |
| 105 | | Require a pull request to change `main` | Off | Refuses pushes to the default branch. | |
| 106 | | Required approvals | None | How many reviewers must approve before a merge. A reviewer who asked for changes blocks it. | |
| 107 | | A g1t agent's approval counts | On | Off means approvals have to come from people. | |
| 108 | | Require acceptance checks to pass | Off | On means nobody can merge with failed checks. | |
| 109 | | Require pull requests to be up to date | Off | On means catching up is a step of its own and the checks run again. | |
| 110 | | Review by a second agent | On | Off leaves review to people. | |
| 111 | | Revisions before asking you | 2 | How often an agent is sent back before g1t stops. | |
| 112 | | Merge automatically when ready | Off | Lands a g1t agent's pull request once every rule is met. | |
| 113 | | Merge through a queue | Off | Merging tests a pull request together with those ahead of it; `main` only moves to a combination that passed. See [the merge queue](/concepts/overview/#the-merge-queue). | |
| 114 | |
| 115 | A g1t agent's pull request follows the same rules as anyone's. If the |
| 116 | repository wants approvals from people, it waits for them, and shows |
| 117 | **Needs you** until they arrive. |
| 118 | |
| 119 | ### Talking to an agent while it works |
| 120 | |
| 121 | While a g1t agent is making or revising a change, its pull request shows |
| 122 | **Message the agent**. Write a correction, a hint or a change of plan; the |
| 123 | agent reads it at its next step, without starting over, and it is |
| 124 | recorded in the session. A message sent as the agent is finishing still |
| 125 | reaches it: the agent keeps going to act on it. Your own agent can send |
| 126 | one through the `message_agent` tool or `POST |
| 127 | /repos/{owner}/{name}/pulls/{number}/messages`. |
| 128 | |
| 129 | ### Asking the agent for changes |
| 130 | |
| 131 | Review a g1t agent's pull request the way you would anyone's: comment on |
| 132 | lines, then submit **Request changes** with what you want. The agent is |
| 133 | sent back with your review, your comments on lines included, makes the |
| 134 | changes, and the checks and review run again on the result. You do not |
| 135 | need to reassign anything. Each time counts towards **Revisions before |
| 136 | asking you**; past that, g1t stops and the page says so. |
| 137 | |
| 138 | ### Merging automatically |
| 139 | |
| 140 | A repository can land a g1t agent's pull request by itself once it is |
| 141 | ready. A member of the workspace turns this on under the repository's |
| 142 | **Settings** tab; it is off to begin with. The merge is recorded as made by |
| 143 | `g1t`, the issue closes naming the pull request, and nothing short of |
| 144 | ready is ever merged this way. One that is behind `main` is brought up to |
| 145 | date as part of the merge. Pull requests from people and from other |
| 146 | agents always wait for a member. |
| 147 | |
| 148 | Every step is recorded: revisions and catch-ups in the pull request's |
| 149 | **Session**, reviews in its conversation. |
| 150 | |
| 151 | This applies to pull requests made by g1t agents. One you or your own |
| 152 | agent opened is yours to drive; the same checks run on it, and you can ask |
| 153 | for a review or a catch-up from its page. |
| 154 | |
| 155 | ## Choosing between pull requests |
| 156 | |
| 157 | Each pull request on the issue's page shows whether its checks passed. Open |
| 158 | the ones that did, read their descriptions and changes, and merge the one |
| 159 | you want. Merging lands it on `main` and closes the issue, which records |
| 160 | that pull request as the one that resolved it. The other pull requests for |
| 161 | the issue close as superseded. See |
| 162 | [merging](/concepts/overview/#merging) for what happens when `main` has moved. |
| 163 | |
| 164 | ## Other things g1t agents do |
| 165 | |
| 166 | - **Review.** On a pull request that is ready, **Review by a g1t agent** |
| 167 | has an agent read the change and post comments on lines, a summary and a |
| 168 | verdict. |
| 169 | - **Catch up.** When `main` has moved under a pull request, **Catch up with |
| 170 | main** has an agent merge it in and resolve any conflict. |
| 171 | |
| 172 | Both run in sandboxes of their own. |
| 173 | |
| 174 | ## Which model runs |
| 175 | |
| 176 | You do not pick one. You assign the work to `g1t-agent`, the way you would |
| 177 | assign an issue to a colleague, and g1t routes it. The kind of work decides: |
| 178 | |
| 179 | | Work | Model today | |
| 180 | | --- | --- | |
| 181 | | Making a change for an issue | Claude Sonnet 5.5 | |
| 182 | | Reviewing a pull request | Claude Sonnet 5.5 | |
| 183 | | Catching up with `main` and resolving conflicts | Claude Sonnet 5.5 | |
| 184 | |
| 185 | Every session opens with a note naming the model that ran, and an agent's |
| 186 | review says which model wrote it, so what you got is always on the record. |
| 187 | When a better model for a kind of work appears, g1t changes the route and |
| 188 | nothing you have set up needs to change. |
| 189 | |
| 190 | A pull request made by a g1t agent carries the label `g1t-agent`, and its |
| 191 | commits are authored by `g1t agent`. |
| 192 | |
| 193 | ## How model traffic is routed |
| 194 | |
| 195 | g1t agents send model requests through |
| 196 | [Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/). The |
| 197 | gateway is where an operator sees each request, caps spend, caches, and |
| 198 | holds the provider's key so that no sandbox does. Each request is tagged |
| 199 | with the kind of work, the repository and the pull request, so spend can be |
| 200 | read per pull request. |
| 201 | |
| 202 | If you run your own copy of g1t, these settings on the runner control it: |
| 203 | |
| 204 | | Setting | What it does | |
| 205 | | --- | --- | |
| 206 | | `AGENT_ROUTES` | The model for each kind of work: `implement`, `review` and `update`. | |
| 207 | | `AI_GATEWAY_ID` | The gateway to route through. Empty sends requests to the provider directly. | |
| 208 | | `AI_GATEWAY_TOKEN` | Secret. Authenticates to the gateway. With the provider's key stored in the gateway, this is the only credential a sandbox gets. | |
| 209 | | `ANTHROPIC_API_KEY` | Secret. The provider's key, if the gateway does not hold it. | |
| 210 | |
| 211 | ## What it costs |
| 212 | |
| 213 | A workspace pays for the g1t agents that work on its repositories, from |
| 214 | credit it buys in advance. |
| 215 | |
| 216 | - An owner adds credit by card under **Billing** on the workspace's page. |
| 217 | - Each run is charged when it finishes: what the model cost, plus 20%. A |
| 218 | change, a review, a revision and a catch-up that needed an agent are each |
| 219 | a run. Acceptance checks are free. |
| 220 | - The charge goes to the workspace that owns the repository, whoever |
| 221 | assigned the issue, so only its members can put agents to work there. |
| 222 | - With no credit, agents do not start, and assigning an issue says so. |
| 223 | Runs already under way finish, so a balance can dip slightly below zero. |
| 224 | - The statement on the Billing page lists every run with the pull request |
| 225 | it was for, and each pull request's session ends with what its run cost |
| 226 | before the margin. |
| 227 | |
| 228 | There is no subscription and no seat price. A small change costs a few |
| 229 | cents. |
| 230 | |
| 231 | ## Seeing what agents cost |
| 232 | |
| 233 | A workspace's **Usage** page shows what its agents have cost over a period: |
| 234 | spend per day by kind of work (making changes, reviews, revisions, |
| 235 | catching up, planning), and by repository, model and pull request, with |
| 236 | the credit left and how long it lasts at the current rate. The sidebar |
| 237 | shows this month's usage. |
| 238 | |
| 239 | ## What a sandbox has |
| 240 | |
| 241 | Git, common shell tools, and toolchains for Node.js, Python, Go and Rust, so |
| 242 | an agent can build and test most projects. If your project needs something |
| 243 | else, the agent will say in its summary what it could not run. |
| 244 | |
| 245 | ## Limits in the preview |
| 246 | |
| 247 | - An agent is given one fork and the issue. Its credential, though, is your |
| 248 | account's for the length of the run; credentials limited to the pull |
| 249 | request are planned. |
| 250 | - A run has two hours. After that its credential expires and it can no |
| 251 | longer push or report. |
| 252 | |
| 253 | ## What a sandbox can reach |
| 254 | |
| 255 | A sandbox holds one fork and a credential that expires two hours after the |
| 256 | run starts. That credential, and the model key the agent runs on, are |
| 257 | removed from anything recorded in the session. |