Runtime Language Rationale

简体中文

Codex Quota Monitor is currently implemented as a Python application. That is an intentional tradeoff, not an assumption that Python is the most efficient runtime for every deployment.

Current Decision

Keep the service in Python for now. Do not rewrite it in Go or Rust only to reduce theoretical runtime overhead.

The monitor is a small self-hosted operations service. Its regular work is low-frequency quota sampling, HTTP dashboard/API responses, JSON parsing, SQLite-backed history, static asset serving, and Prometheus metrics. That shape is mostly I/O-bound and low-concurrency for the expected personal or small-team deployments.

The browser UI also keeps presentation defaults separate from runtime state: the service may provide default locale, time zone, and CSS font-family stacks, while each browser can override those preferences locally. Locale controls UI messages plus browser-side date/number formatting, timezone controls reset-time display, and font settings remain plain CSS font-family stacks. The dashboard ships en and zh-CN messages now, while API payloads stay structured and language-neutral. This keeps future localization work from being tied to one operator’s fonts, locale, or deployment timezone.

Why Python Is Acceptable Here

• The runtime dependency set is intentionally small. Check pyproject.toml before assuming a web framework or large third-party dependency stack exists.
• Python keeps the project easy to inspect, package, and patch for operators who are already using the tool as local infrastructure.
• The current service is long-running. Python cold-start cost matters less than it would for a frequently spawned CLI helper.
• The main correctness risk is quota/account-state interpretation, not raw throughput. Preserving tests and behavior is more valuable than changing runtimes for a small fixed overhead.

What Go Or Rust Would Improve

Go or Rust would likely be more efficient in several areas:

• lower resident memory for the same service shape
• faster cold starts
• smaller release artifacts and smaller Nix/Docker runtime closures
• stronger performance under high request concurrency

Those benefits are real, but they do not currently dominate the project cost. A rewrite would need to port the snapshot model, dashboard API, direct quota sampling, SQLite history, benchmark import, Prometheus metrics, packaging, and tests without changing user-visible behavior.

When To Revisit

Reopen the runtime choice if one or more of these become true:

• the monitor needs to run on memory-constrained devices or very small VPSes
• release images or Nix closures need to be minimized as a product goal
• measured RSS or CPU use becomes a real host-level problem
• account count, browser concurrency, or refresh frequency grows well beyond the current self-hosted operator use case
• frequent cold starts become part of the normal workflow
• Python dependency growth or code organization starts making maintenance harder than a compiled implementation would be

If a rewrite becomes justified, Go is the default language to evaluate first. The project mostly needs HTTP, JSON, time handling, static asset embedding, SQLite, and metrics, which Go covers well with a small operational footprint. Rust should be considered when the project has stronger needs for complex state modeling, strict correctness boundaries, or a Rust-specific maintenance goal.

How To Measure

Prefer measurements over language assumptions:

nix build .#codex-quota-monitor --no-link --print-out-paths
nix path-info -S .#codex-quota-monitor
systemctl show codex-quota-monitor.service -p MemoryCurrent -p CPUUsageNSec

For local foreground testing, compare RSS and startup time with the same configuration, account count, refresh interval, and browser load. Treat runtime language as one input to an operations decision, not as an automatic rewrite trigger.