Scale Limits and Research Frontier

What Aura has shipped, what is in active development, and what is honest open research.

"I don't want the marketing version. I want the limits. Where does this break?"

The Concern

Any system that does live synchronization, cross-peer coordination, and semantic analysis has limits. Some are soft (works but degrades), some are hard (explicitly does not support), and some are research problems that nobody has a good answer to. An honest vendor names all three.

This page is the list.

How Aura Handles It

We organize the limits into three tiers:

Shipped. In production, tested internally and externally, documented behavior.
Active development. Being built, partial functionality available, edges rough.
Research. Known-hard problems. We have prototypes or papers. No shipping date.

Tier 1: Shipped

Peer count on one Mothership. Internal testing validates Aura comfortably on teams up to ~500 concurrent peers against a single Mothership running on a modest VPS (4 vCPU, 8GB RAM). Above that, we recommend either splitting into multiple Motherships (one per team) or upgrading the Mothership host. There is no hard cap in the protocol; the practical ceiling is driven by event log throughput and memory for active session tracking.

Repository size. Aura has been tested on codebases up to roughly 500K LOC without issues. Initial parse for a repo of that size takes 2–6 hours (parallelizable; faster on beefier hardware). Incremental updates after the initial parse are fast — function-level updates complete in milliseconds.

Supported languages (full semantic features). Rust, TypeScript, JavaScript, Python, Go, Java, C, C#, Ruby, PHP. Cross-language AST has the details.

Function-level live sync. Five-second debounce, AST-aware, atomic updates. See code is not Figma.

AST-aware three-way merge for same-branch conflicts in supported languages. See AST merge.

Intent tracking with pre-commit hook enforcement. See intent tracking.

Zone claims for multi-agent coordination. See zone claim.

Impact alerts for cross-branch function modifications. See impact alerts.

Tier 2: Active Development

Federated Motherships. Connecting multiple Motherships so that peers on different Motherships can see each other's work. The protocol exists in prototype; we have not hardened it for production. Target: teams of 10K+ distributed across multiple offices or orgs. Status: early prototype, not recommended for production use. If you need this today, please open an issue so we can prioritize.

Large monorepo cold start. On a 1M+ file monorepo (think Meta-scale or Google-scale), initial parse takes longer than we are comfortable shipping as a single-machine operation. We are working on a distributed parse model where the initial semantic backfill is sharded across multiple workers. Incremental updates once the graph is warm are fast; cold start is the issue. Partial workaround today: run aura init --lazy to backfill on demand rather than all at once.

Swift and Kotlin. Full semantic features for mobile codebases. Tree-sitter grammars exist; we are still tuning the function identity and rename detection heuristics for these languages, particularly around Swift macros and Kotlin's extension-function model. Expect full support in a near-term release. Until then, they work at partial fidelity — core functions and classes are tracked, some advanced constructs fall back to text merge.

C++ heavy-template handling. Modern C++ with heavy template metaprogramming produces trees where the "function" unit is less stable than in other languages. Aura handles typical application C++ well. Template-heavy library code (Eigen-style, Boost-style) falls back to file-level tracking. We are evaluating whether a custom grammar or language-server integration improves the situation.

Incremental aura prove for very large goal sets. Running aura prove against hundreds of goals in CI currently re-evaluates each independently. We have a caching design that reuses graph traversals across goals; it is implemented partially. This is a performance problem, not a correctness one.

Rich conflict picker UI beyond the CLI. Today the interactive conflict picker is CLI-based with a VS Code extension that mirrors it. A richer standalone UI (for teams whose merge workflow is not CLI-driven) is in development. Functional equivalent exists; visual polish lags.

Binary file semantic tracking. Aura handles text files well. Binary files (images, compiled artifacts, large data files) are passed through to Git without semantic analysis. We have done some exploration on structured binary formats (protobuf, avro) but nothing is shipped. Git LFS remains the recommended path for large binaries.

Tier 3: Research

These are problems we consider genuinely open. We have prototypes, we read papers, we occasionally ship experimental flags. We do not claim to have solved them.

Semantic merge of macro-heavy code. In Rust, macros can expand to arbitrary token streams. Two peers editing different macros that both affect the same generated code path produce a merge that is textually clean but semantically ambiguous. The same problem exists in Lisp, Scheme, Racket, Nim, and any language with powerful macros. Aura currently falls back to text merge and flags that macros were involved. A principled solution likely requires running macro expansion during merge, which is expensive and introduces a dependency on the language toolchain at merge time. Research.

