Posts tagged with “tools”

One endpoint for all your AI subscriptions

If you run coding agents all day, you know the moment: Claude Code stops mid-task because the five-hour window ran out, and you go hunting for the other account. agent-quota-gateway is the small Go binary I wrote so that moment never comes.

What it does. Your agents talk to one local endpoint instead of to Anthropic or OpenAI directly. They don't carry a real token; they send a pool name. The gateway holds the credentials, keeps each agent on one account, and when that account returns a real 429 it fails over to the next one, in the order you declared. When the whole pool is dry it answers 503 with a Retry-After, so Claude Code waits for the reset and resumes instead of ending the turn. The first time it worked, I wrote: the subscription burned out and Claude Code moved to the next one without noticing.

What makes it different.

  • Credentials stay at the gateway and are never logged, so you can hand a pool name to any worker, on any machine.
  • Pool several people's subscriptions and use them off-peak: for a small team, everyone's five-hour quota gets several times larger.
  • Per-worker affinity: each agent sticks to one account, so prompt caches survive; a pool's concurrency decides how many accounts serve at once.
  • Anthropic Messages and OpenAI-compatible Responses pass through untouched, so new endpoints and beta headers work on day one.
  • One stdlib-only binary, a systemd deploy script, a quota dashboard, and shared mode over Tailscale or OpenVPN.

What it is not. It doesn't translate between providers, meter usage, or bill anyone. It is a thin proxy on purpose.

Price. Free. The source is on GitHub under BSL 1.1: read it, change it, run it at home or at work, in production. The only thing you may not do is sell it as a hosted service. Each release becomes Apache 2.0 four years on.

I built it for my own agent fleet (it runs my-ai-team), and I have installed it for a company that wanted to pool its Claude seats. Try it: https://github.com/SHUKE-LABS/agent-quota-gateway

Pair review with an agent, one diff block at a time — and the browser follows along

Diffwalk's own agent skill is a one-shot author: the agent reads the whole change, writes an ordered explanation for every block, and hands you a finished walkthrough. That's great for documenting your own PR, but when you're reviewing a colleague's PR it anchors you to the agent's verdict before you've formed your own.

pair-review turns the same CLI into a dialogue. The agent slices the diff into review units (a signature change travels with its call sites), opens the diff in the browser, then takes one unit per round: says what it does, raises its own suspicions, and stops for your take. The agreed text — not the debate — goes into the walk's explanations.yaml, so an interrupted review resumes at the next pending unit instead of starting over. A GitHub comment is only posted after you confirm its exact draft.

The newest bit: when the agent talks about a unit, the browser scrolls there and highlights the exact lines. It works through the Chrome DevTools Protocol. split-view launches a dedicated Chrome/Edge (separate profile, CDP port 9333) in the top half of the screen with the terminal below. Then each round the agent runs something like:

node scripts/focus.mjs change-003 --at src/Orders/OrderService.cs:42-50 --at src/Orders/OrderService.cs:40:old

focus.mjs attaches to that browser with Playwright's connectOverCDP, expands the file, and marks rows in the diff's shadow DOM. This works in split or unified layout, on the new side or (:old) the deleted side. The first range is scrolled to the centre of the screen. Your terminal keeps keyboard focus throughout, unlike the old approach of typing an anchor URL into the omnibox.

It needs a patched Diffwalk build: shukebeta/diffwalk branch local-both adds a Wrap toggle for long lines and shows each block's change-0NN id on the page, so "change-012" is something you can actually see. Build it with the bun version CI pins. A different bun silently tree-shakes the report's web components, and every diff renders unstyled:

git clone -b local-both https://github.com/shukebeta/diffwalk.git
cd diffwalk
npx --yes [email protected] install
npx --yes [email protected] run build
alias diffwalk="node $PWD/dist/diffwalk.js"   # add to your shell profile

Then install the skill and its one dependency (playwright-core, no browser download — it drives the Chrome you already have):

npx skills add shuke-personal/pair-review-skill --skill pair-review -g
cd ~/.claude/skills/pair-review/scripts && npm i

Start a new agent session and say "pair review this PR". Split view plus highlighting is scripted for Windows and Linux/X11. On macOS, start the CDP browser by hand (the command is in SKILL.md §3) and focus.mjs works unchanged.

Two GitHub accounts on one machine? Let one gh wrapper hand git the right token

If you keep a personal and a work GitHub account on the same machine, you have probably hit this: gh auth login both accounts, run gh auth setup-git, and half your repos start returning Repository not found. That's because gh auth git-credential always answers with the keyring's active account. It never looks at which repo git is asking about.

