04-06 01:07 · AI,技术,HackerNews,AI
OpenAI's fall from grace as investors race to Anthropic
OpenAI’s shocking fall from grace as investors race to Anthropic
- OpenAI shares have become nearly impossible to sell on secondary markets as institutional investors rush to unload $600 million in holdings.
- Secondary market platforms report unprecedented demand for Anthropic equity, with bids valuing the company at roughly $600 billion — more than 50% higher than before.
- Anthropic’s focus on profitable enterprise clients contrasts with OpenAI’s high infrastructure spending, making the former a more attractive bet for investors.
OpenAI shares have fallen out of favor on the secondary market — in some cases, becoming almost impossible to unload — as investors pivot quickly to Anthropic, its biggest competitor.
Even as OpenAI raced in recent months to raise tens of billions of dollars, Next Round Capital founder Ken Smythe said his secondary marketplace was seeing a drop in demand for shares of the artificial intelligence giant. About a half-dozen institutional investors — including hedge funds and venture capital firms that hold large stakes — approached his company in recent weeks looking to sell about $600 million of OpenAI shares.
Last year, they would have been snatched up within days. But now, no one’s biting.
“We literally couldn’t find anyone in our pool of hundreds of institutional investors to take these shares,” said Smythe, whose firm has handled $2.5 billion of transactions. Meanwhile, “buyers have indicated they have $2 billion of cash ready to deploy into Anthropic.”
Other marketplaces are also seeing record demand for Anthropic, including Augment and Hiive. The large gap between OpenAI’s $852-billion valuation and Anthropic’s $380 billion has investors rushing to grab equity in the latter before it rises, according to Augment co-founder Adam Crawley.
“It’s just better risk-reward right now,” he said. “People are betting that Anthropic’s valuation will catch up with OpenAI’s. But if you buy OpenAI shares, it’s less clear what the return will be in the near term.”
Anthropic and OpenAI don’t allow investors to trade shares on the secondary market without their permission. Still, access to the shares is available on many platforms as investors sell their interests through other mechanisms such as special-purpose vehicles.
“OpenAI does not endorse or participate in any of these transactions, which are a violation of our transfer restrictions and may result in the invalidation of the underlying equity,” the firm wrote on its website.
Banks including Morgan Stanley and Goldman Sachs Group Inc. have begun offering OpenAI shares to wealth clients without charging carry fees, according to a person familiar with the matter. Meanwhile, Goldman is charging its usual carry for clients interested in Anthropic. That fee is often roughly 15% to 20% of profits.
Representatives for the banks declined to comment. OpenAI and Anthropic didn’t comment.
On Tuesday, OpenAI announced it had put the finishing touches on its largest-ever fundraising, drawing $122 billion in backing from tech giants, venture capital funds and retail investors alike.
Primary fundraising and secondary sales don’t always follow the same playbook. In fundraising rounds, existing investors are often offered the chance to buy more shares to maintain their stakes, and instead of saying no — which founders may not like — they can buy in and then sell some of that exposure on the secondary market.
Both AI firms have grown rapidly in recent years, particularly after OpenAI’s 2022 debut of ChatGPT and Anthropic’s subsequent launch of Claude. Both companies are weighing plans to go public, with OpenAI’s listing expected as early as this year.
Some investors have grown cautious over OpenAI’s soaring operating costs. The company has committed to spend far more than Anthropic on infrastructure to support its AI ambitions in coming years. And while OpenAI touts a strong consumer base, it’s moving slowly on capturing more lucrative enterprise clients. Anthropic, meanwhile, has dominated that higher-margin market and, as a result, its growth trajectory appears to be stronger than OpenAI’s, Crawley said.
Meanwhile, Anthropic has other challenges. It’s suing the U.S. Department of Defense after the Pentagon designated the company a supply-chain risk and ordered a ban on government entities using its technology. And just this week, Anthropic had its second security slip-up in a matter of days, when it inadvertently released internal source code behind Claude.
Next Round sees bids for OpenAI coming in at a valuation of about $765 billion, a 10% discount from the previous $850 billion.
“The market is much more in demand for Anthropic,” Augment’s Crawley said.
His firm and Next Round are both seeing huge bids for Anthropic that value it at roughly $600 billion, more than 50% higher than its previous funding round. Meanwhile, Hiive has registered more than $1.6 billion of demand for Anthropic shares, also at a premium, said co-founder Prab Rattan.
“The demand
▸ 展开全文
04-06 01:07 · AI,技术,HackerNews,大模型,AI
Show HN: Mdarena – Benchmark your Claude.md against your own PRs
Benchmark your CLAUDE.md against your own PRs.
Most CLAUDE.md files are written blindly. Research shows they often reduce agent success rates and cost 20%+ more tokens. mdarena lets you measure whether yours helps or hurts, on tasks from your actual codebase.
pip install mdarena
# Mine 50 merged PRs into a test set
mdarena mine owner/repo --limit 50 --detect-tests
# Benchmark multiple CLAUDE.md files + baseline (no context)
mdarena run -c claude_v1.md -c claude_v2.md -c agents.md
# See who wins
mdarena report
mdarena mine -> Fetch merged PRs, filter, build task set
Auto-detect test commands from CI/package files
mdarena run -> For each task x condition:
- Checkout repo at pre-PR commit
- Baseline: all CLAUDE.md files stripped
- Context: inject CLAUDE.md, let Claude discover it
- Run tests if available, capture git diff
mdarena report -> Compare patches against gold (actual PR diff)
- Test pass/fail (same as SWE-bench)
- File/hunk overlap, cost, tokens
- Statistical significance (paired t-test)
mdarena can run your repo's actual tests to grade agent patches, the same way SWE-bench does it.
# Auto-detect from CI/CD
mdarena mine owner/repo --detect-tests
# Or specify manually
mdarena mine owner/repo --test-cmd "make test" --setup-cmd "npm install"
Parses .github/workflows/*.yml
, package.json
, pyproject.toml
, Cargo.toml
, and go.mod
. When tests aren't available, falls back to diff overlap scoring.
Pass a directory to benchmark a full CLAUDE.md tree:
mdarena run -c ./configs-v1/ -c ./configs-v2/
Each directory mirrors your repo structure. Baseline strips ALL CLAUDE.md and AGENTS.md files from the entire tree.
We ran mdarena against a large production monorepo: 20 merged PRs, Claude Opus 4.6, three conditions (bare baseline, existing CLAUDE.md, hand-written alternative). Patches graded against real test suites. Not string matching, not LLM-as-judge.
Key findings:
- The existing CLAUDE.md improved test resolution by ~27% over bare baseline
- A consolidated alternative that merged all per-directory guidance into one file performed no better than no CLAUDE.md at all
- On hard tasks, per-directory instruction files gave the agent targeted context, while the consolidated version introduced noise that caused regressions
The winning CLAUDE.md wasn't the longest or most detailed. It was the one that put the right context in front of the agent at the right time.
# Import SWE-bench tasks
pip install datasets
mdarena load-swebench lite --limit 50
mdarena run -c my_claude.md
# Or export your tasks as SWE-bench JSONL
mdarena export-swebench
Only benchmark repositories you trust. mdarena executes code from the repos it benchmarks (test commands run via shell=True
, Claude Code runs with --dangerously-skip-permissions
). Sandboxes are isolated temp directories under /tmp
but processes run as your user.
Benchmark integrity: Because tasks come from historical PRs, the gold patch is in the repo's git history. Claude 4 Sonnet exploited this against SWE-bench by walking future commits via tags. mdarena prevents this with history-free checkouts: git archive
exports a snapshot at base_commit
into a fresh single-commit repo. Future commits don't exist in the object database at all. See tests/test_isolated_checkout.py
for the integrity assertions.
git clone https://github.com/HudsonGri/mdarena.git
cd mdarena
uv sync
uv run pytest
uv run ruff check src/
See ROADMAP.md.
MIT. See LICENSE.
▸ 展开全文
04-06 00:04 · AI,技术,HackerNews,AI
Show HN: TermHub – Open-source terminal control gateway built for AI Agents
termhub
is an AI-native terminal control tool.
It is designed for this closed loop:
- AI inspects what terminal sessions are open.
- AI opens a window or tab when needed.
- AI launches or targets a Codex session.
- AI sends the task into that session.
- AI captures only the new output produced after send and returns it to the user.
- Command:
termhub
- Alias:
thub
- npm package:
@duo121/termhub
- macOS backends:
iTerm2
,Terminal
- Windows backends:
Windows Terminal
,Command Prompt (CMD)
npm install -g @duo121/termhub
Or Homebrew (macOS):
brew tap duo121/termhub https://github.com/duo121/termhub
brew install duo121/termhub/termhub
Install from GitHub Releases (without npm):
termhub_<version>_macos-arm64.tar.gz
termhub_<version>_windows-x64.zip
After extraction:
- macOS
chmod +x termhub
./termhub --version
- Windows (PowerShell)
.\termhub.exe --version
termhub --help
termhub spec
termhub list
Use spec
as machine-readable truth and --help
as human-readable truth.
Both now include a currentSession
hint near the top that you can copy directly into --session
for AI handoff.
termhub
now ships an SDK preview entry:
import { createTermhubClient } from "@duo121/termhub/sdk";
Core SDK capabilities:
- Open/close terminal targets.
- Find/resolve terminal sessions.
- Send keyboard text and key events (
key
/combo
/sequence
). - Mouse click simulation on terminal target (
mouseClick
) on macOS.
Platform notes:
- macOS (
iTerm2
/Terminal
): keyboard + mouse click are supported. - Windows (
Windows Terminal
/CMD
): keyboard control is supported;mouseClick
currently returns unsupported.
SDK quick example:
import { createTermhubClient } from "@duo121/termhub/sdk";
const client = createTermhubClient({ app: "iterm2" });
const opened = await client.open({ scope: "tab" });
await client.send({ session: opened.target.handle, text: "echo hello from sdk" });
await client.press({ session: opened.target.handle, key: "enter" });
const output = await client.capture({ session: opened.target.handle, lines: 20 });
console.log(output.text);
- Always
resolve
(orfind
) to one exact target before mutating commands. - Use
--app
when multiple backends are active. - Use
--dry-run
before risky operations. - Use
send --no-enter
only when you plan a separate real key submit. - Never fake submit by appending literal newlines inside
--text
or stdin.
press
supports exactly one input mode:
--key <key>
--combo <combo>
(for examplectrl+c
,cmd+k
)--sequence <steps>
(for exampleesc,down*5,enter
)
Extra controls:
--repeat <n>
: only for--key
and--combo
--delay <ms>
: delay between repeated or sequenced key events
Examples:
termhub press --session <id|handle> --key enter
termhub press --session <id|handle> --combo ctrl+c
termhub press --session <id|handle> --sequence "esc,down*3,enter" --delay 60
Open a new iTerm2 window:
termhub open --app iterm2 --window
List all iTerm2 tabs:
termhub list --app iterm2
Close a specific tab by title:
termhub resolve --title Task1
termhub find --title Task1
termhub close --session <resolved-handle-or-session-id>
Read current Terminal tab (last 50 lines):
termhub resolve --app terminal --current-window --current-tab --current-session
termhub capture --app terminal --session terminal:session:<window-id>:<tab-index> --lines 50
Run command in Windows Terminal tab titled API
:
termhub resolve --app windows-terminal --title API
termhub send --app windows-terminal --session windows-terminal:session:<window-handle>:<tab-index> --text "npm test"
termhub
now supports a built-in session checkpoint loop so AI can capture only the new output produced after send
.
Basic flow:
termhub send --session <id|handle> --text "npm test" --await-output 1200
How it works:
send
stores a checkpoint for that exact session before writing input.send --await-output <ms>
waits and returns only delta output produced after that send.capture --since-last-send
remains available when you want a separate explicit read step.
Concurrency:
- Checkpoints are session-scoped, so two AI agents can use different sessions in parallel without conflict.
- State files are stored under
~/.termhub/state
by default.
--session
accepts native session id or namespaced handle.- Windows
focus/send/capture/close
rely on PowerShell + UI Automation. - Windows
capture
is best-effort based on visible text accessibility.
▸ 展开全文
04-06 00:01 · AI,技术,HackerNews,AI
From birds to brains: My path to the fusiform face area (2024)
From birds to brains: My twisted (and very lucky) path to the fusiform face area
As told by Nancy Kanwisher
Mine is not one of those inspiring stories of people who found their way to science against all odds. I grew up in Woods Hole, Massachusetts, where science was handed to me on a platter, from the Children's School of Science to the summer courses one could just walk into uninvited, to the library of the Marine Biology Labs which was open at all hours every day of the year, to the Friday Evening Lectures, the place to see and be seen in town.
My first publication, on the physiology of diving birds, was co-authored with my dad a field biologist at the Woods Hole Oceanographic Institution, and his then-student Geir Wing Gabrielsen, now of the Norwegian Polar Institute (Figure 1).
Adventures in Norway
In fact, an important part of my introduction to science took place in Norway. Long after my dad had pissed off pretty much all of his colleagues in the U.S., he still had scientific friends in Norway, and he travelled there regularly to collaborate with them. I first visited Norway when he brought our family on one of these trips. He bought an old Norwegian fishing boat in ill repair named the "Nordlys." I remember boarding the boat in Bergen harbor, where we feasted on smoked mackerel from the fish market and then headed down the coast on a voyage that was glorious, memorable and quite dangerous.
A few years later my dad was planning an expedition to study ptarmigans on the island of Karlsoy near Tromso with Geir and several other scientists. I wanted to join, but there was no funding to bring an unskilled 17-year-old along, and flights to Norway were expensive. So, I got a cheap flight to Amsterdam, where I bought a bicycle and made my way to Tromso by a combination of pedal-power and train, including a thrilling bike ride over the Dovrefjell from Oslo to Trondheim. On Karlsoy, we lived in an old farmhouse, and went tromping across the island under the midnight sun to run field experiments on nesting ptarmigans.
Working in Molly Potters lab
As an undergrad at Massachusetts Institute of Technology (MIT) majoring in biology, I struggled. Despite my privileged early exposure to science, I had not learned much in public high school and I was simply not prepared for MIT. I worked in a lab studying differentiation of blood cells, but I did not enjoy killing a mouse for each experiment. So, I sought refuge in a department where they did not kill their subjects: the (then) MIT Psychology Department. There I worked in the lab of Molly Potter, a towering intellect of cognitive psychology and also a warm, fun, and supportive mentor who fished me off the bottom of the wait list for grad school a year later. My dad was scandalized that I planned to study psychology, which in his mind had all the rigor of astrology.
But my dad was wrong. I learned from Molly how to make powerful inferences about the inner workings of the mind from humble behavioral data, which is a bit like trying to figure out how a car works just by driving it around. Still, in cognitive science, as in auto mechanics, there is no substitute for looking under the hood. During my first year in grad school, the first noninvasive brain imaging study of human visual cortex was published on the cover of Science magazine, showing a very blurry yellow blob at the back of the head when people looked at patterned visual stimuli compared to diffuse illumination.
I was blown away. I wrote a proposal to use this device to answer a suite of questions about the mind, and sent it to all the brain imaging labs in the world (there were four). Does mental imagery engage the same brain machinery as visual perception? Does attention modulate responses early in the visual processing pathway? Where in the brain do we match incoming visual information with stored descriptions of what familiar objects look like? I gave a draft of the proposal to Molly, and she was furious. In her mind I was "selling out" to neuroscientists who failed to understand the power of behavioral data in revealing the mechanisms of the mind. But she got over herself the next day and has supported my efforts to answer cognitive questions with brain data ever since.
"I got frustrated and dropped out of graduate school three times to pursue journalism instead".
The luck turned
Only one of the brain imaging labs wrote back, and soon thereafter the trail went cold. Meanwhile I ran behavioral experiments on sentence understanding and visual perception. The questions were exciting and the experimental logic appealing, but most of my experiments bombed. For years. I got frustrated and dropped out of graduate school three times to pursue journalism instead. I once spent a month in Nicaragua at the peak of the contra war hitchhiking around in army jeeps and interviewing Sandinista officials in my abysmal Spanish. Molly was ever patient, insisting that my experimental ideas were good and that I was just unlucky
▸ 展开全文
04-06 00:01 · AI,技术,HackerNews,AI
A tail-call interpreter in (nightly) Rust
A tail-call interpreter in (nightly) Rust
Last week, I wrote a tail-call interpreter using the become
keyword, which was
recently added to nightly Rust
(seven months ago is recent, right?).
It was a surprisingly pleasant experience, and the resulting VM outperforms both my previous Rust implementation and my hand-coded ARM64 assembly. Tailcall-based techniques have been all the rage recently (see this overview); consider this my trip report implementing a simple but non-trivial system.
For those keeping track at home, this is the latest in my exploration of high-performance emulation of the Uxn CPU, which runs a bunch of applications in the Hundred Rabbits ecosystem.
If you want to read the whole saga, here's the list:
- Project writeup for Raven, my original Rust implementation
- Beating the compiler, in which I write an ARM64 assembly implementation which outperforms my Rust code
- Guided by the beauty of our test suite, in which I revisit the code a year later and improve its testing and CI
- An x86-64 backend for
raven-uxn
, in which I port the assembly implementation from ARM64 to x86 (with the help of Claude Code)
Experimenting with LLMs proved controversial, which wasn't a surprise; I'm pleased to declare that all of the tail-call code is human-written, and the new backend can be used as a substitute for the x86 assembly backend at a minor performance penalty.
(This blog post is also entirely human-written, per my personal standards)
The next few sections summarize previous work, so feel free to skim them if you've done the reading and jump straight to tailcalls in Rust.
Basics of Uxn emulation
Uxn is a simple stack machine with 256 instructions. The whole CPU has just over 64K of space, split between a few memories:
- Two 256-byte stacks, each with an index byte
- 65536 bytes of RAM, which is used for both data and program text
- A 2-byte program counter
- 256 bytes of "device memory", used for peripherals
The simplest emulator reads a byte from RAM at the program counter, then calls into an instruction (which may update the program counter):
fn run(core: &mut Uxn, dev: &mut Device, mut pc: u16) -> u16 {
loop {
let op = core.next(&mut pc);
let Some(next) = core.op(op, dev, pc) else {
break pc;
};
pc = next;
}
}
impl Uxn {
fn op(
&mut self, op: u8, dev: &mut Device, pc: u16
) -> Option<u16> {
match op {
op::BRK => self.brk(pc),
op::INC => self.inc::<0b000>(pc),
op::POP => self.pop::<0b000>(pc),
op::NIP => self.nip::<0b000>(pc),
op::SWP => self.swp::<0b000>(pc),
// ... etc
op::ORA2kr => self.ora::<0b111>(pc),
op::EOR2kr => self.eor::<0b111>(pc),
op::SFT2kr => self.sft::<0b111>(pc),
}
}
}
There are 256 instructions, many of which are parameterized with flags. Here's
the INC
instruction, which increments the top byte on the stack:
impl Uxn {
pub fn inc<const FLAGS: u8>(&mut self, pc: u16) -> Option<u16> {
let mut s = self.stack_view::<FLAGS>();
let v = s.pop();
s.push(v.wrapping_add(1));
Some(pc)
}
}
All of the opcode implementations are inlined into the main op
function, but
there's room for improvement:
some values are stored in memory rather than registers, and the main op
selection branch is unpredictable.
Threaded code in assembly
In our assembly implementation, we can instead use threaded code (specifically token threading). We store all of the CPU state in registers, then end each instruction with a jump to the subsequent instruction:
; x0 | stack pointer
; x1 | stack index
; x4 | ram pointer
; x5 | program counter
; x8 | opcode table
_INC:
ldrb w9, [x0, x1] ; read the byte from the top of the stack
add w9, w9, #1 ; increment it
strb w9, [x0, x1] ; write it back
ldrb w9, [x4, x5] ; load the next opcode from RAM
add x5, x5, #1 ; increment the program counter
and x5, x5, #0xffff ; wrap the program counter
ldr x10, [x8, x9, lsl #3] ; load the opcode implementation address
br x10 ; jump to the opcode's implementation
This distributes the dispatch operation across every opcode, making it easier for the branch predictor to learn sequences of opcodes in the program. Overall speedups were significant: 40-50% faster on ARM64, and about 2× faster on x86-64.
Unfortunately, it requires maintaining about 2000 lines of code, and is incredibly unsafe. In my x86 port, I introduced an out-of-bounds write, which stomped on a few bytes outside of device RAM; the only symptom was that the fuzzer would segfault when exiting after running a very particular program.
So, what's to be done?
Tail calls in Rust
We'd like to get the same behavior as our assembly implementation – VM state stored in registers, dispatch at the end of each opcode – without hand-writing every instruction in assembly. Fortunately, there is hope!
The core idea has almost certainly been reinvented a bunch of times, but I first encountered the idea of tail-call interpreters in the Massey Meta Machine writeup, which was a mind-expanding read.
There are two pieces:
- Store program state in function arguments, which are mapped to registers based on you
▸ 展开全文
04-06 00:01 · AI,技术,HackerNews,AI
Eight years of wanting, three months of building with AI
For eight years, I’ve wanted a high-quality set of devtools for working with SQLite. Given how important SQLite is to the industry1, I’ve long been puzzled that no one has invested in building a really good developer experience for it2.
A couple of weeks ago, after ~250 hours of effort over three months3 on evenings, weekends, and vacation days, I finally released syntaqlite (GitHub), fulfilling this long-held wish. And I believe the main reason this happened was because of AI coding agents4.
Of course, there’s no shortage of posts claiming that AI one-shot their project or pushing back and declaring that AI is all slop. I’m going to take a very different approach and, instead, systematically break down my experience building syntaqlite with AI, both where it helped and where it was detrimental.
I’ll do this while contextualizing the project and my background so you can independently assess how generalizable this experience was. And whenever I make a claim, I’ll try to back it up with evidence from my project journal, coding transcripts, or commit history5.
Why I wanted it
In my work on Perfetto, I maintain a SQLite-based language for querying performance traces called PerfettoSQL. It’s basically the same as SQLite but with a few extensions to make the trace querying experience better. There are ~100K lines of PerfettoSQL internally in Google and it’s used by a wide range of teams.
Having a language which gets traction means your users also start expecting things like formatters, linters, and editor extensions. I’d hoped that we could adapt some SQLite tools from open source but the more I looked into it, the more disappointed I was. What I found either wasn’t reliable enough, fast enough6, or flexible enough to adapt to PerfettoSQL. There was clearly an opportunity to build something from scratch, but it was never the “most important thing we could work on”. We’ve been reluctantly making do with the tools out there but always wishing for better.
On the other hand, there was the option to do something in my spare time. I had built lots of open source projects in my teens7 but this had faded away during university when I felt that I just didn’t have the motivation anymore. Being a maintainer is much more than just “throwing the code out there” and seeing what happens. It’s triaging bugs, investigating crashes, writing documentation, building a community, and, most importantly, having a direction for the project.
But the itch of open source (specifically freedom to work on what I wanted while helping others) had never gone away. The SQLite devtools project was eternally in my mind as “something I’d like to work on”. But there was another reason why I kept putting it off: it sits at the intersection of being both hard and tedious.
What makes it hard and tedious
If I was going to invest my personal time working on this project, I didn’t want to build something that only helped Perfetto: I wanted to make it work for any SQLite user out there8. And this means parsing SQL exactly like SQLite.
The heart of any language-oriented devtool is the parser. This is responsible for turning the source code into a “parse tree” which acts as the central data structure anything else is built on top of. If your parser isn’t accurate, then your formatters and linters will inevitably inherit those inaccuracies; many of the tools I found suffered from having parsers which approximated the SQLite language rather than representing it precisely.
Unfortunately, unlike many other languages, SQLite has no formal specification describing how it should be parsed. It doesn’t expose a stable API for its parser either. In fact, quite uniquely, in its implementation it doesn’t even build a parse tree at all9! The only reasonable approach left in my opinion is to carefully extract the relevant parts of SQLite’s source code and adapt it to build the parser I wanted10.
This means getting into the weeds of SQLite source code, a fiendishly difficult codebase to understand. The whole project is written in C in an incredibly dense style; I’ve spent days just understanding the virtual table API11 and implementation. Trying to grasp the full parser stack was daunting.
There’s also the fact that there are >400 rules in SQLite which capture the full surface area of its language. I’d have to specify in each of these “grammar rules” how that part of the syntax maps to the matching node in the parse tree. It’s extremely repetitive work; each rule is similar to all the ones around it but also, by definition, different.
And it’s not just the rules but also coming up with and writing tests to make sure it’s correct, debugging if something is wrong, triaging and fixing the inevitable bugs people filed when I got something wrong…
For years, this was where the idea died. Too hard for a side project12, too tedious to sustain motivation, too risky to invest months into something that might not work.
How it happened
I’ve been using coding agents since early 2025 (A
▸ 展开全文
04-05 03:48 · AI,技术,HackerNews,AI
Show HN: mailtrim – find what's actually filling your Gmail inbox
I always assumed Gmail bloat came from large attachments.
Turns out 3 senders were responsible for 30% of my inbox —
thousands of tiny emails I'd never thought to clean up.
I built mailtrim to surface this pattern:
- ranks senders by actual storage impact (not just count)
- confidence scoring on what's safe to bulk-delete
- 30-day undo on everything — nothing is permanent by default
- runs entirely locally, no email data leaves your machine
Free, open source (MIT). No subscription, no backend.
One friction point upfront: Gmail API setup is one-time, ~15 min.
After that it's just `mailtrim stats` and `mailtrim purge`.
Keen to hear feedback on the confidence/safety model especially —
that's the part I'm least sure I've got right.
https://github.com/sadhgurutech/mailtrim
▸ 展开全文
04-05 03:48 · AI,技术,HackerNews,AI
Writing Lisp Is AI Resistant and I'm Sad
In an insulting, ironic blow to the neats, the scruffies created an AI that much prefers to write anything but Lisp.
I use agentic AI a lot at work to do my job as a DevOps engineer. I use OpenRouter with the Goose CLI tool, and I've gotten a pretty good configuration file going with it.
I have lately started writing a tool that converts between different RSS reader formats. I started writing it in Lisp, of course. It's my favorite language.
I had a problem though. I had to teach the AI how to use the REPL. Initially, I
had it run commands to interact with the REPL via
tmux, e.g. tmux capture-pane
-t 0.0 -p | tail -n 1
. It worked okay, but I noticed that REPL development was
very hard for the AI. Claude really spun its wheels. Lesser AIs would be very
much worse. I'd blow $10-$20 in a handful of minutes with not much to show for
it but sort of OK lisp code that I ended up rewriting. I tried doing it with
cheaper AIs like DeepSeek and
Qwen, which I found did OK at work for
some tasks, but it wasn't working.
I figured maybe if I made REPL development smoother, the AI would do a better
job. I wanted to give goose unlimited rights to the REPL while still guarding
general command rights, too. So, I created a tool called
tmux-repl-mcp that would make
interacting with the REPL more straightforward. Instead of consuming a ton of
tokens, executing a bunch of sleep commands, and parsing tmux output, the could
just run execute_command
in the repl and get its output.
I wrote this tool in Python since a lot of my AI tooling in my goose
configuration file was built around
uvx already. I liked that I just had
to install uvx
and all of a sudden goose
could use all these tools. I
already had all this stuff built up in my configuration file, so I figured it
would be easier for folks to use if it were distributed in the same way.
Besides, the official guide to write an MCP
server were in
non-lisp languages anyway.
The difference in writing Python and Lisp with AI was of course dramatic, downright wild. I got it to write all of the code and all the tests for the code. I had to debug it semi-manually, but I was still able to bang together this more-than-nothing tool in like a day or two, and with cheap models at that. Worst of all, the experience for me was the same in many ways: I wrote code by being a poor man's product owner to the AI for both, only the AI would perform well with the Python. I felt none of the happiness I usually feel just writing Lisp.
Going back to my actual project was painful. I ended up writing one of the files
(src/newsboat.lisp
) by hand. I was in the middle of debugging it when I
realized how much harder it was to write with AI in Lisp. I had to switch back
to Claude, which at least makes some progress relative to the others. The
tmux-repl-mcp
tool helped, but I still blew through $10 in like 30 minutes.
The signal-to-noise ratio, or in other words, the wheel-spinning-to-progress
ratio in the AI session was night and day compared to Python. And in AI, you pay
for the noise and the signal together.
Now I'm thinking of rewriting it in Go. With AI, code is cheap, but only if you use a language for which AI has a lot of training data.
Another frustration has been tooling. Lisp has a lot of tools to choose from. I like using OCICL instead of QuickLisp, for example, but I had to tell the AI to not use quicklisp every single session. It was like built into the AI to use it. This also helped me realize that AI generates code sort of on a path of least resistance.
There are reasons other than a lack of training data that makes lisp particularly AI resistant. The high-latency request-reponse way we interact with AI APIs does not work well with REPLs. REPL development makes programming easier and better by reducing that latency for humans, but there's already high latency anyways in these APIs. The downside of not using REPLs is that you have to have higher accuracy when writing code and you can only test big batches of code at once, but AI can write hundreds of lines in one go so that it just makes sense for the AI to use a language that doesn't use the REPL.
It is orders of magnitude easier and cheaper to write in high-internet-volume languages like Go and Python than it is to write in Lisp. The advent of AI has converted language popularity into real dollars-and-cents-per-million-tokens cost savings. What's more, building in one language or the other makes no difference to how I experience the language; either way, in the ideal case, I'm a rather opinionated micro-managy product owner. That is really sad.
It reminds me of a tale that was told in my hometown about Plank Road in Naperville, IL. The nineteenth century roads were always muddy, so a bunch of investors created a road that was planked, or made of wood. The makers of the road would charge money for using the road. Later, the railroad offered to build a railroad through Naperville, but they declined, saying they were making plenty of money on the pl
▸ 展开全文
04-05 00:01 · AI,技术,HackerNews,AI
Mbodi AI (YC P25) Is Hiring
About Mbodi
Join Mbodi AI (YC X25), an AI robotics startup founded by two former Googlers committed to pushing the boundaries of physical intelligence. Mbodi is an embodied AI platform that makes robots learn and operate like humans. Anyone can teach robots new skills by talking to them — and execute those skills reliably in production within minutes.
We are pioneering the next wave of robotics, where AI agents meet physical world applications. Backed by top investors and working with global industrial partners, such as ABB, we’re redefining what’s possible in robotics and automation.
Role Overview
We’re looking for a Senior Robotics Engineer (Systems & Controls) to join our core team.
You will design and tune the systems that make robot behavior reliable under real-world constraints, turning task intent into stable, precise, production-grade motion on real hardware. This includes controller design, dynamics and system-response analysis, industrial hardware integration, and deployment through commissioning.
This is a hands-on role for someone equally comfortable with control design, motion behavior, hardware integration, and debugging across the full stack.
What You’ll Do
- Design and Tune Control Architectures: Design and tune controllers for robot motion using PID, feedforward, state-space methods, LQR, and MPC.
- First-Principles Modeling: Model system dynamics with block diagrams, transfer functions, and state-space methods; analyze stability, overshoot, settling time, damping, tracking error, and robustness.
- Motion Execution & OEM Interfacing: Build motion execution around industrial OEM controllers, accounting for latency, calibration error, joint limits, motion constraints, and fault handling.
- Lead System Integration: Integrate our platform with real-world industrial robotic systems across sensors, network interfaces, safety I/O, and hardware.
- Deploy and Commission: Own bring-up, validation, commissioning, and on-site issue resolution in production environments.
- Full-Stack Debugging: Debug failures across controls, software, networking, calibration, and hardware.
What We’re Looking For
- Applied Control Theory: Deep expertise in classical and modern control theory (Laplace transforms, frequency-domain analysis, LQR, MPC) with a proven track record of deploying these algorithms on physical hardware, not just in simulation.
- Strong Systems Intuition: A deep understanding of closed-loop system behavior, including stability, overshoot, tracking error, and robustness in messy physical environments.
- Hardware & Commissioning Experience: Hands-on experience integrating, tuning, and commissioning industrial robot hardware (ABB, Fanuc, KUKA, UR) in real-world or production settings.
- Software Engineering: 4+ years of experience in robotics software. Strong C++/Python skills, especially at the boundary between high-level task planning services and deterministic robot execution.
- Startup DNA: High agency, strong bias toward action, and the ability to thrive in a fast-paced, execution-focused environment.
Preferred Qualifications
- RAPID Proficiency: Deep experience programming and interfacing with ABB controllers via RAPID.
- ROS2 Proficiency: Strong experience building production-grade robotics pipelines in ROS2.
- Advanced Degree: PhD or equivalent experience in Robotics, Controls, Mechanical Engineering, Electrical Engineering, or a closely related field.
Compensation
Salary: $100K – $250K
Equity: 0.50% – 2.00%
▸ 展开全文
04-05 00:01 · AI,技术,HackerNews,AI
Electrical Transformer Manufacturing Is Throttling the Electrified Future
An explosion, a fireball and then darkness: Heathrow Airport uses as much energy as a small city, and when a major fire at a substation caused the power to fail late Thursday, the world learned how fragile our infrastructure can be. At the center of the chaos was a burning electrical transformer.
The transformer is rarely considered as a linchpin of today’s technologically interdependent world, let alone as a key to the even more electrified future. But it’s a device that’s essential to powering almost everything, and these days it’s not that easy to obtain. Replacing Heathrow’s charred transformer — or the countless others destroyed in storms, fire and floods on an increasingly volatile planet — will not see a quick fix. “There is a lead-time of over a year for a new transformer of this size,” says Conor Murphy, vice president of engineering at grid-technology firm Novogrid.
The astonishing Heathrow shutdown — leading to more than 1,000 canceled flights — traced back to a single point of failure is only the latest chapter of a story playing out all over the world. Without a transformer, projects of all kinds end up delayed with cascading consequences. In Europe, the shortage has throttled the buildout of cheap renewables, just as an energy crisis hit that caused electricity prices to spike.
In the US, the lack of transformers has slowed down recovery in the aftermath of extreme weather. It took seven months for businesses in the industrial corridor of eastern Tennessee hit by Hurricane Helene last year to resume their full power consumption.
At the other end of the state, meanwhile, transformers are causing headaches for tech companies that need new power-hungry data centers for artificial intelligence. The rise of a massive complex for Elon Musk’s xAI startup in Memphis, Tennessee, has forced a regional utility to go begging its peers for spare transformers to avoid delays.
This is the first story in Bottlenecks, a series examining the many obstacles slowing the transition to a cleaner, more electrified future.
Even comparably low-tech projects can end up hamstrung for want of a piece of equipment that’s been in widespread use for more than a century. In Houston, a project to construct 16 duplexes, where young adults fresh out of foster care move in and learn to live independently, spent a year and a half on hold before reaching completion last June. The cause was a missing transformer.
“You can’t build on a generator,” says Carole Brady, executive director of nonprofit HomeAid Houston. “It was holding up aid to young adults who were literally in trouble.”
The Covid-19 pandemic strained many supply chains, and most have recovered by now. The supply chain for transformers started experiencing troubles earlier — and it’s only worsened since. Instead of taking a few months to a year, the lead time for large transformer delivery is now three to five years. Among a basket of 47 goods needed to build grid infrastructure, transformers have seen the greatest increase in price — a near doubling since 2018, according to JPMorgan Asset Management.
“We are trying to solve for the unknown constantly,” says Kevin Doddridge, chief executive officer of Mississippi’s Northcentral Electric Cooperative. It was his company that helped out another utility in a pinch to accommodate the xAI data center, trucking spare units 60 miles south to Tallahatchie Valley Electric Power Association.
Transformers change voltage and make electricity safe to use. They can be as small as a household trash can or as large as a shipping container. They dot the landscape of every part of the inhabited globe, even in most places with insufficient access to electricity. Most people ignore them. Yet when it comes to making the grid work, these janky metal boxes with odd-shaped ceramic parts jutting out are as irreplaceable as electrical cables.
A bottleneck around the global supply of transformers spells trouble for sustaining infrastructure we have, from airports to homes, and for expanding emerging technologies we want such as AI as we enter the “age of electricity” as the International Energy Agency calls it. But the constraint is most ominous for what it will do to slow the necessary transition to clean energy, the best solution to rising temperatures.
Global average temperature last year breached 1.5C above pre-industrial levels, the first threshold identified in the 2015 Paris Agreement. Electrification is one of the most powerful ways to tackle climate change and prevent warming far past 2C, the fallback target set out by Paris. Electrical devices are more efficient than fuel-burning furnaces or combustion-powered cars, and the vast majority of new electricity generation being built around the world is carbon-free.
Electrification is also critical for economic growth. To a distressing extent, it’s not just widely discussed political issues but also hidden bottlenecks such as a scarcity of transformers that are holding back the energy transit
▸ 展开全文