Semantic merge across language boundaries. FFI calls, language-interop code (Python calling C extensions, JVM polyglot code, WASM), and generated bindings are not analyzed across the boundary. Aura treats each side independently. A semantically-aware cross-boundary merge would require modeling ABI, which is a deep rabbit hole. Research.

Conflict-free AST CRDTs. As discussed in CRDT vs AST merge, AST-level CRDTs exist in research but do not handle tree restructuring well. We read the papers. Nothing production-grade has emerged in the space. If this problem gets solved, the tradeoff between AST merge and CRDT gets interesting again. Today, research.

AI-assisted automatic merge with verifiable correctness. LLMs can often produce plausible merges for same-function conflicts. They also produce subtly wrong merges often enough that shipping this as an auto-merge would be irresponsible. We have prototypes that use an LLM to propose a merge plus a verifier (tests, type checks, structural invariants) to validate the proposal. The verifier side is the hard part: you need a verifier strong enough to reject bad merges and weak enough to accept good ones. This is a variant of program synthesis, and the literature is honest that it is unsolved at scale. Research.

10K+ concurrent peers on a single logical Mothership. Our current Mothership architecture is a single-writer event log with fan-out to peers. At very high peer counts, fan-out becomes the bottleneck. The federated-mothership path above is one answer; a gossip protocol between peers is another. We have not committed to an architecture. Research.

Truly distributed standalone mode without a Mothership. Right now, Aura's P2P story requires a coordination point (the Mothership). A fully peer-to-peer mode with no central node would need gossip, consensus for conflict ordering, and offline reconciliation. Research projects exist in this area (think of radicle, secure-scuttlebutt-style systems for code). We have not built this. Research.

Semantic rewind across massive refactors. aura rewind works well at the function level. If a large refactor moved and renamed hundreds of functions, rewinding to a pre-refactor state by function identity is ambiguous — which function does the old name map to? Aura makes a best effort and surfaces ambiguity. A fully automatic solution is open.

Formal verification integration. Integrating tools like Coq, Lean, or F* into Aura's semantic graph — so that aura prove could check formal proofs, not just structural connections — is something we have discussed. It is hard and not on any near-term roadmap. Research.

The Frontier, In Numbers

Some rough guidance, with the caveat that these are not benchmarks and we will not publish comparative TPS or user-count claims:

| Dimension | Comfortable | Rough edges | Research | |---|---|---|---| | Peers per Mothership | up to ~500 | 500–2000 | 2000+ | | Repo size (LOC) | up to ~500K | 500K–2M | 2M+ | | Files per repo | up to ~100K | 100K–500K | 500K+ | | Languages per repo | 1–3 | 4–10 | 10+ | | Concurrent conflicts per function per hour | 1–3 | 4–10 | 10+ | | Intent log entries per day | up to 10K | 10K–100K | 100K+ |

"Comfortable" means well-tested in internal and early-external workloads. "Rough edges" means works but you will notice slowness or occasional bugs. "Research" means we have not validated it and cannot make claims.

What This Page Will Not Tell You

We do not publish hand-picked benchmark numbers to make Aura look fast. We do not compare TPS against specific competitors. We do not claim specific latency figures because latency depends on network, CPU, repo size, and workload in ways that make any single number misleading.

If you need specific performance data for your workload, run Aura on your workload. aura doctor --bench produces a diagnostic report. We are happy to help interpret results via GitHub issues or the community Discord.

What Aura Does Not Solve

The entire "research" tier is what Aura does not solve. The entire "active development" tier is what Aura does not solve today. We want to be loud about both.

The Honest Tradeoff

Being public about research-tier problems is a trust-building choice that costs us some marketing flexibility. A competitor could cite our own page to argue Aura is not ready. That is a reasonable argument in domains where the research-tier limits matter (very large teams, federated orgs, macro-heavy codebases).

In domains where those limits do not bite — which is most teams — the shipped tier is enough to provide real value. We would rather be honest about where we are than invite bake-offs we are not ready for.

If you have a workload that lives in the rough-edges or research tier, please talk to us before adopting. We would rather steer you away than disappoint you. If your workload is in the comfortable tier, Aura is ready.