DEV Community: Tuğkan

Track Multiple Claude Code Accounts from One Menu Bar with ClaudeHub

Tuğkan — Mon, 21 Sep 2026 16:00:10 +0000

If you use multiple Claude Code subscriptions, you have probably asked this question:

Which account still has usage available?

I use multiple Claude Code accounts, each with its own five-hour and weekly usage limits. I wanted a simple way to check all of them without repeatedly switching accounts.

That is why I built ClaudeHub.

ClaudeHub is a free and open-source macOS menu bar app that displays usage information for multiple Claude Code subscription profiles in one place.

GitHub: github.com/tugkanboz/claude-hub
Download: ClaudeHub Releases

What does ClaudeHub show?

For each configured account, ClaudeHub can display:

Five-hour usage
Seven-day usage
Model-specific limits
Time remaining until each limit resets
Extra usage information when available
Last update time

Only the ClaudeHub icon appears in the menu bar. Clicking it opens a list of your accounts and their latest usage information.

Usage is refreshed automatically every five minutes. You can also update it manually using Refresh Now.

Keeping each account separate

Claude Code supports custom profile directories through the CLAUDE_CONFIG_DIR environment variable.

This makes it possible to keep each account in a separate directory:

CLAUDE_CONFIG_DIR="$HOME/.claude-accounts/account1" claude auth login
CLAUDE_CONFIG_DIR="$HOME/.claude-accounts/account2" claude auth login
CLAUDE_CONFIG_DIR="$HOME/.claude-accounts/account3" claude auth login

Each command creates an isolated Claude Code profile and starts the browser login flow for that account.

Your normal Claude Code configuration remains unchanged:

~/.claude

The additional accounts are stored separately:

~/.claude-accounts/account1
~/.claude-accounts/account2
~/.claude-accounts/account3

Installation

Download the latest version from the releases page:

Download ClaudeHub

Then follow these steps:

Open the downloaded .dmg file.
Drag ClaudeHub into the Applications folder.
Create an isolated Claude Code profile for each account from Terminal.
Open ClaudeHub.
Select Accounts > Add Existing Claude Profile...
Choose one of the profile directories you created.
Enter the label you want to see in the menu.
Repeat the process for the remaining accounts.

ClaudeHub will then display all configured accounts in the same menu.

Keychain access

Claude Code stores authentication credentials in macOS Keychain.

When ClaudeHub accesses a profile for the first time, macOS may ask for your Mac password. Choose Always Allow if you do not want to approve the same access every time ClaudeHub starts.

Choosing Allow may grant access only for the current run. In that case, the password prompt can return when you reopen the app.

ClaudeHub does not write tokens to its configuration files or logs. Credentials are held in memory only while the app is running.

What happens when a token expires?

When a normal access token is about to expire, ClaudeHub uses the installed Claude Code CLI to renew the session.

This happens automatically:

It does not open a browser.
It does not invoke a Claude model.
It does not consume subscription usage.
It normally does not require another login.

A manual login is only required if the account was logged out, the refresh token was revoked or the session became invalid.

Run the login command again using the same profile directory:

CLAUDE_CONFIG_DIR="$HOME/.claude-accounts/account2" claude auth login

After completing the login, quit and reopen ClaudeHub. You do not need to remove the profile from ClaudeHub or add it again.

What happens after restarting the Mac?

Your profiles and authentication sessions are not removed when the computer restarts.

ClaudeHub stores the account labels and profile directory paths locally. Claude Code keeps the authentication credentials in macOS Keychain.

After restarting the Mac, you only need to open ClaudeHub again. A new browser login is not normally required.

If you want ClaudeHub to launch automatically, add it under:

System Settings > General > Login Items

Technical overview

ClaudeHub is a native macOS application built with:

Swift
AppKit
Swift Package Manager
macOS Security Framework
URLSession
GitHub Actions

The app currently supports Apple Silicon Macs running macOS 13 or newer.

Language support

ClaudeHub follows the macOS system language.

It currently includes:

English
Turkish
French
Spanish

If the current system language is not supported, ClaudeHub falls back to English.

The product name remains ClaudeHub in every language.

Privacy

ClaudeHub is designed to store as little information as possible.

It never modifies your normal ~/.claude configuration.
It does not write tokens to configuration files.
It does not include tokens in logs.
It does not collect telemetry.
It does not contain advertising or analytics SDKs.
It stores only the account label and profile directory path locally.
Usage requests are sent directly to Anthropic.

The project is open source, so its behavior can be reviewed directly in the source code.

Open source

You can inspect the source code, open an issue or contribute to the project:

github.com/tugkanboz/claude-hub

Let your AI agent test your API: two-go's AI layer and MCP server

Tuğkan — Tue, 02 Jun 2026 18:51:45 +0000

There's a moment in every project where you have a working endpoint, you know
you should write tests for it, and you also know you're about to spend the next
hour wiring up an HTTP client, an assertion library, and a dozen little helpers
before you write a single meaningful check.

I got tired of that moment. So I built two-go:
a small, zero-dependency library for testing HTTP APIs from Node. You build a
request with a chainable API, attach the checks you care about, and await it.

