2026년 1월 21일의 Show HN

Hey HN, we trained and open-sourced a 1.5B model that predicts your next edits, similar to Cursor. You can download the weights here (https://huggingface.co/sweepai/sweep-next-edit-1.5b) or try it in our JetBrains plugin (https://plugins.jetbrains.com/plugin/26860-sweep-ai-autocomp...).

Next-edit autocomplete differs from standard autocomplete by using your recent edits as context when predicting completions. The model is small enough to run locally while outperforming models 4x its size on both speed and accuracy.

We tested against Mercury (Inception), Zeta (Zed), and Instinct (Continue) across five benchmarks: next-edit above/below cursor, tab-to-jump for distant changes, standard FIM, and noisiness. We found exact-match accuracy correlates best with real usability because code is fairly precise and the solution space is small.

Prompt format turned out to matter more than we expected. We ran a genetic algorithm over 30+ diff formats and found simple `original`/`updated` blocks beat unified diffs. The verbose format is just easier for smaller models to understand.

Training was SFT on ~100k examples from permissively-licensed repos (4hrs on 8xH100), then RL for 2000 steps with tree-sitter parse checking and size regularization. The RL step fixes edge cases SFT can’t like, generating code that doesn’t parse or overly verbose outputs.

We're open-sourcing the weights so the community can build fast, privacy-preserving autocomplete for any editor. If you're building for VSCode, Neovim, or something else, we'd love to see what you make with it!

I built a simple tool to compare hard drive and SSD prices by price-per-terabyte.

I kept having to calculate $/TB manually when shopping for NAS drives, so I made this to save myself the trouble.

It pulls prices from Amazon (US, CA, AU, and EU stores), calculates $/TB, and lets you filter by drive type, interface, form factor, and capacity.

Nothing fancy — just a sortable table updated daily.

Any feedback is more than welcome, I hope someone will find it useful!

S2 was on HN for our intro blog post a year ago (https://news.ycombinator.com/item?id=42480105). S2 started out as a serverless API — think S3, but for streams.

The idea of streams as a cloud storage primitive resonated with a lot of folks, but not having an open source option was a sticking point for adoption – especially from projects that were themselves open source! So we decided to build it: https://github.com/s2-streamstore/s2

s2-lite is MIT-licensed, written in Rust, and uses SlateDB (https://slatedb.io) as its storage engine. SlateDB is an embedded LSM-style key-value database on top of object storage, which made it a great match for delivering the same durability guarantees as s2.dev.

You can specify a bucket and path to run against an object store like AWS S3 — or skip to run entirely in-memory. (This also makes it a great emulator for dev/test environments).

Why not just open up the backend of our cloud service? s2.dev has a decoupled architecture with multiple components running in Kubernetes, including our own K8S operator – we made tradeoffs that optimize for operation of a thoroughly multi-tenant cloud infra SaaS. With s2-lite, our goal was to ship something dead simple to operate. There is a lot of shared code between the two that now lives in the OSS repo.

A few features remain (notably deletion of resources and records), but s2-lite is substantially ready. Try the Quickstart in the README to stream Star Wars using the s2 CLI!

The key difference between S2 vs a Kafka or Redis Streams: supporting tons of durable streams. I have blogged about the landscape in the context of agent sessions (https://s2.dev/blog/agent-sessions#landscape). Kafka and NATS Jetstream treat streams as provisioned resources, and the protocols/implementations are oriented around such assumptions. Redis Streams and NATS allow for larger numbers of streams, but without proper durability.

The cloud service is completely elastic, but you can also get pretty far with lite despite it being a single-node binary that needs to be scaled vertically. Streams in lite are "just keys" in SlateDB, and cloud object storage is bottomless – although of course there is metadata overhead.

One thing I am excited to improve in s2-lite is pipelining of writes for performance (already supported behind a knob, but needs upstream interface changes for safety). It's a technique we use extensively in s2.dev. Essentially when you are dealing with high latencies like S3, you want to keep data flowing throughout the pipe between client and storage, rather than go lock-step where you first wait for an acknowledgment and then issue another write. This is why S2 has a session protocol over HTTP/2, in addition to stateless REST.

You can test throughput/latency for lite yourself using the `s2 bench` CLI command. The main factors are: your network quality to the storage bucket region, the latency characteristics of the remote store, SlateDB's flush interval (`SL8_FLUSH_INTERVAL=..ms`), and whether pipelining is enabled (`S2LITE_PIPELINE=true` to taste the future).

I'll be here to get thoughts and feedback, and answer any questions!

Hey folks, I’m Hassan, one of the co-founders of Infracost (https://www.infracost.io). Infracost helps engineers see and reduce the cloud cost of each infrastructure change before they merge their code. The way Infracost works is we gather pricing data from Amazon Web Services, Microsoft Azure and Google Cloud. What we call a ‘Pricing Service’, which now holds around 9 million live price points (!!). Then we map these prices to infrastructure code. Once the mapping is done, it enables us to show the cost impact of a code change before it is merged, directly in GitHub, GitLab etc. Kind of like a checkout-screen for cloud infrastructure.

We’ve been building since 2020 (we were part of YC W21 batch), and iterating on the product, building out a team etc. However, back in 2020 one of our users asked if we can also show the carbon impact alongside costs.

It has been itching my brain since then. The biggest challenge has always been the carbon data. The mapping of carbon data to infrastructure is time consuming, but it is possible since we’ve done it with cloud costs. But we need the raw carbon data first. The discussions that have happened in the last few years finally led me to a company called Greenpixie in the UK. A few of our existing customers were using them already, so I immediately connected with the founder, John.

Greenpixie said they have the data (AHA!!) And their data is verified (ISO-14064 & aligned with the Greenhouse Gas Protocol). As soon as I talked to a few of their customers, I asked my team to see if we can actually finally do this, and build it.

My thinking is this: some engineers will care, and some will not (or maybe some will love it and some will hate it!). For those who care, cost and carbon are actually linked; meaning if you reduce the carbon, you usually reduce the cost of the cloud too. It can act as another motivation factor.

And now, it is here, and I’d love your feedback. Try it out by going to https://dashboard.infracost.io/, create an account, set up with the GitHub app or GitLab app, and send a pull request with Terraform changes (you can use our example terraform file). It will then show you the cost impact alongside the carbon impact, and how you can optimize it.

I’d especially love to hear your feedback on if you think carbon is a big driver for engineers within your teams, or if carbon is a big driver for your company (i.e. is there anything top-down about carbon).

AMA - I’ll be monitoring the thread :)

Thanks

I made this for myself, and it seemed like it might be useful to others. I'd love some feedback, both on the threat model and the tool itself. I hope you find it useful!

Backstory: I've been using many agents in parallel as I work on a somewhat ambitious financial analysis tool. I was juggling agents working on epics for the linear solver, the persistence layer, the front-end, and planning for the second-generation solver. I was losing my mind playing whack-a-mole with the permission prompts. YOLO mode felt so tempting. And yet.

Then it occurred to me: what if YOLO mode isn't so bad? Decision fatigue is a thing. If I could cap the blast radius of a confused agent, maybe I could just review once. Wouldn't that be safer?

So that day, while my kids were taking a nap, I decided to see if I could put YOLO-mode Claude inside a sandbox that blocks exfiltration and regulates git access. The result is yolo-cage.

Also: the AI wrote its own containment system from inside the system's own prototype. Which is either very aligned or very meta, depending on how you look at it.

I been building a view into companies based on their job postings. I am hoping it is useful to get a quick snapshot on the company say for interview prep etc. Please be advised that it is still a WIP in terms of data quality. Example urls: https://jobswithgpt.com/company-profiles/openai/ https://jobswithgpt.com/company-profiles/advanced-micro-devi...

Hey HN! I built Retain as the evolution of claude-reflect (github.com/BayramAnnakov/claude-reflect).

The original problem: I use Claude Code/Codex daily for coding, plus claude.ai and ChatGPT occasionally. Every conversation contains decisions, corrections, and patterns I forget existed weeks later. I kept re-explaining the same preferences.

claude-reflect was a CLI tool that extracted learnings from Claude Code sessions. Retain takes this further with a native macOS app that:

- Aggregates conversations from Claude Code, claude.ai, ChatGPT, and Codex CLI - Instant full-text search across thousands of conversations (SQLite + FTS5)

It's local-first - all data stays in a local SQLite database. No servers, no telemetry. Web sync uses your browser cookies to fetch conversations directly.

Hi HN! I built Ghibli Search, a semantic search engine for Studio Ghibli movie scenes (e.g. Spirited Away, My Neighbor Totoro, Howl's Moving Castle, etc.).

Describe a dreamscape like "flying through clouds at sunset" or upload an image, and it finds visually similar scenes from the films.

Live demo: https://ghibli-search.anini.workers.dev/

Full Cloudflare stack: Workers, AI Search, R2, Workers AI

Open source: https://github.com/aninibread/ghibli-search

Would love feedback on the search quality and any ideas for improvements!

I am working on building (and have made my first prerelease) for a Digital Audio Workstation with git like branching version control.

It's free for local use and paid for cloud syncing or collaboration.

Hey HN!

I built this after getting frustrated with losing great ideas while driving, cooking, or exercising. You know that moment when inspiration strikes but your hands are occupied?

The Problem: Doubao AI earphones (popular in China, similar to AirPods but with built-in AI) are great for Q&A, but all conversations disappear after listening. It's a closed ecosystem with no way to export valuable content.

My Solution: A Python tool that monitors the Doubao web interface and automatically syncs voice notes to Obsidian in real-time.

What makes it interesting:

30+ speech variation recognition - Works even if you say "note" instead of "take note" or use filler words like "um, note this down" Hands-free operation - Just say "Doubao, take a note, [your content]" and it appears in Obsidian instantly Smart deduplication - Won't create duplicate entries for similar content Cross-platform - Works on Windows, macOS, Linux Technical approach:

Uses Playwright to monitor DOM changes and network requests Regex engine handles speech variations and colloquialisms SQLite for deduplication logic Async I/O for real-time file operations Real use cases I've tested:

Capturing meeting insights while driving between offices Recording workout thoughts during runs Noting recipe improvements while cooking Quick idea capture during walks The tool essentially breaks the walled garden of AI earphones and turns them into a proper knowledge management device. It's like having a voice assistant that actually remembers and organizes everything you tell it.

Demo: Say "Doubao, note this: remember to research async patterns" → Instantly appears in Inbox/Voice Notes/2026-01-21.md

Built with Python + Playwright + SQLite. MIT licensed.

What do you think? Have you faced similar issues with voice assistants that don't persist information? Would love to hear about your workflows for capturing ideas on-the-go!

GitHub: https://github.com/GptsApp/doubao-earphone-to-obsidian

Hi HN, I'm Tony.

I built Grov (https://grov.dev/) because I hit a wall with current AI coding assistants: they are "single-player." The moment I kill a terminal pane or close a chat session, the high-level reasoning and architectural decisions generated during that session are lost. If a teammate touches that same code an hour later, their agent has to re-derive everything from scratch or read many documentation files for basically any feature implemented or bug fixed.

I wanted to stop writing a lot of docs for everything just to give context to my agents or have to re-explain to my agents what my teammate did and why.

Grov is an open-source context layer that effectively gives your team's AI agents a shared, persistent memory.

Here is the technical approach:

1. Decision-grain memory, not document storage: When you sync a memory, Grov structures knowledge at the decision level. We capture the specific aspect (e.g., "Auth Strategy"), the choice made ("JWT"), and the reasoning ("Stateless for scaling"). Crucially, when your codebase evolves, we don't overwrite memories, we mark old decisions as superseded and link them to the new choice. This gives your team an audit trail of architectural evolution, not just the current snapshot.

2. Git-like branches for memories: Teams experimenting with different approaches can create memory branches. Memories on a feature branch stay isolated until you are ready to merge. Access control mirrors Git: main is team-wide, while feature branches keep noise isolated. When you merge the branch, those accumulated insights become instantly available to everyone's agents.

3. Two-stage injection (Token Optimization): The expensive part of shared memory isn't storage it's the context window. Loading 10 irrelevant memories wastes tokens and confuses the model. Grov uses a "Preview → Expand" strategy: Preview: A hybrid semantic/keyword search returns lightweight memory summaries (~100 tokens). Expand: The full reasoning traces (~500-1k tokens) are only injected if the agent explicitly requests more detail. This typically results in a 50-70% token reduction per session compared to raw context dumping.

The result: Your teammate's agent doesn't waste 5 minutes re-exploring why you chose Postgres over Redis, or re-reading auth middleware. It just knows, because your agent already figured it out and shared it.

Github: https://github.com/TonyStef/Grov

Hey HN! I'm Fabio and I built UltraContext, a simple context API for AI agents with automatic versioning.

After two years building AI agents in production, I experienced firsthand how frustrating it is to manage context at scale. Storing messages, iterating system prompts, debugging behavior and multi-agent patterns—all while keeping track of everything without breaking anything. It was driving me insane.

So I built UltraContext. The mental model is git for context:

- Updates and deletes automatically create versions (history is never lost)

- Replay state at any point

The API is 5 methods:

  uc.create()   // new context (can fork from existing)
  uc.append()   // add message
  uc.get()      // retrieve by version, timestamp, or index
  uc.update()   // edit message → creates version
  uc.delete()   // remove message → creates version

Messages are schema-free. Store conversation history, tool calls, system prompts—whatever shape you need. Pass it straight to your LLM using any framework you'd like.

What it's for:

- Persisting conversation state across sessions

- Debugging agent behavior (rewind to decision point)

- Forking contexts to test different flows

- Audit trails without building audit infrastructure

- Multi-agent and sub-agent patterns

What it's NOT:

- Not a memory/RAG system (no semantic search)

- Not a vector database

- Not an Orchestration/LLM framework

UltraContext handles versioning, branching, history. You get time-travel with one line.

Docs: https://ultracontext.ai/docs

Early access: https://ultracontext.ai

Would love feedback! Especially from anyone who's rolled their own context engineering and can tell me what I'm missing.

Hi Hacker News! I’m David Huie. I’m launching SpeechOS, a drop-in voice input SDK for web apps.

I was inspired by Wispr Flow and wanted the same workflow inside business apps (CRMs, docs, forms, support tools), not just a standalone tool. It’s saved me a massive amount of time vs typing.

How it works: add a couple lines of JS plus an API key, and SpeechOS shows a small mic widget on every text field.

Live demo: https://www.speechos.ai/

(Click a text box and the mic widget appears; click the gear icon to see settings, custom vocabulary, and snippet configuration.)

Users can:

- Dictate: speak naturally, real-time voice to polished text (punctuation, no filler/typos)

- Edit: say “make it shorter”, “fix grammar”, “translate...”

- Command: define Siri-style app actions (for example, “submit form”, “mark complete”), and we match intent to your commands

It also supports:

- Custom vocabulary: domain terms and names (product names, acronyms, jargon) so they transcribe correctly

- Text snippets: saved reusable blocks of text you can insert by voice (for example, “my signature”, “disclaimer”, “my address”)

Why: text entry speed and accuracy still matter for productivity tools. A large-scale text entry dataset with 37,370 participants showed an average typing speed of 36.2 WPM and ~2.3% uncorrected errors. In speech research, speech recognition was about 3× faster than keyboard input and had ~20.4% lower error rate for English text entry. (https://hci.stanford.edu/research/speech/)

SpeechOS is currently in beta and free for now. Sign up at https://app.speechos.ai/accounts/signup/ and enter this HN-only beta code: HN-JFc74cVC (please don’t share outside HN).

Links:

SDK repo: https://github.com/speechos-org/speechos-client

Demo: https://www.speechos.ai/

Signup (code: HN-JFc74cVC): https://app.speechos.ai/accounts/signup/

I’d love feedback on:

1) Where this is most valuable in your stack (notes? docs? CRM entry? support macros?)

2) What you’d want from voice commands/snippets configuration

3) What would make you comfortable shipping this (privacy/security, latency, pricing)

If you’re building anything in voice AI/dictation, I’d be happy to swap notes ([email protected]).

I built this because I got tired of Stockfish giving me evaluations (+0.5) without explaining the actual plan. Most opening explorers focus on statistics (Win/Loss/Draw). I wanted a tool that explains the strategic intent behind the moves (e.g., "White plays c4 to clamp down on d5" vs just "White plays c4"). The Project: Comprehensive Database: I’ve mapped and annotated over 3,500 named opening variations. It covers everything from main lines (Ruy Lopez, Sicilian) to deep sidelines. Strategic Visualization: The UI highlights key squares and draws arrows based on the textual explanation, linking the logic to the board state dynamically. Hybrid Architecture: For the 3,500+ core lines, it serves my proprietary strategic data. For anything deeper/rarer, it seamlessly falls back to the Lichess Master API so the explorer remains functional 20 moves deep. Stack: Next.js (App Router), MongoDB Atlas for the graph data, and Arcjet for security/rate-limiting. It is currently in Beta. I am working on expanding the annotated coverage, but the main theoretical landscape is mapped. Feedback on the UI/UX or the data structure is welcome.

Hi HN, I’m experimenting with a small Python library called PicoFlow for building LLM agent workflows using a lightweight DSL.

I’ve been using tools like LangChain and CrewAI, and wanted to explore a simpler, more function-oriented way to compose agent logic, closer to normal Python control flow and async functions.

PicoFlow focuses on: - composing async functions with operators - minimal core and few concepts to learn - explicit data flow through a shared context - easy embedding into existing services

A typical flow looks like:

  flow = plan >> retrieve >> answer
  await flow(ctx)

Patterns like looping and fork/merge are also expressed as operators rather than separate graph or config layers.

This is still early and very much a learning project. I’d really appreciate any feedback on the DSL design, missing primitives, or whether this style feels useful for real agent workloads.

Repo: https://github.com/the-picoflow/picoflow

A fork of Solar System Live that generates animated videos showing planetary orbits over any date range. Tracks orbital statistics (how many times Earth was lapped by Mercury/Venus, or lapped outer planets) and overlays dates/ages on each frame.

Example: Einstein's lifetime (1879-1955) showing 76 years of solar system evolution. Built with Python + Pillow + ffmpeg, runs locally with Lighttpd.

https://github.com/simondorfman/solar_system_live

We use optical illusion-style puzzles to reflect the characters’ psychology.

Hi HN,

I’m Eric, and I built www.meetgoran.com

Goran is a Mac/Windows desktop app for sales teams that turns your calls into actionable coaching: what was covered (and what wasn’t), what to improve next time, and patterns across reps.

First 5 meetings free (no credit card) ~ 10 min setup.

Connect Google Calendar so it can join scheduled meetings and capture the call context

What it does (practical, not “AI magic”):

- Produces structured sales notes + highlights key moments (pricing pushback, next steps, etc.)

- Scores calls against frameworks like MEDDIC/BANT (or your own checklist)

- Helps managers compare “top vs median” behaviors without rewatching hours of recordings

- Makes good examples searchable so new reps can copy what’s already working

Why I built it:

In most teams, the best talk-tracks stay trapped in recordings nobody rewatches, and managers don’t have time to coach every rep. I wanted something that turns calls into a “self-building playbook” reps will actually use.

What I’d love feedback on:

- Where would this not fit (team size, workflow, compliance constraints)?

- What should be the “default” output: rep coaching, manager dashboard, or team playbook?

Super happy with all responses.

The data of your page is stored in the URL shortener's database.

Visit https://tinyurl.com/mrpas5dc to see how it works.

The full URL, if you don't trust the short URL:

https://mdview.io/#mdv=N4IgbiBcCMA0IBMCGAXJUTADrhzWOAtgnjgMQ...

A common approach to automating Amazon shopping or similar complex websites is to reach for large cloud models (often vision-capable). I wanted to test a contradiction: can a ~3B parameter local LLM model complete the flow using only structural page data (DOM) plus deterministic assertions?

This post summarizes four runs of the same task (search → first product → add to cart → checkout on Amazon). The key comparison is Demo 0 (cloud baseline) vs Demo 3 (local autonomy); Demos 1–2 are intermediate controls.

More technical detail (architecture, code excerpts, additional log snippets):

https://www.sentienceapi.com/blog/verification-layer-amazon-case-study

Demo 0 vs Demo 3:

Demo 0 (cloud, GLM‑4.6 + structured snapshots) success: 1/1 run tokens: 19,956 (~43% reduction vs ~35k estimate) time: ~60,000ms cost: cloud API (varies) vision: not required

Demo 3 (local, DeepSeek R1 planner + Qwen ~3B executor) success: 7/7 steps (re-run) tokens: 11,114 time: 405,740ms cost: $0.00 incremental (local inference) vision: not required

Latency note: the local stack is slower end-to-end here largely because inference runs on local hardware (Mac Studio with M4); the cloud baseline benefits from hosted inference, but has per-token API cost.

Architecture

This worked because we changed the control plane and added a verification loop.

1) Constrain what the model sees (DOM pruning). We don’t feed the entire DOM or screenshots. We collect raw elements, then run a WASM pass to produce a compact “semantic snapshot” (roles/text/geometry) and prune the rest (often on the order of ~95% of nodes).

2) Split reasoning from acting (planner vs executor).

Planner (reasoning): DeepSeek R1 (local) generates step intent + what must be true afterward. Executor (action): Qwen ~3B (local) selects concrete DOM actions like CLICK(id) / TYPE(text). 3) Gate every step with Jest‑style verification. After each action, we assert state changes (URL changed, element exists/doesn’t exist, modal/drawer appeared). If a required assertion fails, the step fails with artifacts and bounded retries.

Minimal shape:

ok = await runtime.check( exists("role=textbox"), label="search_box_visible", required=True, ).eventually(timeout_s=10.0, poll_s=0.25, max_snapshot_attempts=3)

What changed between “agents that look smart” and agents that work Two examples from the logs:

Deterministic override to enforce “first result” intent: “Executor decision … [override] first_product_link -> CLICK(1022)”

Drawer handling that verifies and forces the correct branch: “result: PASS | add_to_cart_verified_after_drawer”

The important point is that these are not post‑hoc analytics. They are inline gates: the system either proves it made progress or it stops and recovers.

Takeaway If you’re trying to make browser agents reliable, the highest‑leverage move isn’t a bigger model. It’s constraining the state space and making success/failure explicit with per-step assertions.

Reliability in agents comes from verification (assertions on structured snapshots), not just scaling model size.

Hey HN,

Staff Engineer at Ably here. Over the past few months I've been speaking to engineers building AI assistants, copilots, and agentic workflows (over 40 companies at this point), with particular focus on cloud-hosted agents.

I expected the hard problems to be in model selection, prompt engineering, and orchestration. Instead, the same infrastructure challenges kept coming up: realtime sync between agents and end clients is surprisingly painful to get right.

- Managing and scaling WebSocket or SSE connections between agents and clients

- Buffering messages server-side and implementing replay logic for reconnecting clients

- Tracking what each client has received across multiple devices

- Ensuring continuity between historical and live responses on initial load

- Routing reconnecting clients to the correct agent instance in distributed deployments

Ably AI Transport solves this: it's a drop-in transport layer that sits between your agents and end-user devices.

We discovered many companies who were already using Ably Pub/Sub to tackle these problems. The pub/sub pattern decouples agents from clients: agents publish to channels, clients subscribe, Ably handles delivery and replay.

AI Transport makes this easier - for example, we've added message appends for efficient token streaming, and annotations for attaching metadata like citations.

A few of the interesting technical pieces:

- Channel-oriented architecture: In connection-oriented setups, the connection pokes the agent into life. If the connection drops, on reconnection the agent must figure out what state each client is missing. AI Transport uses channels instead: agents publish, clients subscribe, the channel handles replay. Presence events let agents detect when users go online/offline or connect from multiple devices.

- Identity in decoupled pub/sub: Users authenticate with your server, which issues JWTs with embedded clientId and capabilities. Agents receive messages with cryptographically verified identity. User claims (ably.channel.* in the JWT) appear in message.extras.userClaim - useful for HITL workflows where you verify an approver's role before executing a tool call.

- Token streaming with appends: New message.append operation lets you build a response incrementally. Clients joining mid-stream get a message.update with the complete response so far, then receive subsequent appends. Channel history contains one compacted message per response.

- Annotations for citations: Attach citation metadata to responses without modifying content. Clients can subscribe to individual annotations or obtain them on demand via REST. Ably also automatically aggregates annotations into summaries (e.g. count by domain name), which are delivered to clients in realtime.

- Messaging patterns: Docs include patterns for tool calls, human-in-the-loop approval flows, and chain-of-thought streaming.

Docs: https://ably.com/docs/ai-transport

If you're building AI UX, I'd love to hear what problems you've hit and what you've built in-house.

Thanks!

Mike Christensen

I’ve been working on MicroState, a city builder prototype written entirely in vanilla JavaScript using the HTML5 2D Canvas API.

My goal was to see how far I could get with a 2.5D isometric style simulation with vanilla JavaScript built very simply and drawn entirely with procedural generation for maps, tiles, roads, trees, buildings, etc.

The most interesting element is probably the terrain model, which allows for fairly arbitrary terrain.

Although some of the generated graphics like trees are cached as sprites, buildings- which are much more intensive to draw - are not cached yet, and many will probably cause your CPU fan to go brrr.

It's not quite a game yet, though it is "playable" and I thought folks might find it fun to try and have suggestions for features and gameplay they'd like to see, both in single player and multiplayer.

I'll be publishing the source on GitHub soon so it's easier to submit and track features and defects (and to clone and fork).

Happy to answer any questions!

Claude Cowork just launched, bringing agentic AI to everyday work. Rowboat is an open-source alternative that builds knowledge that persists over time.

A quick demo is here: https://youtu.be/T2Bmiy05FrI

It connects to Gmail and meeting notes (Granola, Fireflies) and organizes them into an Obsidian-compatible vault. Plain Markdown files with backlinks, organized around things like people, projects, organizations, and topics. As new emails and meetings come in, the right notes update automatically.

Rowboat is also the primary interface for this vault. You can read, navigate, edit, and add notes directly. It includes a full markdown editor and graph visualization so you can see how context builds up across conversations.

Why not just search transcripts when you need something? Search only answers the questions you think to ask. A system that accumulates context over time can track decisions, commitments, and relationships across conversations, surfacing patterns you didn’t know to look for.

Once this context exists, it becomes knowledge that Rowboat can work with. Because it runs on your machine, it can work directly with local files and run shell commands or scripts, including tools like ffmpeg when needed.

The link in the title opens an interactive example graph showing how context accumulates across emails and meetings. We used a founder example because it naturally includes projects, people, and long-running conversations, but the structure applies to any role.

Examples of what you can do with Rowboat: draft emails from accumulated context, prep for meetings by assembling past decisions and enriching them with external research (for example via Exa MCP), organize files and project artifacts on your machine as work evolves, or turn notes into voice briefings via MCP servers like ElevenLabs.

We’re opinionated about noise. We prioritize recurring contacts, active projects, and ongoing work, and ignore one-off emails and notifications. The goal is long-lived knowledge that compounds over time.

All data is stored locally as plain Markdown. You can use local models via Ollama or LM Studio, or a hosted model. Apache-2.0 licensed.

GitHub: https://github.com/rowboatlabs/rowboat

Curious how this fits into your current workflow for everyday work.

Show HN: What I learned building a local-only password manager (PassForgePro)

Hi HN,

I built PassForgePro as a learning project to better understand password manager design, local-first security, and common cryptographic pitfalls.

The goal was not to replace mature tools like Bitwarden or KeePass, but to explore:

* how a local-only, zero-knowledge style design can work * key derivation with PBKDF2 and encrypted SQLite vaults (AES-256-GCM) * handling sensitive data in memory and clipboard cleanup * defining a realistic threat model and its limitations

This project is experimental and unaudited. I’m sharing it mainly to get feedback on the architecture, crypto choices, and overall approach, and to discuss what I got wrong or could improve (audits, reproducible builds, testing, etc.).

I’d really appreciate feedback, especially from people with security or cryptography experience.

Repo: https://github.com/can-deliktas/PassForgePro Docs / demo: https://can-deliktas.github.io/PassForgePro

Google reviews piss me off because it's either 1 star or 5 stars and who knows if the person actually ate the food. I wish people had to visit a place multiple times, spaced out, before their ratings would even count. I decided to take that philosophy and apply it to one dish, Phở.

I'm going to all the restaurants that serve phở in Portland, Oregon's city limits and rating them. You can see the ranking, but not the point values until I've visited twice. Technically you can go get the data as it's open source and get the scores, but most people are too lazy to do that. It's a simple static site built with astro, so hammer away at what I did wrong.

I've been going in spurts over the past couple years and I'm hoping to get through the first round within the next month or two. I'm a white guy that doesn't know anything so of course the ratings are completely subjective.

Hey HN! I'm the maker of Mudo.

I built this because my therapist kept asking me to journal my anxiety, but every app I tried had 20 questions, 47 emotions, and felt overwhelming. I'd quit after 2 days.

So I made the simplest possible version: 4 moods (Happy, Calm, Sad, Anxious), one tap, done. After 30 days I realized I'm not "always anxious" like I thought - just Sunday nights (work dread).

Technical stuff: - Built with SwiftUI - Local-first storage (privacy-focused) - Optional iCloud sync - No backend, no tracking, no ads

It's iOS-only right now (sorry Android folks). Free version works fine, premium unlocks more moods and unlimited history.

Would love feedback, especially on: - Is the free tier too limited? - Should I add journal notes or keep it dead simple? - Any features you'd want if you were tracking anxiety?

Thanks for checking it out!

Hi Everyone,

I created a mobile app called Accumoo, and I would appreciate it if y'all can have a look, download and give me a favorable review. Lots of blood, sweat, tears and love went into this app, and I hope you LOVE it as much as I do - it's the app I always needed and wanted. Anyhow, I've been a Rails developer and Software Engineer for a long time, and this is my first stab at a mobile app. It's a "habit tracker" app on steroids that's just fun to use - syncs across devices, local-first architecture - and an easter egg game for good measure.

Help a disabled vet out and give it a go.

Thank you in advance. GA

Cursor published a great post last week on scaling long-running autonomous coding agents to build a browser.

We’ve been exploring a similar idea, but applied to math proofs

We show how a swarm of agents, coordinated via shared memory, can generate a Lean proof for a non-trivial multi-step math problem-Putnan A2-that a single agent struggled with. We were feeling fancy so we wrote a full post and captured the runtime.

Harness will be public soon(tm) for you to run it yourself.

The repo contains the code and analysis — feedback welcome.

A small web tool that helps decide what to cook using the ingredients you already have.

It doesn’t generate strict recipes, it offers a direction for a meal, without measurements.

Built as a calm alternative to recipe overload.

tl;dr - typing /login in claude code in a docker container will do auth in your host's browser :)

My team and I develop almost exclusively in dev containers. If you initiate an oauth2 auth from inside the dev container (for claude, azure cli, etc) you either (a) have some annoying copy and pasting to do or (b) you are using VS Code which magically makes it work with your host browser.

This utility makes the VS Code magic into a standalone utility so you don't need to be using VS Code but still get automatic proxying of your oauth2 requests to your hosts browser.

The basic idea (which is what VS Code does under the hood I believe) is to set up a server<->client relationship between host<->container that grabs your container-based cli tools browser open request, forwards out to the host, does oauth, forwards it back into the container.

We've been using it for a while and it works great. Thought I'd share.

Hi, creator here.

Most Raft/Paxos libraries treat the state machine as a black box. That’s fine until the state machine does real-world things like charging a card, sending an email or firing a webhook.

Then the leader crashes after the side effect but before commit, and you get duplicates. Every time. All the “exactly once” hand-waving collapses the moment a process dies mid-flight.

This repo is my attempt to fix that by design: side effects live in the replicated log, not behind it.

how it works, roughly:

Side effects are written as pending entries in replicated state. Only the current leader executes them, under a fencing token.

Leadership is fenced durably so a zombie leader can’t wake up and re-run old effects.

The state machine runs with a deterministic RNG seed + block time from the log, so replay is bit-for-bit or it halts.

The WAL is strict: CRC + hash-chained. Corruption stops the system instead of guessing.

Trade-offs are explicit:

Effects are at-least-once. Exactly-once requires stable IDs and sink-side dedup.

CP over AP. Safety over availability.

If you’ve ever been paged because a leader died at exactly the wrong microsecond, you know why I built this.

Repo: https://github.com/abokhalill/chr2

Happy to answer any questions about chr2 architectural internals or design trade offs.

I spent 15 years in FP&A and corporate budgeting. For the first 10, I actively avoided management because the path to leadership seemed designed for extroverts. Be more visible. Speak up in meetings. Network at happy hours.

I eventually got promoted anyway, mostly by taking ownership of problems I cared about fixing more than I cared about avoiding meetings. Turns out if you run the meeting, you can keep it organized.

Recently I taught myself to code using AI tools (Cursor + Claude, mostly) and wanted to build something that would have helped my past self. The result is leadquiet.com an AI coaching tool specifically for introverts in leadership roles.

It's text-based (no video calls), focused on energy management and leveraging introvert strengths rather than "overcoming" them, and priced for individuals ($15/mo).

I'm not from tech. I still work full-time in finance. Built this nights and weekends. Would love feedback if you try it.

I wanted a minimalist launcher that limits the apps I can access based on my location. I waste way to much time doom scrolling at home, and simply removing the app from my apps list based on my location has really helped.

Tap water contamination is a pan-India issue, but stays invisible until it becomes a crisis. Here’s my small civic attempt to fix that.

More here: https://www.reddit.com/r/india/comments/1qi1bhg/tap_water_co...

LLMs are stateless - every call starts from zero. Prometheus adds persistent memory inspired by cognitive science: episodic, semantic, procedural, identity, and imagination layers.

Key features: - Contradiction detection when new info conflicts with stored knowledge - Dream mode: synthesizes frameworks from accumulated knowledge during idle time - Concept imagination: builds internal representations with emotional valence - Works with DeepSeek, OpenAI, Anthropic, Ollama

Built this because I needed persistent context for a biomedical research system. Happy to answer questions about the architecture.

Kar Beyaz Tüm Renkler is a spectrum album: a single musical idea observed through multiple forms. Each track starts from the same core motif and applies controlled stylistic transformations, producing distinct yet related pieces.

Conceptually, this treats the music as one latent musical structure projected into different musical domains.

A spectrum album is a general compositional approach: a way of exploring how one theme can remain itself while producing many realizations. Kar Beyaz Tüm Renkler is its first application.

The workflow uses structured prompting in Suno for generation, followed by external loudness normalization and AI mastering for consistency across tracks.

Replaces method calls and field accesses with reflection equivalents → makes static analysis and decompilers much less useful. Experimental, performance hit expected.

Hello HN folks- maker here, I built Sornic because I have 100+ saved articles I never read. Now I listen to them while commuting.

How it works: - Paste any article URL - Mozilla Readability extracts content - Claude Haiku cleans it up (removes "subscribe", ads, etc.) - OpenAI TTS generates natural audio

Free to use, 5 articles/day, no signup.

Stack: Next.js, Upstash Redis, Vercel

What I'd love feedback on: - Which sites don't work (so I can improve extraction) - Voice quality preferences - Would you pay for unlimited?

Thanks for trying it!

I built a browser-based tool to visualize Google Location History after they moved Timeline data to on-device storage, making it harder to view your own data.

Demo: https://ethan.dev/utilities/location-history-visualizer

Key features:

• 100% client-side – your data never leaves your browser

• Supports new location-history.json format (from Google Maps app export)

• Also works with older Google Takeout formats (Records.json, Semantic Location History)

• Interactive map with Leaflet.js, customizable styling, PNG export

• No signup, no analytics, no tracking

Technical details:

- Uses Leaflet for mapping, dom-to-image for exports

- Parses multiple Google Timeline formats (they've changed it 3 times)

- Handles the new "geo:lat,lng" coordinate format

- Date range filtering, fullscreen mode, style customization

Why I built this: Google's Timeline migration to on-device storage broke web access. You can export from the Maps app (Settings → Location → Export Timeline data) but there's no easy way to visualize it. This tool runs entirely in your browser with zero server interaction.

The code handles visit objects (places you stayed) and activity objects (routes between locations), showing semantic labels like "Home" and confidence scores.

Open to feedback on the parser logic – Google's format isn't well documented.

First MVP

Built a social dare board where people pay others to do stupid things.

Would love feedback https://idareyou.vercel.app/

Hi HN,

Most productivity tools assume you already know what to do. I kept getting stuck before that point.

Everpath is an experiment in planning goals as paths and roadmaps instead of task lists. You start with a goal written in natural language, and it generates a roadmap you can iterate on:

- reshape it by talking to it (“make this slower”, “focus on fundamentals”)

- view it as a board when executing

- view it as a calendar when committing time

- use a discussion mode that pushes back on unrealistic plans

This is not meant to replace discipline or effort. It’s meant to make starting less mentally expensive.

Curious what resonates and what doesn’t.

I built a CLI tool that converts natural language to SQL by wrapping LLM CLIs (Claude Code, Codex, Cursor) that already understand your codebase.

The insight: these CLIs already index your schemas, migrations, and models. Instead of building another NL2SQL tool with custom embeddings, I just wrapped what already works.

How it's different: - No schema sync. New table? git pull. Done. - No embeddings to regenerate - Follow-up queries work naturally (session persists) - Uses your actual table/column names

Usage: $ cd your-project $ qry init $ qry > get users who signed up last week SELECT * FROM users WHERE created_at >= NOW() - INTERVAL '7 days';

Also exposes an API server for Slack bots, admin tools, etc.

GitHub: https://github.com/amansingh-afk/qry

Tradeoff: requires one of these CLIs installed. But if you're already using Claude Code or Cursor, it just works.

Would love feedback on the approach.

a website for bee swarm simulator blue hive guide

Hi HN,

I recently shipped a small MVP called ImproveThis, and I wanted to share the thinking behind it and get feedback from the community.

The core idea is simple: the same message can sound very different depending on who it’s sent to. A note to a manager, a colleague, or a friend often needs a different tone, even if the intent is the same.

ImproveThis lets users define people they commonly write to and refines text accordingly. What’s interesting to me isn’t the AI part, but the product decisions around it.

I actually bought the domain back in May 2025, but between a full time job and personal commitments, I kept postponing it. Recently, I decided to stop optimizing for “perfect” and instead ship something usable and learn from real usage.

A few deliberate choices in this MVP: - No pricing plans yet - No payment integration - One free plan with 100 refinements per month - No credit card required

At this stage, I’m prioritizing usage patterns and feedback over monetization. I want to understand: When people actually use this Whether the “who you’re writing to” framing is helpful What feels unnecessary or missing

I’m sharing this here because HN discussions tend to surface practical feedback that’s hard to get elsewhere. Happy to answer questions about the product, the decisions behind it, or where I’m unsure. Feedback very welcome.

I spent months building an app only to realize I had zero distribution. To solve this, I’ve manually vetted 40+ influencers (reach up to 160k) specifically for SaaS promotion. The platform is live at ShipShared.link. We’re selecting our “Founding 10” startups for a February 9th pilot. The Model: • No Monthly Subscriptions: You don't pay a monthly fee just to access the platform. • Fixed Campaign Fees: Founders pay a fixed fee to launch a campaign, which provides predictable reach. • Verified Influencers: We handle the vetting so you don't have to "launch and pray." I'd appreciate any feedback on the model or the site.

Launched Bricolaje today

Bricolaje is a desktop application that uses AI to suggest terminal commands, helping you stay productive while reducing the friction that often comes with command-line workflows.

It pairs with a companion CLI tool, bj, so you can request suggestions directly from the terminal you’re already using—and keep a clean record of what was proposed and what worked.