What I learned:

The one real 30-day movement is a distillation that dropped the local ceiling from an enterprise GPU to a mid-range card - r/StableDiffusion posted SeedVR2-1.4B on 29 July, a six-layer distillation of ByteDance's 7B sharp model. The model card on Hugging Face is where the number lives: 6 transformer blocks against the stock architecture's 36, 5.7x smaller on disk, and roughly 4.6 GB of VRAM where the teacher wants 14 to 16 GB. That is the difference between a card you own and a card you rent. It ships as a drop-in custom_nodes folder for ComfyUI, which tells you who it is for. The parent ByteDance-Seed/SeedVR repo sits at 1.3K stars with 48 open issues, so this is a research drop being maintained as a product, not a finished tool.

The quality argument against paid software is effectively settled, and it was never the argument that mattered - blind tests on real 480p, 720p and 1080p footage put SeedVR2 7B Sharp FP16 at 9.7 out of 10 against Topaz at 9.8, a gap WaveSpeed calls imperceptible to most viewers. The honest reading of that result is not that the free one won. It is that quality stopped being the axis. Topaz is a desktop app where you drop in a video and pick a preset; SeedVR2 is ComfyUI plus weight management plus VRAM troubleshooting plus a temporal setting you have to think about. educba puts the same split cleanly: commercial apps treat the model as a black box, open-source repos hand you full control and a Python environment to maintain. What you are choosing between is a preset and a graph, and the comfy.org video upscale workflow shows what the graph actually costs - split to frames, run SeedVR2 per frame, reassemble at the original FPS from the source video info.

Where the output falls apart is not softness, it is invention, and the people who know this say it bluntly - the sharpest line in the corpus came from @MirH_x: "Anyone who doesn't understand AI upscaling should avoid upscaling for serious content. Most upscalers use diffusion based models...looks nice but adds it's own information." That is the entire caveat in one sentence. AI Pro Photography names the visible symptom: upscalers invent detail rather than preserve it, so smooth skin comes back with waxy pores, plastic sheen and smeared edges. Their fix is unglamorous and worth internalizing - upscale 2x rather than 4x or 6x, and pick a face-aware model instead of a general "max detail" one. The bigger the multiplier you ask for, the more of the output is the model's guess rather than your footage.

The failure that survives every VRAM improvement is temporal, because per-frame upscaling hallucinates independently on every frame - LTX frames temporal consistency as the hardest problem in AI video for a mechanical reason: a per-frame upscaler with no temporal model decides what high-frequency detail to add separately for each frame, so moving subjects shimmer, and the shimmer is frequently worse than the compression artifact it replaced. This is why the "just run Real-ESRGAN over every frame" workflow keeps disappointing people who tried it on real footage rather than a still. Digen cites a PCWorld measurement of a 57% drop in flickering artifacts when moving from frame-by-frame to a sequence-aware model, which is a large improvement and still not zero. Detail enrichment and temporal stability are in direct tension - one wants big pixel-level variation, the other wants it constrained.

The quiet counter-move in the corpus is to not use a generative model at all - the highest-ranked non-diffusion tool in the run is a 664-star Swift command-line upscaler running Apple's Metal scaler, and its whole proposition is that it does not invent anything. No diffusion, no hallucinated pores, no per-frame divergence, and no Python environment - just a deterministic upscale that also quietly handles the codec trap where anything above 4K has to leave H.264 and HEVC behind for ProRes because macOS cannot play back what it just made. It will never recover detail that is not in the source, which is precisely the point for anyone doing archival or client work. The same instinct shows up as Show HN: PixelUp, a 100% offline Windows upscaler, though at 6 points it landed with almost no discussion.

The constraint quietly pushing people local is not cost, it is footage they are not allowed to upload - Pexo makes the point in passing while ranking free tools: client work, internal company video and anything under NDA has to go through client-side or local processing, because a free cloud upscaler means trusting someone else's data handling with material you do not own. Almost every "best free upscaler" list in the window is ranking web uploaders. For a whole category of real work those are disqualified before quality is even discussed, and that is a better reason to learn the ComfyUI graph than any benchmark score.

KEY PATTERNS from the research: 1. The month's actual delta is a VRAM number, not a quality number - SeedVR2-1.4B runs in about 4.6 GB against the 7B teacher's 14 to 16 GB, per Hugging Face 2. Free open-source now scores within 0.1 of paid Topaz on blind tests of real footage, so the remaining gap is setup and motion handling rather than output quality, per WaveSpeed 3. Diffusion upscalers fail by adding information, not by staying soft, which is why they are a bad default for anything documentary or evidentiary, per @MirH_x 4. Temporal flicker is structural to per-frame processing and only shrinks - a measured 57% reduction with sequence-aware models, not elimination, per Digen 5. Lower multipliers and face-aware models are the cheapest quality win available, because 2x asks the model to guess far less than 6x, per AI Pro Photography 6. A non-generative Metal or GPU scaler is the correct tool whenever invented detail is a liability, and a 664-star Swift/Metal command-line upscaler is the working version of that argument