import { go } from "two-go";

await go("https://api.example.com")
  .get("/users")
  .bearer(token)
  .expectStatus(200)
  .expectHeader("content-type", /json/)
  .expectJson("data[0].id", 1);

That one chain sends the request and runs all three checks. If any of them
fails, it throws, so there's no special runner to configure. It works on its
own, and it drops straight into node:test, Jest, Vitest, or Mocha with no
plugin.

That's the core. But the part I actually want to talk about in this post is the
part that didn't exist in API testing libraries when I started: letting an AI
agent do the testing work for you. two-go ships two things for that: an
optional AI layer, and an MCP server.

Why bother with an AI layer at all?

Most of the friction in API testing isn't writing assertions. It's the staring
at a response and deciding what to assert. What status should this return?
What's the shape of data[0]? Which fields could leak? Which weird payloads
break it?

Those are exactly the questions a language model is good at taking a first pass
at. So two-go has an optional two-go/ai entry point that can:

draft a test suite from a live endpoint or a sample response,
explain why a test failed,
review a response for likely bugs,
and generate adversarial payloads to fuzz an endpoint.

The important design choice: the AI layer never touches the core. two-go still has zero runtime dependencies. The AI module talks to the provider over fetch with your own key, and it works with OpenAI, Anthropic, or any compatible endpoint, including a local model.

Drafting a suite from a real endpoint

export OPENAI_API_KEY=sk-...
two-go ai gen https://api.example.com/users -o test/users.twogo.mjs

# or from a saved response, with a different provider two-go ai gen ./sample.json --provider anthropic -o test/users.twogo.mjs

Or from code:

import { aiGenerateTests } from "two-go/ai";

const code = await aiGenerateTests({
  endpoint: "/users",
  baseUrl: "https://api.example.com",
  sample: { data: [{ id: 1, name: "Ada" }] },
  provider: "openai", // or "anthropic", or a custom { baseURL } for a local model
});

The output is a normal *.twogo.mjs file. It goes into git and runs in CI like anything else. Treat it as a first draft. It gets the boilerplate and the obvious checks out of the way, and you tighten the assertions from there.

Explaining a failure (after the fact, never changing the result)

When a test fails, you can ask the model what probably went wrong. This is advisory: it runs after the failure and never changes pass or fail.

import { explainFailure } from "two-go/ai";

try {
  await api.get("/users").expectStatus(200);
} catch (err) {
  const why = await explainFailure(err, {
    response: err.response,
    provider: "openai",
  });
  console.log(why); // likely cause plus a suggested fix
}

Reviewing and fuzzing

aiReview looks at a response and hands back a list of likely problems: a leaked token, a wrong type, a field that shouldn't be there. aiFuzz generates adversarial payloads you then send with the normal client.

import { aiReview, aiFuzz } from "two-go/ai";

const res = await api.get("/me");
const findings = await aiReview(res, { provider: "openai" });
// [{ severity, field, message }]

const payloads = await aiFuzz({
  endpoint: "/users",
  method: "POST",
  schema: { type: "object", properties: { name: { type: "string" } } },
});
for (const body of payloads) {
  const r = await api.post("/users").json(body);
  if (r.status >= 500) console.log("possible bug on payload", body, "->", r.status);
}

Both are advisory. aiReview gives you findings, aiFuzz gives you inputs, and you decide what to do with them. The model proposes; your assertions dispose.

The MCP server: hand the tools to the agent

The AI layer above is two-go calling out to a model. The MCP server flips the direction: it lets an agent like Claude drive two-go directly, as a set of tools.

If you haven't run into it yet, MCP (Model Context Protocol) is an open standard for exposing tools to AI agents. two-go ships an MCP server
that runs over stdio with no dependencies, no URL, no account, and no API key. It's all local.

Install once so the two-go-mcp command is on your PATH:

npm install -g two-go

Then wire it into your client. For Claude Code:

claude mcp add two-go two-go-mcp

For Claude Desktop, Cursor, Windsurf, Copilot CLI, or Kiro,
drop this into the client's MCP config:

{
  "mcpServers": {
    "two-go": { "command": "two-go-mcp" }
  }
}

(VS Code uses a top-level servers key and a "type": "stdio" field; Codex and Gemini have their own mcp add commands. The README has a copy-paste block for each.)

The tools it exposes to the agent:

http_request: send a request, get back status, headers, timing, and body.
gen_openapi / gen_postman: generate a suite from a spec or collection.
infer_schema: infer a JSON schema from a value.
validate_schema: validate a value against a schema.

Once it's connected, you can just talk to your agent: "call the staging users endpoint and tell me if the shape changed," or "generate a test suite from this OpenAPI file." The agent makes the calls through two-go and reasons over the real responses.

And because the server logic is importable, you can host it yourself:

import { createServer } from "two-go/mcp";

const server = createServer();
const response = await server.handle({
  jsonrpc: "2.0",
  id: 1,
  method: "tools/list",
});

The rest of the box (so the AI output has somewhere to land)

