Hacker News

Article URL: https://twitter.com/colingorrie/status/2026658482959565246

Comments URL: https://news.ycombinator.com/item?id=47162519

Points: 2

# Comments: 0

Article URL: https://www.bloomberg.com/news/articles/2026-02-24/apple-s-touch-screen-macbook-pro-to-have-dynamic-island-new-interface

Comments URL: https://news.ycombinator.com/item?id=47162516

Points: 2

# Comments: 0

Hi HN — I've been working on Falcon, a developer collaboration platform built around portable identity instead of server ownership. The core idea: communities shouldn't disappear when a platform, server, or admin does. Your identity and relationships should persist. This latest iteration moves Falcon into a service-oriented architecture and introduces a trust-gated access model tied to AT Protocol identities. What's new:

Identity-first access: entry to communities based on verified identity + trust signals, not invite links Trust service: prototype for reputation/relationship-based gating Gateway: auth + routing boundary for identity-aware services Real-time infra: JetStream-backed messaging layer in progress Mono-repo with bounded services: gateway, trust, messaging (SIV), client, protocol lexicons

The goal isn't "decentralization for its own sake." It's to test whether developer communities would coordinate differently if identity and membership weren't locked to a single platform like Discord or Slack. Still early:

prototype stage infra evolving quickly no production deployment yet

I'm a solo founder with 10 years of backend experience, building this because my community needs it. I'm especially looking for feedback from OSS maintainers, infra/protocol engineers, and teams running private dev communities. Main question: Would identity-portable, trust-gated communities actually change how dev groups collaborate — or is platform gravity still too strong?

Comments URL: https://news.ycombinator.com/item?id=47162502

Points: 2

# Comments: 0

Article URL: https://www.baen.com/chapters/W200506/0743499107___2.htm

Comments URL: https://news.ycombinator.com/item?id=47162499

Points: 2

# Comments: 0

Article URL: https://lwn.net/SubscriberLink/1058319/7f10cd1d82956e9f/

Comments URL: https://news.ycombinator.com/item?id=47162496

Points: 2

# Comments: 0

When I first set up OpenClaw, I ran into a big problem immediately.

I spent $250 on my first day doing what felt like harmless testing.

Nothing production. No customers. Just me trying things like:

“Summarize this Slack thread”

“Give me a morning digest”

“Explain this error log”

“Pull action items from the last N messages”

A couple Telegram alerts

At first I blamed OpenClaw. The real issue was simpler: I had Claude set as the default for basically everything, and I accidentally created a workflow where every run got more expensive than the last.

Here’s what actually happened.

“Simple tasks” weren’t simple because the context kept growing I started with “summarize the last 30–50 messages.” Then I kept adding “just one more thing”:

include prior decisions

keep continuity across runs

include relevant earlier context

make it more detailed

That makes results feel smarter, but it turns every request into a bigger prompt. The tricky part is it still feels like the same task, so you don’t notice the cost drift until the number is already big.

Tool output bloat snowballed I let tool outputs flow straight into the next step:

long logs

giant diffs

full API responses

“for debugging” screenshots

Even if one run is tolerable, the next run inherits the baggage. This is how testing quietly becomes a token furnace: output becomes input becomes output again.

Scheduled jobs created an “idle → warm-up tax” loop I had cron-ish jobs that ran, went idle, then ran again.

If your setup effectively re-establishes a big prompt footprint on each run, you keep paying the setup cost repeatedly. It’s not one catastrophic request. It’s lots of medium ones with repeated overhead.

Duplicates from retries/triggers A couple times I saw behavior consistent with “the same expensive work executed twice”:

transient slowdowns causing retries

duplicated triggers from chat integrations

One duplicated summarization run isn’t a rounding error when the prompt is already bloated.

So why did it hit $250 so fast? Because Claude was my default hammer for every nail, and I unintentionally designed the system to feed itself bigger and bigger inputs.

What fixed it (the boring, effective stuff)

- Hard caps on what gets summarized (smaller windows, tighter selection)

- Aggressive trimming of tool output (only keep what the next step truly needs)

- Removed screenshots unless strictly required

- Forced “fresh session” boundaries for scheduled jobs so context can’t grow forever

- Output length ceilings so digests can’t become essays

- De-duped triggers and made retries safer to avoid re-running the same job twice

- And the biggest one: stop using the most expensive model by default for routine steps

The part that pushed me into building something After that first-day bill, the pattern was obvious: relying on discipline (“I’ll remember to switch models later”) doesn’t scale.

Claude was the immediate cost driver, so I took the routing model I’d built for Agentlify and adapted it into a custom routing layer specifically for OpenClaw: cheap/fast models for routine steps, only escalate to Claude when the task actually needs it. That became https://clawpane.co

Not linking anything here. The point isn’t “buy my thing.” The point is that routing stops being an optimization and becomes a seatbelt once you’ve had one day like this.

Takeaway If you’re trialing agent workflows and your bill is spiking, it’s usually not one big request. It’s:

- context creep

- tool payloads piling up

- scheduled runs repeatedly paying warm-up overhead

- occasional duplicates

and an expensive default model doing work that doesn’t require it.

If you want, reply with what tasks you’re running and what your defaults look like. I’ll tell you where the spend usually hides.

Comments URL: https://news.ycombinator.com/item?id=47162495

Points: 2

# Comments: 0

Article URL: https://twitter.com/pberrini/status/2026884672584867986

Comments URL: https://news.ycombinator.com/item?id=47162487

Points: 2

# Comments: 0

I built a system that gives LLMs persistent memory from conversations — not through RAG or databases, but by editing the model's actual weights. The knowledge lives in the parameters. The context window is empty.

