My API keys were in notes, scattered all over. Not the safest place if one ever leaked.
So I built Keysrs, a free Mac menu bar app: keys in the Keychain behind Touch ID, and a live read on where my Claude Code, Codex and Grok tokens go.
My API keys were in notes, scattered all over. Not the safest place if one ever leaked.
So I built Keysrs, a free Mac menu bar app: keys in the Keychain behind Touch ID, and a live read on where my Claude Code, Codex and Grok tokens go.
@mitansh_j07 Thanks! The keys came first. The token read came after, when I wanted to see where my usage was actually going. Which one do you use most, Claude, Codex or Grok?
No account. No logging in to provider sites. Nothing leaves your Mac unless you opt in to anonymous stats, off by default.
I've used it every day for a couple of weeks. It was really fun to build.
Then I wanted to see where my tokens were going. Keysrs reads the files Claude Code, Codex and Grok already write on your Mac and puts the limits in the menu bar: Claude 5-hour and weekly, Codex weekly, Grok weekly. Plus tokens per model per day.
In the video I ask Claude Code for an email lookup with my Hunter key. Touch ID pops up, the result comes back, the key never shows.
For plain HTTP calls there are gateway grants: one key, one host, a scoped path, an expiry. Then the agent asks again.
The part I use most: Claude Code or Codex can use a key without me pasting it into the chat.
keys env hunter-key HUNTER_API_KEY -- <command>
One Touch ID, and the secret goes to that one command only.
It's free and MIT. I thought about charging for it and didn't.
macOS 14+, Apple Silicon. Signed and notarized.
https://t.co/VRb4eErip7
https://t.co/ifyuLrNXJN
Debating on the launch of one of my apps. Should I be the sole proprietor or should I just use the mit license and not worry about liability? Any advice?
We spent the last few days testing JEV internally. We tried to reproduce it, break it, and improve it.
5 things we learned:
1. JEV’s core insight is simple - and probably right. If the answer space is bounded, don’t generate the answer token by token. Remove autoregressive decoding and you can remove 1–2 orders of magnitude of inference work.
2. RLCD isn’t the moat. Data might be. Laya already open-sourced the implementation + weights. The missing piece is the synthetic data recipe. And our experiments strongly point in the same direction.
3. “Open source already beat JEV” is a benchmark illusion.
Same checkpoint:
In-distribution: 0.769
OOD: 0.541
Change the distribution and the apparent breakthrough largely disappears.
4. Compute-optimal ≠ learnability-optimal.
We moved state outside the problem sequence to save compute. Result: -27 points. Likely because we saved FLOPs while throwing away useful MLM pretraining priors.
Then we tested 6 more ideas in one night: anchor selection, continuity smoothing, asymmetric windows, bucketed temperature, two-stage retrieval, full RLCD.
All failed or failed to generalize. Only one thing consistently worked: More data.
1,200 → 123,475 examples
OOD: 0.4069 → 0.5498
5. The weirdest result: A decoder with zero additional training still beat every trained small encoder:
0.5671 vs 0.5628 / 0.5411 / 0.4069
Our takeaway: JEV’s breakthrough may not be a particular architecture or training algorithm.
It may be a much simpler idea: When the answer space is bounded, search it. Don’t generate it. And right now, the biggest bottleneck to making that work broadly doesn’t look like architecture.
It looks like data.
@argofowl think of the users who still use it as a chatbot to answer easy questions why would you waste compute. makes a lot of sense to me. if you know what youre doing you will another model.