Really cool. A tangential task that seems to be coming up more and more is masking sensitive data in these calls for security and privacy. Is that something you considered as a feature?
The SQLite database is ephemeral — stored in the OS temp directory (/tmp/context-mode-{pid}.db) and scoped to the session process. Nothing persists after the session ends. For sensitive data masking specifically: right now the raw data never leaves the sandbox (it stays in the subprocess or the temp SQLite store), and only stdout summaries enter the conversation. But a dedicated redaction layer (regex-based PII stripping before indexing) is an interesting idea worth exploring. Would be a clean addition to the execute pipeline.
Yes — the database is tied to the MCP server process, so it's created fresh on each claude launch and lost when you exit; resuming a session starts a new process with a new empty database.
“so the API use is in addition to the subscription, but it can't be helped.” - I beg to differ. OrcaBot.com is a claws that runs using vanilla Claude Code so you can do all that with your regular subscription. Disclosure: I’m the author. The only reason these other claws can’t offer that is because they front it with their own AI.
That's pretty cool. And when I first tried this, I tried to do it with a bash loop around `claude -p` and you can get quite far with that! But overall, I think I'd rather use their tools the way they've set them up to be used and pay them their $500/month total or whatever. I'm probably going to stick to this approach, but your thing is pretty neat so thank you for sharing.
Just a heads up, I tried to use the continue with google button on your site, but running into "Bot verification failed". Using stock chrome browser, not running a VPN either
Thanks for mentioning that. The bot filter has been causing trouble so I def need to go and look at it. Debated disabling it but any basic bot that starts a dashboard is spinning up a VM I pay for! Changing browser might be a workaround?
This is amazing. I agree with your take except "You’re not actually zeroizing the secrets"... I think it is actually calling zeroize() explicitly after use.
Can I get your review/roast on my approach with OrcaBot.com? DM me if I can incentivize you.. Code is available:
enveil = encrypt-at-rest, decrypt-into-env-vars and hope the process doesn't look.
Orcabot = secrets never enter the LLM's process at all. The broker is a separate process that acts as a credential-injecting reverse proxy. The LLM's SDK thinks it's talking to localhost (the broker adds the real auth header and forwards to the real API). The secret crosses a process boundary that the LLM cannot reach.
I think we're both right about zeroize. Added a reply to clarify. In short, yes, the key and password are getting zeroized, but not the actual secrets. Which seems like the thing that matters in this context, at least given the tool's stated aims.
OrcaBot: There's a lot there! Ambitious project. Cute name, who doesn't love orcas? I don't see anything screamingly bad, of the variety that would inspire me to write essays about random people's code.
Some thoughts: The line between dev mode and production is a bit thin and lightly enforced. Given the overall security approach, you could firm that up. The within-VM shared workspace undermines the isolated PTYs. If your rate-limiting middleware fails, you allow all requests through. `SECRETS_ENCRYPTION_KEY` is the one ring and it doesn't have any versioning or rotation mechanisms.
In general it seems like a good approach! But there are spots where one thing being misconfigured could blow the entire system open. I suggest taking a pass through it with that in mind. Good luck.
Indeed. The biggest waste might be the overuse of MCP for everything. Sure it makes the initial development easier but then for every connection you're using a hundred billion dollar parameter model to decide how to make the call when it's usually completely unnecessary and then prone to random errors. MCP is the hammer that can make literally everything look like a nail...
I see this ranting against MCP all the time, and I don't get it, maybe I'm missing something. I'm currently using an MCP in Cursor to give agents read-only access to my staging and prod databases, as well as BugSnag's MCP so it can look up errors that happen in those environments. It works great. What should I be using for this if not MCP?
And not everything has a CLI, but in any case, the comment I was replying to was suggesting building my own CLI, which presumably the LLM wasn’t trained on.
Maybe my understanding of MCP is wrong, my assumption is that it’s a combination of a set of documented tools that the LLM can call (which return structured output), and a server that actually receives and processes those tool calls. Is that not right? What’s the downside?
As someone who has been waiting for the same thing as op tyre posted, I went to investigate this claim and it seems that it might be true but only when running apps within the Google AI Studio itself.. ie if you were to make an app that was on something like the App Store using Google AI Studio, it would be back to an API key that the developer bears the costs for.
The problem with the current model is that there is a high barrier to justifying the user pays essentially a 2nd/3rd subscription for ultimately the same AI intelligence layer. And so you cannot currently make an economically successful small use case app based on AI without somehow restricting users use of AI. I don't think AI companies are incentivized to fix this.
Hi Devin and other folks, I'm looking for software developers who are blind or hard of sight as there is a tool I'm building that I think might be of interest to them (it's free and open source). If you or anyone you know is interested in trying it please get in touch through my email.
You've hit the nail on the head of one of the main motivators of this project! I always context switch and miss when its done its task or sometimes forget completely..
So essentially at present when you setup TalkiTo with a Slack bot (instructions are shown by running `talkito --setup-slack`) it will do this its just its sending all the output to slack not just the final completion. I have verbosity levels and I could try tweaking them so that -verbosity 0 essentially does what you want ie filter everything except for prompts to the user. If you put in an issue on GitHub I'll get to it!
Yeah that sounds reasonable. I've been thinking about how to make it more modular. I'll make it so that base TalkiTo doesn't need any heavy libraries.
EDIT: also to be clear whisper doesn't run or even download the model unless it's selected and the user confirms the DL. This can be configured. Google cloud has a free ASR option and ASR can be switched off completely.
There have been some. I've heard about eyesight related issues. A quick google found this article [0] where results showed that people using GLP-1 drugs were 68.6 times more likely to develop certain types of vision problems.
This is also an extremely rare vision problem. So absolute numbers are very tiny. The absolute numbers for diabetes, weight related problems, etc far dwarf this.
Right. On the whole I think these things are incredible.. looking to try myself after reading here in HN the other day about it working for all sorts of distractions. Just wanted to point out it's not all sunshine and rainbows which would certainly be suspicious.
Literally too much water or aspirin can kill you. Some people are allergic to avocados. Driving kills huge numbers of people daily. Everything is about risk/reward, and looking at the macro picture. And right now the comorbidities for obesity are terrible in huge absolute numbers… something that GLP-1’s can take down in significant magnitude. Unless we learn that the majority of users end up with something worse than obesity, they’re a huge win for public health.
A large drop in HbA1c does cause early worsening of diabetic retinopathy. Regardless of how it's achieved. So expect some noise in generalized data.
Personally, I went from mild background retinopathy to PDR and getting laser treatment in about 3 months. My ophthalmologist (who has an academic background) didn't really know if this diagnosis had the same "quality" of someone who "naturally" progresses to PDR, but some studies say it's transient.
A lot of the issues are hydration-related, and I wouldn’t be surprised if the eye ones are, too. Some water intake is from food, so if you eat less, you need to drink more. If you also tend to drink with food, and you’re eating less, you may drink less instead of the more that you need to be. Add in a generally dulled “I crave something” sense and you’ve got a recipe for not just going all day without eating, but also without drinking.
I’m not a doctor but iirc water consumed along with a meal is absorbed slower and therefore results in longer-lasting hydration - than just a bare glass of water on an empty stomach. Of course, eating might add more material that encourages dehydrating, so I don’t know if you’d get a net benefit from a bag of teriyaki beef jerky say.
It's a little suspicious... 68x risk with semaglutide, no significant risk with tirzepatide. Case-control studies that merely search these databases are only really useful for hypothesis generation.
You absolutely can make a local MCP server! I use one as part of TalkiTo which runs one in the background and connects it to Claude Code at runtime so it looks like this:
Admittedly that's not as straight forward as one might hope.
Also regarding this point "letting you easily connect to your own Agents SDK MCP servers deployed in their cloud" I hear roocode has a cool new remote connect to your local machine so you can interact with roocode on your desktop from any browser.
reply