During wake, facts from conversation are injected directly into MLP weights via MEMIT (a single forward pass, instant recall). During sleep, the system audits which memories degraded, refreshes them with null-space constraints (guaranteeing orthogonality to working memories), then progressively transfers knowledge into LoRA — like biological memory consolidation from hippocampus to neocortex.

The key problem was a hard capacity ceiling: the 8B model sustains 0.92 recall up to 13 facts, then crashes to 0.57 at fact 14 — a sharp phase transition, not gradual decay. And LoRA consolidation was blocked by what I call the "alignment tax": RLHF training fights back against injected knowledge (37% recall loss on 8B from a single LoRA pass).

The fix: per-fact graduated consolidation. Each fact independently tracks its own stage and advances only when LoRA proves it absorbed that specific fact. A dissolution schedule (1.0 → 0.5 → 0.1 → 0.0) gradually removes the MEMIT edit as LoRA takes over. And cumulative fusing — training each cycle on the already-fused model — reduces the alignment tax from catastrophic to negligible (starting loss drops 2.91 → 0.62 by cycle 2).

Results on Llama 3.1 8B (4-bit, 2×H100): - 100% advancement rate at 5/10/15/20 facts - 1.00 chat recall at all scales - MEMIT edits dissolve on schedule, making the buffer renewable - Effective lifetime capacity: unbounded

There's also a biological curiosity: individual facts consolidate at different rates. One synthetic fact ("Aria lives in Portland") is consistently the hardest across very run — some memories are just harder to absorb, same as in biological systems.

6 papers documenting the full journey from initial LoRA prototype to this result: https://doi.org/10.5281/zenodo.18779159

Built with: Python, PyTorch, PEFT, BitsAndBytes, Llama 3.1. Runs on MacBook Air (3B) or H100 (8B/70B).

Comments URL: https://news.ycombinator.com/item?id=47162473

Points: 2

# Comments: 0

Article URL: https://3nt.lat/

Comments URL: https://news.ycombinator.com/item?id=47162461

Points: 1

# Comments: 0

Article URL: https://www.youtube.com/watch?v=ktFlaBhpMu8

Comments URL: https://news.ycombinator.com/item?id=47162456

Points: 1

# Comments: 0

Article URL: https://date-fns.org/

Comments URL: https://news.ycombinator.com/item?id=47162455

Points: 1

# Comments: 0

VPS pricing is increasing by ~50%, dedicated pricing is increasing by ~10%.

Product Old price New Price

VPS-1 $4.90 $7.60

VPS-2 $7.70 $11.75

VPS-3 $15.00 $23.50

VPS-4 $26.00 $43.50

VPS-5 $40.40 $64.50

VPS-6 $53.40 $86.00

VPSLZ-1 $6.00 $8.50

Comments URL: https://news.ycombinator.com/item?id=47162430

Points: 1

# Comments: 0

Article URL: https://pq-api.cyclecore.ai/try

Comments URL: https://news.ycombinator.com/item?id=47162416

Points: 1

# Comments: 1

Hi HN,

I’ve been experimenting with WebRTC and Rails 8 to see if it's possible to build a messaging utility that is truly "stateless". I wanted to create something for those moments when you need to move a snippet of text or a file between devices without leaving a trace on a server, a database, or a third-party cloud.

The AI Collaboration: I also want to mention that this project has been a deep dive into collaborating with AI. I used AI to brainstorm the "Zero-Trace" architecture, help me harden the infrastructure after a security audit.

How it works:

Zero-Trace Architecture: No accounts, no cookies (beyond basic security), and absolutely no server-side logging. Client-Side Encryption: Encryption keys stay in the URL fragment (#). Since fragments are never sent to the server, the signaling layer is cryptographically blind to your data. P2P Signaling: We use ActionCable for the initial handshake. Once the WebRTC DataChannel is established, the conversation and file transfers happen directly between browsers. Zero Third-Party Dependencies: No external fonts, scripts, or trackers. Everything is served from the origin to prevent IP leakage to third-party providers. The Beta Experiment: I'm currently testing the stability of the P2P signaling. I’ve enabled file transfers (up to 24MB) for everyone during this phase. I’m curious to see how the connection logic handles different network environments.

The Tech Stack:

Framework: Rails 8 Deployment: Kamal 2 on a single VPS I’d love to get your thoughts on the UX and any edge cases you find with the WebRTC handshake!

Comments URL: https://news.ycombinator.com/item?id=47162405

Points: 1

# Comments: 0

Article URL: https://smallake.kr/wp-content/uploads/2019/12/SSRN-id3247865.pdf

Comments URL: https://news.ycombinator.com/item?id=47162391

Points: 1

# Comments: 0

Article URL: https://github.com/raullenchai/vllm-mlx

Comments URL: https://news.ycombinator.com/item?id=47162364

Points: 2

# Comments: 1

Article URL: https://safeenough.substack.com/p/swamp-dirt-and-ai-safety

Comments URL: https://news.ycombinator.com/item?id=47162341

Points: 1

# Comments: 0

Article URL: https://www.frontiersin.org/journals/physiology/articles/10.3389/fphys.2023.1199175/full

Comments URL: https://news.ycombinator.com/item?id=47162331

Points: 2

# Comments: 0

Article URL: https://www.youtube.com/watch?v=aoag03mSuXQ

Comments URL: https://news.ycombinator.com/item?id=47162191

Points: 1

# Comments: 1

Article URL: https://github.com/consigcody94/tesla-lab

Comments URL: https://news.ycombinator.com/item?id=47162188

Points: 1

# Comments: 1