The AI features are only useful because the generated tests run against a real library. The non-AI core is the bulk of two-go:

HTTP client + inline checks: expectStatus, expectJson, expectHeader, expectJsonSchema, expectSorted, and a long list of others.
expect() for any value: Jest-style matchers, with .not, .resolves, and .rejects.
Soft assertions: collect every failure in a run, throw once at the end.
Polling: eventually / pollUntil for slow or eventually-consistent endpoints.
Snapshots, sessions with {{token}} chaining, a fake-data generator, async helpers (parallelLimit, mapLimit, waterfall), a ~170-function utility belt, and a JSON schema validator + inference.
Importers that turn an OpenAPI doc or Postman collection into a starting suite, with a CLI: two-go gen openapi ./openapi.json -o test/api.twogo.mjs.

All of it ships with hand-written TypeScript types and zero runtime dependencies. Node 18+ (it uses the built-in fetch), ESM only.

A realistic flow, end to end

Here's how the pieces fit together in practice:

You have an endpoint and an OpenAPI doc. Run two-go gen openapi to get a skeleton suite.
Ask your agent (via the MCP server) to call the live endpoint and flag any drift from the doc.
Run aiReview on a sample response to surface leaks and type mismatches.
Tighten the generated checks into real assertions by hand.
Commit the *.twogo.mjs files. They run in CI like any other test.

The AI does the tedious first pass: boilerplate, obvious checks, "here's what looks off." You keep the judgment calls. Nothing about the AI layer is load bearing. Pull the key and the core still works exactly the same.

Try it

npm install two-go --save-dev

npm: https://www.npmjs.com/package/two-go
GitHub: https://github.com/tugkanboz/two-go

The roadmap (JUnit/JSON reporters, a GraphQL helper, a cookie jar, request-level retry) is open in the issues. If you build something with it, or break it, I'd love to hear about it.

I started awesome-ai-testing because I couldn't find a clean map of AI testing tools

Tuğkan — Tue, 05 May 2026 13:00:00 +0000

The AI testing space moves fast. Test generators, self-healing frameworks, MCP servers, LLM evaluators, visual AI platforms, new tools every month. Most of them claim to "use AI" without saying what that actually means.

Existing awesome lists either don't cover AI testing or mix it into broader test automation directories. The result: hard to compare options, hard to find open source alternatives, hard to see what's mature versus experimental.

awesome-ai-testing is a new curated list focused on this gap. It currently has around 100 tools across 20 categories, with each entry tagged as open source, commercial, or open core. I'm sharing it early, not polished, to get feedback from people who actually run tests for a living.

What's in it

Categories are organized by what people actually search for, not academic taxonomies:

Test Generation: Qodo-Cover, EvoMaster, EvoSuite, Diffblue, plus AI editors like Cursor and Claude Code that can write Playwright, Cypress, and Selenium tests with the right prompting.
MCP-Based Testing: Playwright MCP, Chrome DevTools MCP, and community variants. This is the area moving fastest right now.
Self-Healing Test Frameworks: Healenium for open source, Testim and Functionize on the commercial side.
Natural Language Test Authoring: Magnitude, Passmark, Shortest, Auto Playwright, Midscene.js, all open source.
LLM-as-Judge Evaluation: Promptfoo, DeepEval, Ragas, Inspect AI, TruLens, Arize Phoenix.
Mock and Service Virtualization: Mountebank, WireMock, Mockoon, MSW, Pact, Hoverfly. Useful when mocking LLM APIs in tests.
Visual AI, Mobile AI, Performance, Accessibility, API testing: Each with its own section.

Each entry has a badge:

🆓 Open source
💰 Commercial
🆓💰 Open core (free tier or open source with paid features)

Open source options are listed first in each category. The commercial space is well-promoted already; open source needs visibility.

What's excluded

To keep the list useful:

Tools abandoned for 2+ years
Marketing pages without a real product
Generic test runners with weak AI claims (no Selenium with bolted-on plugins)
Closed source tools without a free trial or transparent pricing

Honest disclaimers

The list is new. A few caveats:

Some categories are denser than others. AI Code Review didn't make the cut yet because it doesn't clearly belong in a testing-focused list.
This is a curated list, not a benchmark. Tools are included based on quality signals (active maintenance, real users, transparent pricing), not personal testing of every entry.
Categorization will shift as the list grows. Promptfoo sits in two categories because it genuinely does both.

Three workflows the list supports

"I need to test my AI app" → LLM and AI System Testing + Mock and Service Virtualization
"I want AI to write my tests" → Test Generation + MCP-Based Testing + Natural Language Test Authoring
"My existing test suite is brittle" → Self-Healing Test Frameworks + Test Analytics and Triage

What would help right now

If you maintain or use an AI testing tool that's missing, open a PR. The contribution guide is two screens long.

If you spot something miscategorized or inaccurate, open an issue.

If you tried a tool from the list and it was great or terrible, drop it in the comments here. That kind of signal is exactly what turns a list into a useful list.

Repo: https://github.com/tugkanboz/awesome-ai-testing