congrats on the launch. i'm curious how you think about on device AI vs providers that are in the cloud. where do you see the capabilities of models that can run on the phone, and are there inherent advantages to this?
there's a long tail of edge cases where a smaller model does something dumb with input/output, which causes a decent amount of pain to the user (e.g. nodemon, do we stop/do we start?). Coding agent developers can't make an opinion on every possible terminal command
maybe what we're asking for is that terminal commands keep in mind that agents are now the primary users of them, and have a feeling that new packages or commands could get wider adoption if they are better understood by a coding agent
- similar to SEO for LLMs growing in adoption
- documentation sites offering .md file raw for LLMs to ingest easily
These things will make it so that your packages or libs adopted faster
disabling history on YouTube disables short feeds and recommendations on the home page. It takes 10 seconds and has saved easily thousands of hours and mental sanity.
Also, if you ever want to revisit a video, just use chromes history, but you'll find also this rarely happens if ever.
> Which suggests that there's always some cloud component? How usable is the plugin with fully local setup?
right now requests go directly to your proxy from the plugin if you have it configured (i.e. if you set up a clean VPC/VPN network environment with no outbound requests besides anthropic): both chat, cmdk, and agent will work. We are still working on the DevX for this, but need someone to work closely on this. Enterprise is also pushing us to make this more friendly.
But there are massive downsides, we use some custom models and hosting infrastructure to speed things up. For example, code edits will take much longer.
For fully local LLMs, we just need to setup a unified API client, but there aren't any good kotlin ones and I'm scrambling to write this from scratch. It is very annoying how there are different nuances in the anthropic/openai/etc. and all the "Open source" gateways are cloud hosted. I don't think people will want to "host" a gateway locally, the best experience is to just to put your keys/base url in settings which could be localhost:3000.
It would be helpful to have a setting to disable features that circumvent the configured OpenAI base URL. In its current state, it's not possible to use Firebender without being afraid of accidentally sending out data, right?
That is correct, and is definitely a problem. basically there should be a button that toggles for no code data leaving the network (unless its the proxy you configured). Right now you have to be aware of what features do and don't rely on the proxy which is not a good UX. At the very least there should be modal popup asking for an override or cancel on features that require our custom models.
I can solidify this option with stronger guarantees.
Separately, we're working on Soc II at the moment and should have type 1 soon, and type 2 pending the observation period.
I know trusting my word is difficult bc I'm a random person on the internet, but we do NOT store you code data or use your code data to improve our product in any way (like training models).
reply