What I learned:

The bill for local-first is not merge logic, it is tombstones, and the numbers are much worse than the marketing suggests - a CRDT cannot forget. Deleting something records the deletion rather than removing the data, so every delete leaves a marker that has to be kept until you can prove every replica saw it. Metaduck puts the canonical horror story in numbers: Figma found documents carrying more than 10 million tombstones from deleted shapes at 32 bytes each, and the files became gigabytes. Zylos generalizes it - on top of roughly 2 MB of actual state you pay 16 to 32 bytes per character in tombstone and identity overhead plus vector clocks, which lands a two-million-character document somewhere between 34 and 66 MB. That is a 17x to 33x memory footprint against a plain representation of the same content, and Riak operators have reported metadata exceeding payload by an order of magnitude under high write rates with infrequent compaction.

The fix for that cost quietly gives back the property people adopted CRDTs for - you can garbage collect tombstones, but only once you know every replica has seen the deletion, and knowing that requires coordination. The headline claim of a CRDT is that it merges without coordination; the operational reality is that it merges without coordination and then needs coordination to stay small. In practice teams snapshot instead: create a new CRDT snapshot past a million tombstones and discard history older than a week. The reported savings are real - 60 to 80% storage reduction from merging Yjs updates into consolidated snapshots, around 70% overhead reduction from OR-Set tombstone compaction in high-churn workloads - but every one of those numbers is a background job you now own, and a history-retention policy you now have to defend to whoever wanted infinite undo.

The practitioner writeup of the month is unusually blunt about the engines, and the split is not about merge quality at all - johnny.sh walks the 2026 field and lands on Zero, with LiveStore judged architecturally excellent but ruled out because one user maps to one SQLite instance, which makes sharing data between users structurally awkward. It is best for apps shaped like Overtone: lots of data per user, very little shared. The verdict on ElectricSQL is the part that circulated, calling it something to avoid at all costs on the grounds that long polling is a slow and brittle push mechanism and that client-side writes are "choose your own adventure" - you build your own REST write path. Worth holding that against the repo's actual scale, 10K stars and 253 open issues, and against its README now describing itself as "the agent platform built on sync." The company that sold Postgres sync is currently selling to the agent market.

Every serious guide lists the same four hard parts, and none of them is the merge algorithm - conflicts, auth, storage, partial sync. RxDB and Turso both land there, with client-side migrations and permissions-at-the-sync-boundary as the two that surprise people. Partial sync is the one that gets underestimated: once the local store cannot hold everything, you are writing lazy bootstrap logic and managing multiple replication scopes per user, which is a real subsystem. And permissions get genuinely hard, because a client that holds the data locally has already been handed whatever you synced to it. The AppScale guide is unusual for shipping an explicit "when NOT to go local-first" section and seven named anti-patterns rather than a pitch.

The clean disqualifier is anything where the last one wins - strong eventual consistency means everyone converges, not that anyone was right. Inventory where several people buy the last item, exclusive resource allocation, financial transactions: a CRDT will happily merge two people taking the same unit into a state that is internally consistent and commercially wrong. The blunt version from the guides is that for a team that just needs a CRUD app, this complexity is a trap, and for the right kind of app with experienced people it pays back many times over. That is a narrower target than the volume of tooling in this space implies.

Meanwhile the phrase has quietly split in two, and the louder half has nothing to do with sync - almost everything on Hacker News this month carrying the local-first label was a desktop AI tool using it to mean "runs on your machine, no cloud": Compass as a local-first knowledge graph for codebases, a local-first router for agent skill libraries, a local-first browser agent pitched on 30ms latency and $0 LLM cost, a local-first interface to Slurm, a local-first cost intelligence tool. The only item in the window actually doing CRDT sync was Opbox, multiplayer sync for text files on disk, at 11 points. If you read "local-first" in a launch post now, it most likely means privacy and no network dependency, not offline convergence. That is worth knowing before you go looking for sync advice under the term.

KEY PATTERNS from the research: 1. The dominant hidden cost is tombstone accumulation, not merge complexity - 10M+ tombstones at 32 bytes turning Figma documents into gigabytes, per Metaduck 2. CRDT overhead runs 17x to 33x the underlying state once identity metadata and vector clocks are counted, per Zylos 3. Compaction reclaims 60 to 80% of that, but collecting tombstones safely needs to know all replicas saw the delete, which reintroduces the coordination CRDTs were adopted to avoid 4. Engine selection in practice turns on write path and data-sharing shape rather than merge semantics - LiveStore's one-user-one-SQLite model is the concrete example, per johnny.sh 5. The four hard parts every production guide names are conflicts, auth, storage and partial sync, with client-side migrations as the sleeper, per Turso 6. "Local-first" has bifurcated - on Hacker News it now overwhelmingly means a local AI tool with no cloud dependency rather than an offline-convergent sync architecture

