sachaa

Since Jev came out I've been exploring how I could bring this great system one concept directly to the browser with similar latency. I've seen several LLM-wrapped system one alternatives but the performance was never what I expected. When I discovered Laya I realized we might have a feasible solution here. After multiple iterations and improvements I have a version that is able to get results in 100-200ms.

I made it open source: https://github.com/wexare-ai/browser-laya

System one systems will be essential for the future of AI and truly believe we need to push for more decentralized solutions like this.

This is really cool! Love generative art like this. Is the open source repo available somewhere?

The value shouldn't be in reporting (aka "being loud") status updates, it’s in signaling where you’re stuck or unsure. Status updates are just noise if they don’t invite help.

I share the optimism here. Connecting dots across knowledge, lived experience and purpose remains, to me, a deeply human pursuit. The more AI discovers, the more possibilities we have to connect those discoveries to questions that matter to us.

The irony is that AI makes it easier than ever to show what you can do, but people are using it to hide who they are.

What worries me isn’t AI replacing experts, it’s that we may stop producing people who know enough to notice when AI is confidently wrong.

Fair points, especially on GSM8K saturation and Qwen possibly already sitting close to the solution. That said, even if this is mostly "last-mile alignment", the fact that it can be done with such a tiny signal is still interesting, it suggests the gap between capability and behavior might be much smaller (and cheaper to bridge) than we assume.

If 13 parameters can unlock better reasoning, then we will not be "training" models, we'll be steering them. Most of the capability is already there.

The real unlock isn’t TinyLoRA, it’s what this implies: ultra-cheap, continuous adaptation. The bottleneck shifts from compute to having a good reward signal.

You can also do this with a simple bookmarklet, no extension needed.

Create a new bookmark in your browser, name it something like "Profile HN User", and paste this as the URL:

javascript:void(function(){var u;var m=window.location.href.match(/news\.ycombinator\.com\/user\?id=([^&]+)/);if(m){u=m[1]}else{u=prompt(%27Enter HN username:%27)}if(!u)return;var msg=%27Profile this HN user: https://hn.algolia.com/api/v1/search_by_date?tags=comment,au...})()

If you're on a HN profile page (news.ycombinator.com/user?id=someone) it grabs the username automatically. Otherwise it prompts you to type one. It copies the profiling prompt to your clipboard and opens a new Claude conversation, just Cmd/Ctrl+V and hit Enter.

Thanks for the feedback. This is a proof of concept, not production-hardened software, and the README should be clearer about that.

To your questions:

- 1. The CryptoKey is extractable: false, so JS can't export the raw key material, it only exposes encrypt/decrypt operations. It won't stop a full XSS attack on the same origin, but it does prevent casual inspection of IndexedDB/DevTools. Defense in depth, not a silver bullet.

- 2 & 4. You're right, the fetch_url tool and javascript eval in the worker both have unrestricted network access. A confirmation step for outgoing requests is worth adding. Good callout.

- 3 Honest oversight, no reason the Telegram token shouldn't get the same treatment. Will fix.

Updating the security language in the README to be more accurate about the threat model. PRs welcome if anyone wants to tackle sandboxing the JS tool (iframe with a null origin is one approach).

Thanks! Currently the scheduler runs on the main thread. It checks every 60s and fires due tasks while the app is open. So it works well for recurring prompts during active use, but won't fire if the PWA is closed since browsers don't support persistent background timers. Periodic Background Sync is the closest web API but it's Chrome-only with no timing guarantees, so for now pinning the tab is the reliable path.

Agree and disagree. The focus should not be on "code" but exposing them early on to problem solving:

https://www.youtube.com/watch?v=mvK0UzFNw1Q

If coding is the way to go to solve a problem then be it. If plumbing is the solution then that is what they should learn.

The key is to empower them to solve problems early on. The good news is that that can even happen in their backyard getting dirty.