Performance

Your agent spends less time waiting

Measured from Gothenburg, Sweden. August 2026. Source code and raw data.

We gave Claude Code the same bug on identical repos, one on Codebahn and one on GitHub. Same model, same prompt, same machine. Then we parsed the transcripts to separate model thinking time from platform wait time.

The full session

Fix a validation bug: read the issue, find the code, write the fix, run tests, open a PR. Four integration paths, two platforms.

3% vs 33%. On GitHub via MCP, a third of the session is platform wait.

Four tasks, consistent gap

We ran four different tasks via MCP to see whether the gap held across workloads: two bug fixes, a code review, and a codebase exploration. Platform wait time only (model thinking excluded).

Read-heavy tasks show the biggest gap. The explore task: 19 calls on Codebahn in 1.3 seconds. 22 calls on GitHub in 65.8 seconds. Code review: 8 calls in 0.7 seconds vs 12 calls in 17.4 seconds.

What each call costs

Per-call latency across all MCP sessions. These are not averages of averages; every individual tool call is counted.

Codebahn's slowest call (578ms) is faster than GitHub's fastest (1,112ms). Reads are where the gap is widest: 66ms vs 2,565ms. Since most agent work is reading (fetch issue, read file, list branches), this is where the difference compounds.

GitHub gets slower mid-session

Within a single GitHub MCP session, call latency increases over time. The explore task shows it most clearly: the first call takes 1,116ms, the last takes 7,130ms. The fix-email session follows the same pattern, with calls 12 and 13 hitting 7,744ms and 8,070ms.

Codebahn shows no escalation. The 19th call in the explore task (41ms) is comparable to the first (66ms).

The escalation likely originates in the GitHub MCP server's session handling, not in GitHub's API itself. It resets between sessions, so it affects longer agent tasks more than short ones.

GitHub agents do more work

Across all four MCP tasks, the GitHub agent made 69 calls vs Codebahn's 53. The extra calls fall into three categories:

• Discovery. get_my_user_info and search_repos appear in every GitHub session but never in Codebahn sessions. The GitHub MCP server requires these preamble calls before the agent can work on a repo.
• Retries. list_repo_issues is called two to three times in some GitHub sessions (once on Codebahn). The first call did not return what the agent needed.
• Verification reads. The GitHub agent reads files back after writing more often, suggesting lower confidence in write success.

CLI comparison (cleanest apples-to-apples)

The MCP comparison has an architecture difference: hosted endpoint (Codebahn) vs local binary calling a remote API (GitHub). The CLI comparison removes that variable. Both sides use a local binary, SSH for git, HTTPS for the platform API. Same task, same machine.

3.3x. This is the number that survives the most scrutiny. Same integration pattern, same protocols, one variable: the platform.

What this means for a team

A developer running 10 agent tasks a day via CLI accumulates roughly 3.5 minutes of platform wait on GitHub (205 seconds) vs 1 minute on Codebahn (62 seconds). The difference is about 2.5 minutes per developer per day.

Via MCP, the gap is larger: roughly 5 minutes per developer per day, because the per-call difference is wider and GitHub's escalation makes longer sessions progressively slower.

A five-person team over a month: 50 to 100 minutes of cumulative platform wait that does not exist on Codebahn.

Why it's faster

Three factors compound:

• Geography. Codebahn runs in Paris (EU). GitHub's API serves from the US. For an EU developer, every round trip saves about 200ms. This is the 2.8x measured by the raw API benchmark: 116ms median vs 324ms, across 350 calls and 7 endpoints.
• MCP architecture. Codebahn's MCP endpoint runs on the same infrastructure as the platform. A tool call goes directly to the API. GitHub's MCP path is longer: Claude Code starts a local Go binary, which makes HTTPS calls to the API, serializes responses, and pipes them back through stdio.
• Server behavior. The GitHub MCP server adds discovery calls before productive work and suffers from latency escalation within a session. Codebahn's MCP server does neither.

How we measured it

• Single machine in Gothenburg, Sweden. Both platforms tested simultaneously per iteration.
• Identical private repositories on both platforms: same files, same issues, same comments. Small TypeScript project (8 files) with two seeded bugs.
• Agent: Claude Code (claude-opus-4-6). Same model, same open-ended prompt ("find the email validation bug, fix it, open a PR"). Platform wait time extracted by pairing tool call and result timestamps in the transcript.
• API benchmark: 7 matched REST endpoints, 50 iterations each (350 total). DNS and TLS warmed before timing.

The public benchmark repo has the seed repository, measurement scripts, raw data, and the full report with per-call distributions and detailed analysis.

Caveats

• EU-specific. Codebahn is in Paris, the test machine is in Sweden. A developer in the US would see a smaller gap. The claim is "faster from the EU," not "faster everywhere."
• Single runs for agent tasks. The API benchmark (350 calls) is statistically robust. The agent workflows ran once per platform per task. Model behavior varies between runs.
• MCP architectures differ. Codebahn uses a hosted endpoint. GitHub uses a local binary calling a remote API. The CLI comparison (3.3x) is the cleaner apples-to-apples number.
• GitHub's MCP server may improve. The latency escalation and extra discovery calls may be fixed in future versions. The raw API comparison is unaffected.

GitHub is a trademark of GitHub, Inc. This is an independent comparison, not affiliated with or endorsed by Microsoft or GitHub.