What I learned:

Git structurally cannot answer this question, which is why the whole argument is about what to bolt onto it - the cleanest statement of the problem came from Augment Code: "Git does not provide it for AI-assisted work. Attackers can spoof author fields, SSH keys prove possession rather than identity, and nothing natively binds a commit to whether a human, a model, or an agent produced it." Every proposal in the window is an attempt to add a fact git was never designed to carry. That framing also explains why the debate is so heated over something as small as a commit trailer: the trailer is currently the entire mechanism.

The ecosystem picked a trailer, and the same month it was picked, people started force-pushing to remove one - LLVM adopted a "human in the loop" policy in January and it has become the reference text: a human must read and review all LLM-generated code before asking anyone else to review it, agents that submit contributions without human approval are forbidden, and substantial tool-generated content is labelled with an Assisted-by: trailer. All Things Open reports that trailer settling as the ecosystem default. Running the other way, the automatic Co-Authored-By: Claude trailer has two open issues against it framed as branding user work without consent and polluting history with no opt-in and no warning, with one report of 489 commits tagged before the author noticed and a full history rewrite to clean up. @dcolascione watched GNU Emacs force-push master to rewrite history over exactly one such tag and called it painful to watch play out. The split is not transparency versus secrecy. It is whether a tool is a co-author or an editor, and that is a question about credit rather than accountability.

The most interesting line in LLVM's policy is not about code quality at all - alongside the human-in-the-loop rule sits a ban on using AI tools for issues marked "good first issue". devclass ties the whole policy to a rise in AI-driven nuisance contributions through 2025, and Phoronix reads it as a compromise rather than a ban. But protecting good-first-issues specifically is a decision to protect the onboarding path, not the codebase. The tickets that exist so a newcomer can learn the review process stop working if a model closes them, and a maintainer noticed that before the quality argument was settled.

The organizational pattern that is actually converging is one named human per agent, which is older than it looks - Pullflow calls it Bot Sponsorship: any AI-authored or reviewed pull request must have a named human who takes responsibility for it. The scaled-up version is a named human manager plus an agent registry recording owner, purpose, data access, decision authority and risk tier for each agent. Forbes names the failure it prevents: agents optimizing quietly, at scale, inside workflows nobody fully owns. Notice what this is - it is the code-owner model applied to a non-human contributor, which means the answer to "who owns agent-written code" is the same answer as before and the actual work is enforcement, not invention.

Legally the "AI did it" defense is already closed, and the awkward corollary is that you may not own what you cannot disown - California AB 316 took effect on 1 January 2026 and forecloses arguing in court that the AI acted on its own or beyond your control if you developed, modified or used it. Liability for distributing infringing output lands on the distributor rather than the tool vendor. At the same time, purely AI-generated code is generally not copyrightable in the US because copyright requires human authorship, a holding the D.C. Circuit affirmed in 2025 and the Supreme Court declined to review. So the code nobody can pin on you as author is also code you may have no exclusive claim to. Live tests are running on both sides: the GitHub Copilot suit was argued before the Ninth Circuit in February with no decision yet, a dog photographer lost a copyright case over an AI-generated version of her image, and xAI's first lawsuit against a user is explicitly a test of who is responsible for what Grok makes.

On the ground the question people actually ask is not who is to blame but who is expected to understand it - the highest-engagement thread in the window is an engineer on r/ExperiencedDevs with two years at their company facing a new project that is 99% AI generated and not knowing how to handle it, at 273 points and 163 comments. Forbes puts the institutional version of the same worry well: it sounds like a simple question until an auditor, regulator, customer or executive asks why the software behaves the way it does. The tooling response is provenance capture rather than detection - agent-trace and TracesHub record which lines came from which model via which tool and the prompt behind them, deterministic and hash-based at commit time rather than "87% likely AI" guesswork, with the pitch "git blame says you wrote it. Did you?" atomicdotdev/atomic goes further with token-level blame in a semantic change graph. The measured-not-guessed distinction is the design point worth stealing.

KEY PATTERNS from the research: 1. Git has no native binding between a commit and whether a human, model or agent produced it, so every answer here is a bolt-on convention, per Augment Code 2. Assisted-by: has become the de facto ecosystem trailer via LLVM's human-in-the-loop policy, which also forbids agents submitting without human approval, per LLVM 3. The loudest fight over the same mechanism is the opposite complaint - automatic Co-Authored-By trailers being applied without opt-in, with history rewrites to remove them, per anthropics/claude-code#64019 4. The organizational answer converging is a named human per agent - Bot Sponsorship on every AI-authored PR, extended to an agent registry with owner and risk tier, per Pullflow 5. "The AI did it" is not available as a legal defense in California from January 2026, while purely AI-generated code is simultaneously not copyrightable for lack of human authorship 6. Provenance tooling is converging on deterministic capture at commit time rather than probabilistic detection after the fact, which is a meaningfully different product than an AI-code detector