-
Notifications
You must be signed in to change notification settings - Fork 14
by the numbers
Data collected on 2026-06-15.
These figures come from the git history and working tree of the DroidProxy repository. Where a number is a lower bound or skewed by automation, that is called out inline.
The app is a single Swift package under src/, with a small React/TypeScript marketing site under website/. The Swift sources are the bulk of the code.
- Swift source: ~5,051 lines across 15 files in
src/Sources. - Website TypeScript: ~747 lines (
.ts/.tsx, excludingnode_modules).
xychart-beta horizontal
title "Lines of code by language"
x-axis ["Swift (src/Sources)", "TypeScript (website)"]
y-axis "Lines" 0 --> 5500
bar [5051, 747]
| Category | Count | Notes |
|---|---|---|
| Swift source files | 15 | src/Sources/**/*.swift |
| Swift test files | 4 |
ClaudeThinkingBlockSanitizerTests, ThinkingProxySonnetMaxThinkingTests, DroidProxyModelCatalogTests, OAuthUsageTrackerTests
|
| Bundled YAML config | 1 | src/Sources/Resources/config.yaml |
| Swift packages | 1 | src/Package.swift |
The test surface grew from a single sanitizer suite to four files (~362 lines total), now also covering the Sonnet 4.6 max-thinking transform, the model-catalog reasoning metadata, and Claude usage-window parsing.
The repository started on 2025-10-04 and has ~792 commits as of this snapshot, with ~208 in the last 90 days. Commit volume by month:
xychart-beta
title "Commits per month"
x-axis ["2025-10", "2025-11", "2025-12", "2026-01", "2026-02", "2026-03", "2026-04", "2026-05", "2026-06"]
y-axis "Commits" 0 --> 180
bar [99, 49, 168, 116, 91, 76, 81, 85, 27]
The 2025-12 spike lines up with the switch to the CLIProxyAPIPlus backend and the surrounding release churn. (That fork was later replaced by mainline CLIProxyAPI on 2026-05-30 — see Lore.) The 2026-06 bar is a partial month.
From git log --since="90 days ago" --pretty=format: --name-only -- src | sort | uniq -c | sort -rn:
| Changes | File |
|---|---|
| 44 | src/Sources/SettingsView.swift |
| 36 | src/Sources/ThinkingProxy.swift |
| 23 | src/Sources/AppPreferences.swift |
| 16 | src/Sources/DroidProxyModelCatalog.swift |
| 13 | src/Sources/ServerManager.swift |
| 13 | src/Sources/AppDelegate.swift |
| 9 | src/Sources/AuthStatus.swift |
The two highest-churn source files (SettingsView.swift and ThinkingProxy.swift) are also the two largest, which is consistent with them carrying most of the feature work. AppPreferences.swift and DroidProxyModelCatalog.swift rank high relative to their size because the model catalog and fast-mode toggles are edited each time the exposed model set changes.
A large share of commits come from automation rather than people:
-
github-actions[bot]: 292 commits (release automation and appcast updates). -
dependabot[bot]: 4 commits.
That is ~296 of ~792 commits, roughly 37% of all history. The release bot dominates because the auto-release / appcast workflow commits a version bump and an appcast.xml update on each release. Treat any human-vs-bot split here as a lower bound for human authorship: bot attribution is only as accurate as the commit author field, and squashed or co-authored work can hide additional automation or human edits.
The codebase concentrates complexity in a few large files.
| Lines | File |
|---|---|
| 1249 | src/Sources/SettingsView.swift |
| 1207 | src/Sources/ThinkingProxy.swift |
| 498 | src/Sources/ServerManager.swift |
| 493 | src/Sources/OAuthUsageTracker.swift |
| 447 | src/Sources/ClaudeThinkingBlockSanitizer.swift |
| 424 | src/Sources/AppDelegate.swift |
| 302 | src/Sources/DroidProxyModelCatalog.swift |
| 190 | src/Sources/AuthStatus.swift |
SettingsView.swift and ThinkingProxy.swift together account for nearly half of the Swift source. Both are also the highest-churn files, which makes them the most natural refactor candidates: the proxy mixes request parsing, routing, JSON scanning, and multiple upstream integrations in one type, and the settings view holds most of the UI surface in one file.
There are 0 TODO / FIXME comments across src/Sources, so there is no in-code backlog marker to mine; refactor priorities have to be inferred from size and churn instead.