Investigate: agent setup for every agent, and the workspace's AI as its own layer (AI gateway?) #187

Investigation first, then a recommendation. Build nothing until the owner picks a direction. There are two linked questions:

1. Can anyone build with g1t from whatever agent they use, and is our agent setup as good as the best there is? Use Cloudflare's as the bar: https://developers.cloudflare.com/agent-setup/
2. Should g1t treat a workspace's AI as a layer of its own, separate from how its developers use g1t, so the organization can see and control AI spend across every agent its people use? In effect, should g1t be (or include) an AI gateway? Come back with a pivot proposal for how this all fits.

What Cloudflare does (checked 2026-10-17; read it again, because it changes)

• One directory page. It has ten agent cards (Claude Code, Codex, Cursor, GitHub Copilot, OpenCode, Vibe, Devin, VS Code, Command Code, Bionic), filtered by workflow (Terminal, IDE, Cloud, Extension). Below them are a compare table and a short glossary of the tradeoffs in plain language. The table covers pricing (Subscription, Hybrid or BYOK), the model (locked or multi-provider), context (project memory or an indexed codebase) and whether the agent is open source.
• One guide per agent, with the same sections every time:
  • Quick start: install the agent. For Claude Code, /plugin marketplace add cloudflare/skills then /plugin install cloudflare@cloudflare.
  • Platform access: skills, MCP servers, the CLI, agent-friendly docs.
  • Example prompts, tips, FAQ, troubleshooting.
  • Building agents on Cloudflare.
  • Links to the other agents.
• MCP over OAuth. The first tool call opens authorization, and the user picks permissions. CI uses an API token as a bearer. The main server is "Code Mode" at mcp.cloudflare.com: search() and execute(), where the model writes code against the whole API. Focused servers (docs, browser, containers…) sit beside it.
• A skills pack of about 19 product skills, shipped as one plugin through their own marketplace repository.
• Nothing about spend, AI Gateway or BYOK on the agent pages, because their AI Gateway is a separate product. That's a gap g1t could own.

What g1t has today (verify each; start reading here)

• Plugins: plugins/claude-code (hooks that record sessions, plus skills and commands), plugins/codex (a skill and MCP, no hooks yet), and plugins/other-harnesses/AGENTS.snippet.md (pasted in by hand).
• The MCP server (apps/api/src/mcp.rs, tools.rs, operations.rs): resource tools, each with an action.
• Docs: guides/bring-your-own-agent.mdx ("connect an AI client"), guides/ai.md, guides/claude-code-plugin.md.
• Workspace AI (g1t.sh/<workspace>/-/ai): owners add providers on the workspace's own keys, and Ask, @g1t in Chat and hosted sessions use them. g1t hosts no model for this and bills nothing for it.
• Billing and spend: services/billing (budget.rs, limits.rs, costs.rs, usage, overages, grants), Usage at -/usage, and Actions and compute metering per workspace.
• Sessions are recorded per harness, with the model wherever the harness reports it. They now carry usage and estimated cost too (see #188).
• Related work items: #203 (work gets recorded in every harness) and #188 (agent spend per engineer). Build on them rather than duplicating them.

Investigate

1. Agent coverage. Take each agent on Cloudflare's list, plus ChatGPT, Claude desktop and web, Gemini CLI, Windsurf, Zed, Aider and Goose. Using current docs, find the extension points each has today: MCP (remote? OAuth?), skills, plugins or a marketplace, hooks, rules files. Then say what g1t gives each one now and what it could give, in setup steps, recording depth and auth. Present it as a matrix.

2. The setup page. Design g1t's equivalent: a directory, a guide per agent with the same skeleton, and a one-command or one-click install wherever the agent allows one. Ours can go further:

   • Personalize it for the signed-in workspace: its slug, a pre-authorized token or OAuth, the repository detected.
   • Show live that setup worked ("we see your session").
   • Offer the work-recording layers.

   Decide where it lives: the docs, the in-app -/ai and connect pages, or both. Compare g1t's MCP shape (resource tools) with Code Mode (search plus execute) and recommend one.

3. AI as a separate layer. Keep two things apart:

   • The organization's AI: providers, keys, models, budgets, policy, who may use what.
   • Its developers' use of g1t: sessions, work items, pull requests.

   Today the two are blurred. Lay out the options, from least to most:

   • Keep BYOK and report only the spend that harnesses expose.
   • Run an AI gateway: a g1t-hosted endpoint per workspace, compatible with the OpenAI and Anthropic APIs, that agents reach with a key the workspace issues. It would meter tokens and cost per person, session, work item and repository, enforce budgets and model policy, and route to the workspace's own providers. Spend would then sit next to the work it paid for ("#155 cost $14 across 3 agents").
   • Build on Cloudflare's AI Gateway: g1t runs on Workers, so wrap it or integrate it instead of rebuilding it.

   For each option, cover:

   • Which agents can be pointed at a custom base URL. Subscription-locked agents (Claude Code on a Max plan, Codex on ChatGPT) can't, so they need an "observed spend" path instead of a gateway.
   • Privacy: prompts would pass through g1t, so say what gets logged.
   • Billing in services/billing: pass-through or margin.
   • Effort.

4. The pivot. One page for the owner covering:

   • Positioning: "g1t is where your organization's agent work and AI spend live, whatever agent each developer uses."
   • The product surfaces: Agent setup, AI (providers, gateway, budgets), Work, Sessions.
   • What to build first, and what to drop or merge.
   • Risks.

Deliverable

A written recommendation with the matrix, the setup-page design (sketches are fine) and the gateway options compared. Publish it as a doc the owner can share with the team, and end with the decisions you need from the owner. Cite current sources with dates; check them rather than assuming. Make no code changes unless the owner says so, and open a work item for each direction the owner approves.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.