Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.
| Deploy scripts live in the repository | 1 | { |
| 2 | "$schema": "../../node_modules/wrangler/config-schema.json", | |
| 3 | "name": "g1t-runner", | |
| 4 | "account_id": "1e6f2cffa3f445920836e8ebe446bb58", | |
| 5 | "compatibility_date": "2026-09-26", | |
| 6 | "main": "./src/index.ts", | |
| 7 | "workers_dev": false, | |
| Fast pages, required checks on the branch, self-hosted runners, honest incidents | 8 | // One image (the base plus the runner binary), on three machine sizes. |
| 9 | // scripts/deploy.mjs deploys with each image set to the reference it | |
| The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were. | 10 | // built and pushed ("The runner's images" in |
| 11 | // docs.g1t.sh/guides/deploy-to-cloudflare/), so a deploy builds | |
| 12 | // nothing; "./Dockerfile" here is for building by hand. | |
| Deploy scripts live in the repository | 13 | "containers": [ |
| 14 | { | |
| 15 | "class_name": "AttemptSandbox", | |
| 16 | "image": "./Dockerfile", | |
| 17 | "instance_type": "standard-1", | |
| 18 | "max_instances": 20, | |
| 19 | // A deploy replaces sandboxes. Ones that are busy are given this | |
| 20 | // long, in seconds, to finish first, so shipping g1t does not | |
| 21 | // kill agents in the middle of their work. | |
| 22 | "rollout_active_grace_period": 7200 | |
| Fast pages, required checks on the branch, self-hosted runners, honest incidents | 23 | }, |
| 24 | { | |
| 25 | // Workflow jobs with `runs-on: g1t-2core`: 2 vCPU, 8 GiB, 16 GB. | |
| 26 | "class_name": "Sandbox2Core", | |
| 27 | "image": "./Dockerfile", | |
| 28 | "instance_type": "standard-3", | |
| 29 | "max_instances": 10, | |
| 30 | "rollout_active_grace_period": 7200 | |
| 31 | }, | |
| 32 | { | |
| 33 | // Workflow jobs with `runs-on: g1t-4core`: 4 vCPU, 12 GiB, 20 GB. | |
| 34 | "class_name": "Sandbox4Core", | |
| 35 | "image": "./Dockerfile", | |
| 36 | "instance_type": "standard-4", | |
| 37 | "max_instances": 10, | |
| 38 | "rollout_active_grace_period": 7200 | |
| Every agent can have its own computer. A session that needs one wakes it: a home of its own on g1t cloud, one per agent and never shared, where it runs commands, reads and writes files and keeps what it made, with each session working in its own folder under a shared home; after ten idle minutes it sleeps, its home kept as a snapshot and restored when it wakes, and Reset wipes the home while memory and artifacts stay. Its shell and files are abilities with the usual choices, Alone, Alone when asked, Ask first or Never, offered only inside sessions and never to a chat reply; every command shows on the session with its output, and the agent's new Computer tab shows the state, the disk used of the five gigabytes included, the recent commands, and Wake, Put to sleep and Reset. Machine time counts only while it is awake, on the sandbox lines of the ledger that name the agent and who asked, held to the same spend caps as the session; the disk itself costs nothing in this version. The runner gained a long-lived supervisor that answers the computer's requests inside the container, and the runner service a computer per agent that keeps its snapshot in the agent homes bucket when one is attached, and says so when none is. The REST API and the agent tool can read a computer, wake it, put it to sleep and reset it. The agents, abilities, sessions, runners, billing and deploy guides say how it works and what an operator sets up; pinning a computer to your own runner, its browser and take-over come next. | 39 | }, |
| 40 | { | |
| 41 | // Workspace agents' own computers (src/computer.ts): the same image | |
| 42 | // in MODE=computer, one per agent, awake only while a session uses | |
| 43 | // it. Modest to start; raise it as agents get computers. | |
| 44 | "class_name": "AgentComputer", | |
| 45 | "image": "./Dockerfile", | |
| 46 | "instance_type": "standard-1", | |
| 47 | "max_instances": 20, | |
| 48 | "rollout_active_grace_period": 7200 | |
| Deploy scripts live in the repository | 49 | } |
| 50 | ], | |
| 51 | "durable_objects": { | |
| Fast pages, required checks on the branch, self-hosted runners, honest incidents | 52 | "bindings": [ |
| 53 | { "name": "SANDBOX", "class_name": "AttemptSandbox" }, | |
| 54 | { "name": "SANDBOX_2CORE", "class_name": "Sandbox2Core" }, | |
| Every agent can have its own computer. A session that needs one wakes it: a home of its own on g1t cloud, one per agent and never shared, where it runs commands, reads and writes files and keeps what it made, with each session working in its own folder under a shared home; after ten idle minutes it sleeps, its home kept as a snapshot and restored when it wakes, and Reset wipes the home while memory and artifacts stay. Its shell and files are abilities with the usual choices, Alone, Alone when asked, Ask first or Never, offered only inside sessions and never to a chat reply; every command shows on the session with its output, and the agent's new Computer tab shows the state, the disk used of the five gigabytes included, the recent commands, and Wake, Put to sleep and Reset. Machine time counts only while it is awake, on the sandbox lines of the ledger that name the agent and who asked, held to the same spend caps as the session; the disk itself costs nothing in this version. The runner gained a long-lived supervisor that answers the computer's requests inside the container, and the runner service a computer per agent that keeps its snapshot in the agent homes bucket when one is attached, and says so when none is. The REST API and the agent tool can read a computer, wake it, put it to sleep and reset it. The agents, abilities, sessions, runners, billing and deploy guides say how it works and what an operator sets up; pinning a computer to your own runner, its browser and take-over come next. | 55 | { "name": "SANDBOX_4CORE", "class_name": "Sandbox4Core" }, |
| 56 | { "name": "COMPUTER", "class_name": "AgentComputer" } | |
| Fast pages, required checks on the branch, self-hosted runners, honest incidents | 57 | ] |
| Deploy scripts live in the repository | 58 | }, |
| Fast pages, required checks on the branch, self-hosted runners, honest incidents | 59 | "migrations": [ |
| 60 | { "tag": "v1", "new_sqlite_classes": ["AttemptSandbox"] }, | |
| Every agent can have its own computer. A session that needs one wakes it: a home of its own on g1t cloud, one per agent and never shared, where it runs commands, reads and writes files and keeps what it made, with each session working in its own folder under a shared home; after ten idle minutes it sleeps, its home kept as a snapshot and restored when it wakes, and Reset wipes the home while memory and artifacts stay. Its shell and files are abilities with the usual choices, Alone, Alone when asked, Ask first or Never, offered only inside sessions and never to a chat reply; every command shows on the session with its output, and the agent's new Computer tab shows the state, the disk used of the five gigabytes included, the recent commands, and Wake, Put to sleep and Reset. Machine time counts only while it is awake, on the sandbox lines of the ledger that name the agent and who asked, held to the same spend caps as the session; the disk itself costs nothing in this version. The runner gained a long-lived supervisor that answers the computer's requests inside the container, and the runner service a computer per agent that keeps its snapshot in the agent homes bucket when one is attached, and says so when none is. The REST API and the agent tool can read a computer, wake it, put it to sleep and reset it. The agents, abilities, sessions, runners, billing and deploy guides say how it works and what an operator sets up; pinning a computer to your own runner, its browser and take-over come next. | 61 | { "tag": "v2", "new_sqlite_classes": ["Sandbox2Core", "Sandbox4Core"] }, |
| 62 | { "tag": "v3", "new_sqlite_classes": ["AgentComputer"] } | |
| Fast pages, required checks on the branch, self-hosted runners, honest incidents | 63 | ], |
| Every agent can have its own computer. A session that needs one wakes it: a home of its own on g1t cloud, one per agent and never shared, where it runs commands, reads and writes files and keeps what it made, with each session working in its own folder under a shared home; after ten idle minutes it sleeps, its home kept as a snapshot and restored when it wakes, and Reset wipes the home while memory and artifacts stay. Its shell and files are abilities with the usual choices, Alone, Alone when asked, Ask first or Never, offered only inside sessions and never to a chat reply; every command shows on the session with its output, and the agent's new Computer tab shows the state, the disk used of the five gigabytes included, the recent commands, and Wake, Put to sleep and Reset. Machine time counts only while it is awake, on the sandbox lines of the ledger that name the agent and who asked, held to the same spend caps as the session; the disk itself costs nothing in this version. The runner gained a long-lived supervisor that answers the computer's requests inside the container, and the runner service a computer per agent that keeps its snapshot in the agent homes bucket when one is attached, and says so when none is. The REST API and the agent tool can read a computer, wake it, put it to sleep and reset it. The agents, abilities, sessions, runners, billing and deploy guides say how it works and what an operator sets up; pinning a computer to your own runner, its browser and take-over come next. | 64 | // Where agents' computers keep their homes between wakes (src/computer.ts). |
| 65 | // NOT YET ENABLED: the bucket does not exist, and a deploy with a binding | |
| 66 | // to a missing bucket fails. The operator creates it, then uncomments | |
| 67 | // this block ("Agents' computers" in docs.g1t.sh/guides/deploy-to-cloudflare/): | |
| 68 | // | |
| 69 | // npx wrangler r2 bucket create g1t-agent-homes | |
| 70 | // npx wrangler r2 bucket lifecycle add g1t-agent-homes abort-uploads homes/ --abort-multipart-days 1 | |
| 71 | // | |
| 72 | // Until then computers work but forget their home when they sleep, and | |
| 73 | // the Computer tab says the disk isn't attached yet. | |
| 74 | // | |
| 75 | // "r2_buckets": [{ "binding": "HOMES", "bucket_name": "g1t-agent-homes" }], | |
| Deploy scripts live in the repository | 76 | "services": [ |
| 77 | { "binding": "IDENTITY", "service": "g1t-identity" }, | |
| 78 | { "binding": "REPOS", "service": "g1t-repos" }, | |
| 79 | { "binding": "WORK", "service": "g1t-work" }, | |
| 80 | { "binding": "BILLING", "service": "g1t-billing" }, | |
| 81 | { "binding": "INTEGRATIONS", "service": "g1t-integrations" }, | |
| 82 | { "binding": "ACTIONS", "service": "g1t-actions" }, | |
| Project dependencies: addresses, preview stacks, Affects, and agents who know | 83 | { "binding": "DEPLOYMENTS", "service": "g1t-deployments" }, |
| Agents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API | 84 | { "binding": "PROJECTS", "service": "g1t-projects" }, |
| 85 | // The context hub: the Context section every agent run starts with. | |
| Invite-only launch: sign in with GitHub, repository access and lifecycle, many emails, a new look | 86 | { "binding": "CONTEXT", "service": "g1t-context" }, |
| 87 | // The event bus: abuse.flagged, when a sandbox looks like it is mining. | |
| 88 | { "binding": "EVENTS", "service": "g1t-events" } | |
| Deploy scripts live in the repository | 89 | ], |
| 90 | // A sweep for lifecycle steps whose trigger was missed or whose sandbox | |
| Merge branch 'worktree-agent-ac5b181a013e54348' | 91 | // died before reporting, which also starts queued nightly backups. |
| Deploy scripts live in the repository | 92 | "triggers": { "crons": ["*/5 * * * *"] }, |
| 93 | // Events it reacts to: a pull request ready for review, or its head moving. | |
| 94 | "queues": { | |
| Merge branch 'worktree-agent-ad8a36dfcd4176015' into spend-guardrails | 95 | "consumers": [{ "queue": "g1t-events-runner", "max_batch_size": 20, "max_batch_timeout": 1, "max_retries": 3, "dead_letter_queue": "g1t-events-dlq" }] |
| Deploy scripts live in the repository | 96 | }, |
| 97 | "vars": { | |
| 98 | // Each workspace chooses where its agents' model spend goes: its own | |
| 99 | // provider (under Integrations) or g1t's hosted models, paid from its | |
| 100 | // credit. While billing takes no real money, hosted models are open | |
| 101 | // only to these workspaces; once it does, to every workspace. | |
| Invite-only launch: sign in with GitHub, repository access and lifecycle, many emails, a new look | 102 | "HOSTED_AGENT_WORKSPACES": "flagon-io", |
| Merge branch 'model-routing' | 103 | // How g1t routes agent work: "Auto" (AgentRouting and route in |
| 104 | // src/model-env.ts). Nobody assigning an agent has to choose; a workspace | |
| Merge branch 'main' into actions-toolkit-oidc-artifacts | 105 | // can still choose a tier per kind of work under Integrations. Staff |
| 106 | // choose each tier's model, the background model and each job's tier and | |
| 107 | // effort in sudo (Agents & models; billing's model_defaults), which the | |
| 108 | // runner reads once a minute and puts on top of this. So "tiers", "tasks" | |
| 109 | // and "effort" here apply only while billing cannot be read; the labels, | |
| 110 | // change sizes, "frontierAfter" and "learning" always do. "tiers": the | |
| Merge branch 'model-routing' | 111 | // catalogue, the model behind small (fast), large (standard) and frontier |
| 112 | // (most capable); "modelName" is shown to people, "model" is sent to the | |
| 113 | // provider, "price" (dollars per million tokens) is for estimates only. | |
| 114 | // "tasks": the tier each kind of job starts on, or "change" to size the | |
| 115 | // change a review reads ("smallChange" or less and nothing sensitive: small; | |
| 116 | // more than "largeChange": frontier). "frontierLabels", "largeLabels" and | |
| 117 | // "smallLabels" move work by its issue's labels. A failed attempt goes one | |
| 118 | // tier up and "frontierAfter" failures in a row to frontier; "learning" | |
| 119 | // steps work down or up by the repository's own recent runs of the kind. | |
| Merge branch 'main' into worktree-agent-a69aeabc4b0deeb97 | 120 | "AGENT_ROUTING": "{\"tiers\":{\"small\":{\"modelName\":\"Claude Haiku 5.5\",\"model\":\"claude-haiku-5-5\",\"price\":{\"input\":0.1,\"output\":0.5,\"cacheRead\":0.01,\"cacheWrite\":0.125}},\"large\":{\"modelName\":\"Claude Sonnet 5.5\",\"model\":\"claude-sonnet-5-5\",\"price\":{\"input\":2,\"output\":10,\"cacheRead\":0.1,\"cacheWrite\":2.5}},\"frontier\":{\"modelName\":\"Claude Opus 5.5\",\"model\":\"claude-opus-5-5\",\"price\":{\"input\":4,\"output\":20,\"cacheRead\":0.2,\"cacheWrite\":5}}},\"tasks\":{\"implement\":\"large\",\"revise\":\"large\",\"answer\":\"small\",\"review\":\"change\",\"update\":\"small\",\"plan\":\"small\"},\"effort\":{\"plan\":\"high\",\"answer\":\"medium\",\"update\":\"low\"},\"smallChange\":{\"files\":10,\"lines\":200},\"largeChange\":{\"files\":60,\"lines\":3000},\"largeLabels\":[\"security\"],\"frontierLabels\":[\"architecture\"],\"smallLabels\":[\"documentation\",\"docs\",\"typo\"],\"frontierAfter\":2,\"learning\":{\"window\":20,\"minRuns\":5,\"stepDownAt\":0.9,\"stepUpAt\":0.5}}", |
| Deploy scripts live in the repository | 121 | // Where sandboxes send model requests, with a token for their run. |
| 122 | // The proxy holds the keys: g1t's gateway's, or the workspace's own. | |
| 123 | "MODELS_URL": "https://models.g1t.sh", | |
| 124 | // Set to a Cloudflare AI Gateway id to route model traffic through it. | |
| 125 | // Used only when MODELS_URL is unset. | |
| 126 | "AI_GATEWAY_ID": "g1t", | |
| Agents get guardrails, run credentials, an audit log, a context hub, repository instructions and mentions; security upkeep; snake_case API | 127 | "CLOUDFLARE_ACCOUNT_ID": "1e6f2cffa3f445920836e8ebe446bb58", |
| 128 | // Guardrails' network list is enforced by starting sandboxes without | |
| 129 | // internet and passing their HTTP(S) through this Worker. "off" opens | |
| 130 | // every sandbox's network again, whatever its guardrails say. | |
| Invite-only launch: sign in with GitHub, repository access and lifecycle, many emails, a new look | 131 | "EGRESS": "enforce", |
| 132 | // Sandboxes stop themselves when they look like they are mining | |
| 133 | // (crates/runner abuse.rs). "off" turns the CPU watch off; miners | |
| 134 | // named in commands are refused either way. | |
| Merge branch 'worktree-agent-ac5b181a013e54348' | 135 | "ABUSE_WATCH": "on", |
| Merge branch 'main' into actions-toolkit-oidc-artifacts | 136 | // Each workflow job gets a Docker Engine of its own, inside its |
| 137 | // sandbox, started the first time a step uses Docker or the job has | |
| 138 | // `services:` or `container:` (crates/runner docker/). "off" gives | |
| 139 | // jobs none. | |
| 140 | "DOCKER": "on", | |
| Merge branch 'worktree-agent-ac5b181a013e54348' | 141 | // Nightly backups (src/backup.ts): each sweep starts this many of the |
| 142 | // backups the repos service queued, with at most BACKUPS_RUNNING at | |
| 143 | // once. "0" starts none. | |
| 144 | "BACKUPS_PER_SWEEP": "4", | |
| 145 | "BACKUPS_RUNNING": "6" | |
| Deploy scripts live in the repository | 146 | }, |
| Merge branch 'worktree-agent-a8752162fea25f63f' into spend-guardrails | 147 | // Every log kept: few requests, and a failed run must be traceable. |
| 148 | "observability": { "enabled": true, "head_sampling_rate": 1 } | |
| Deploy scripts live in the repository | 149 | } |
This file's history is long; its oldest lines are credited to the oldest commit read.