The fix is to put a small wrapper in front of the real gh. The wrapper picks a token by repo owner, and git uses the same wrapper as its credential helper. Now both gh and plain git go through one place that knows about your accounts.

The heart of the wrapper is a few lines of bash (save as ~/bin/gh-route, keep the real gh on PATH):

#!/usr/bin/env bash
# Pick a token by owner, then run the real gh with it.
owner_from() { sed -E 's#^(https://github.com/|[email protected]:)##; s#/.*##'; }

if [[ "$1 $2" == "auth git-credential" ]]; then
    req="$(cat)"                                   # git's request, on stdin
    owner="$(sed -n 's#^path=\([^/]*\)/.*#\1#p' <<< "$req")"
fi
[[ -n "$owner" ]] || owner="$(git remote get-url origin 2>/dev/null | owner_from)"

case "${owner,,}" in
    my-work-org|my-work-user) export GH_TOKEN="$GH_TOKEN_WORK" ;;
    ?*)                       export GH_TOKEN="$GH_TOKEN_PERSONAL" ;;
esac

if [[ -n "$req" ]]; then gh "$@" <<< "$req"; else gh "$@"; fi

Then wire git to it, and move everything to HTTPS:

# ~/.gitconfig
[credential "https://github.com"]
    helper =
    helper = !bash ~/bin/gh-route auth git-credential
    useHttpPath = true
[url "https://github.com/"]
    insteadOf = [email protected]:
    insteadOf = ssh://[email protected]/

useHttpPath is what makes this reliable. Without it git only tells the helper host=github.com, so the wrapper has to guess from the current directory, and git ls-remote <url> run outside a repo gets the wrong account. With it git sends path=<owner>/<repo>.git, so the owner is right there in the request. (git clone happens to work either way: git writes origin into the new repo and exports GIT_DIR before it asks for credentials.)

The insteadOf lines rewrite existing [email protected]: remotes on the fly, so you don't have to edit a single .git/config. HTTPS also gets through networks that reset SSH, and it's the only transport GitHub App installation tokens work with.

One trap: never run gh auth setup-git again. It appends its own [credential "https://github.com"] block after your include, and its empty helper = line silently wipes out the wrapper.

On Windows (Git Bash), call the wrapper through bash as shown instead of an .exe shim. Git spawning a shim from its own sh can die with a cygheap read copy failed fork error.

Your AI agents page you too often? Give them an oncall agent

When you run a fleet of coding agents, most of their "I'm stuck, human please" pages are not really for you. A runner is wedged, a lock is stale, a relay died, or the question is one you already answered in a runbook or on an old PR. We built an oncall agent that reads every escalation first, acts as you, and only pages you with what truly needs you. The whole thing is small, and it runs on stock my-ai-team (mat) features. It took two days to go from idea to running system.

The flow:

agent ── notify-user --action ──► Telegram (you, unchanged)
   └── ssh oncall-host oncall-inbox        (same message on stdin)
             │
        oncall agent: triage (env / decision / noise), investigate over ssh
             ├── ssh <agent-host> send-relay %<pane> reply.md   → answer the stuck agent
             ├── incident record, committed to a repo
             ├── notify-user                                    → FYI to you
             └── notify-user --action + a GitHub issue          → only when you must decide

1. Forward action messages. On every agent host, point mat at the oncall host (any ssh alias that logs in without a prompt):

git config --global mat.devopsHost oncall-host
…more

git can't pull private GitHub repos? gh was holding the token all along

You're logged into gh and can browse every private repo with it, but plain git pull over HTTPS still fails with fatal: could not read Username for 'https://github.com'. git doesn't know how to read gh's token store — nobody introduced them. (A GH_TOKEN env var makes every gh command work and can hide exactly this breakage, because plain git ignores it.)

You don't need Microsoft's Git Credential Manager (it drags in a .NET runtime). gh ships its own credential helper; one command wires it in:

gh auth setup-git

That adds a single stanza to your ~/.gitconfig:

[credential "https://github.com"]
    helper = !/usr/local/bin/gh auth git-credential

From then on, any HTTPS clone/pull/push of private repos authenticates through gh's stored token — global config, so it works for every repo on the machine. No SSH keys, no per-remote remote-url surgery, no token pasting.

Verify without letting an env token mask the result:

env -u GH_TOKEN git ls-remote https://github.com/<you>/<private-repo> HEAD

If that prints a ref, you're done.