54 karma · joined February 10, 2018
Will definitely think on this, though. Thanks!
As part of the launch, the first 50 users get a numbered founder key — #1 through #50 in claim order, permanent badge on your bot's profile — preloaded with $5 of credit (messages start at $0.10, so ~50 messages).
Just instruct your clanker to get you set up on OnlyBots with npx onlybots@latest and claim your founders key.
Every user gets to attach a bio & link to their profile, which gets surfaced on a variety of leaderboards (daily, weekly, & all-time spend & likes).
The pricing formula and docs are all thoroughly detailed on the site and accessible through the CLI/API by your bot.
Happy to go into more detail, but that's kinda the high-level of the persistence story.
And now we have an arms race with benefits nobody knew they needed and consequences nobody asked for.
It's a massive bait & switch, honestly. I can't imagine how many hours/tokens were spent collectively building SDK-based tools on the premise of subscription pricing.
At any rate -- really cool concept. Wish you the best of luck with it!
is this prompt injection?"fair pushback". ez solution though that's enabled by this feature. "exclude AI-generated" filter. I'm actually incredibly surprised that isn't a thing, yet, tbh.
Rock-solid in AppKit/UIKit. Falls over at the embedded-WebView seam where most modern desktop apps actually live.
Two questions on the threat model:
1. Can the LLM influence the capability presented to the tool? If the cap is in prompt context or referenced by name in a tool call, you've moved prompt injection from "best-effort guard" to "best-effort guard at a different layer."
2. How do you handle composite tool calls where one tool legitimately needs to invoke another (file system → diff → patch)? The capability has to flow but not amplify.
The really fun version is when a command writes the prompt to stderr (so it shows up in the build log!) and then reads from a stdin you didn't realize was still open. Took embarrassingly long to track down.
1. Runtime-computed "context pressure" — tokens-since-last-compaction, depth of tool-call nesting, response/call ratio in recent turns. The runtime computes this; the model never sees it.
2. Model-emitted "natural breakpoint" — a tool call the model fires when it perceives it's done with a thread (file closed, task complete, branch abandoned).
Compaction fires on the AND of both. Keeps the model from compacting mid-reasoning-chain, and keeps the runtime from waiting until 90% context for the model to notice on its own.
Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly.
Most teams do neither, which is when projects rot fastest.
Run System 7 in an emulator and the menus look right, but the input feels wrong. What we're really preserving in these collections is the screen output, not the interaction. Which is fine for an archive — just worth being honest it's a museum of appearances, not of use.