technoabsurdist6 days ago
Congrats on the launch! Big fan of Continue <3
At Continue, we've always believed that developers should be amplified, not automated. A key aspect of this philosophy is providing choices that let you customize your AI code assistant to fit your specific needs, workflows, and preferences.
The AI-native development landscape constantly evolves with new models, MCP servers, assistant rules, etc. emerging daily. Continue's open architecture connects this ecosystem, ensuring your custom code assistants always leverage the best available resources rather than locking you into yesterday's technology.
The Continue Hub makes it even easier to customize with a registry for defining, managing, and sharing building blocks (e.g. models, rules, MCP servers, etc). These building blocks can be combined into custom AI code assistants, which you can use with our open-source VS Code and JetBrains extensions (https://github.com/continuedev/continue).
Here are a few examples of different custom AI code assistants that we’ve built to show how it works:
A custom assistant that specializes in helping with data load tool (dlt) using their MCP: https://www.loom.com/share/baf843d860f44a91b8c580063fcfbf4a?...
A custom assistant that specializes in helping with Dioxus using only models from Mistral: https://www.loom.com/share/87583774753045b1b3c12327e662ea38?...
A custom assistant that specializes in helping with LanceDB using the best LLMs from any vendor via their public APIs (Anthropic, Voyage AI, etc): https://www.loom.com/share/3059a35f8b6f436699ab9c1d1421fc8d?...
Over the last 18+ months since our Show HN, our community has rapidly grown to 25k+ GitHub stars, 12.5k+ Discord members, and hundreds of thousands of users. This happened because developers want to understand how their tools work, figure out how to better use them, and shape them to fit their development practices / environments. Continue does not constrain their creativity like the vertically integrated, proprietary black box AI code assistants that lack transparency and offer limited customizability.
Before Continue Hub, developers faced specific technical challenges when building custom AI assistants. They manually maintained separate configuration files for different models, wrestled with breaking API changes from providers, and built redundant context retrieval systems from scratch. We've seen teams spend weeks setting up systems that should take hours. Many developers abandoned the effort entirely, finding it impossible to keep up with the rapidly evolving ecosystem of models and tools.
Our open-source IDE extensions now read a standardized configuration format that fully specifies an AI code assistant's capabilities—from models and context providers to prompts and rules. Continue Hub hosts these configurations, syncs them with your IDE, and adds versioning, permissions, and sharing. Assistants are composed of atomic "blocks" that use a common yaml format, all managed through our registry with both free solo and paid team plans.
We're releasing Continue 1.0 today, which includes both Continue Hub and the first major release of our Apache 2.0 licensed VS Code and JetBrains extensions. While the Hub currently only supports our IDE extensions, we've designed the underlying architecture to support other tools in the future (https://blog.continue.dev/continue-1-0). The config format is intentionally tool-agnostic—if you're interested in integrating with it or have ideas for improvement, we'd love to hear your thoughts!
Even within the subset of developers that use C or OCaml, there are likely to be a large variety of best practices, codebase layouts, and internal knowledge—these are the things we want to empower folks to codify
Should now be able to remix PyTorch rules for example: https://hub.continue.dev/starter/pytorch-rules/remix
And in some cases not just "better", but if you hook up custom tools then your assistant can do entirely new things!
I certainly feel that running them locally isn't the end state, curious if others have started to feel pains there yet?
But I wouldn't want to have a third party host where, all they're doing is just running the npx/uvx command themselves and I still have to give them keys, etc.
At that point, I'd rather just host them locally.
The current system of generating keys and setting custom permissions will leave room for error.
Basically knowledge packs could be specified in each npm package.json or similar.
And we should view a knowledge pack as just a cache in a way. Because agents these days are capable of discovering that knowledge themselves, via web browsing and running tests, it is just costly to do so on every agent run or for every library they don't know.
I sort of view specialized agents as akin to micro services, great if you have perfect domain decomposition, but likely to introduce artificial barriers and become inconvenient as the problem domain shifts from the original decomposition design.
I guess I should write this up as blogpost or something similar.
EDIT: Newly written blog post here: https://benhouston3d.com/blog/crafting-readmes-for-ai
A situation to think about: if I were to write a rule that said "I am using Tailwind CSS for styling", then this is actually information that can't be just known. It's not "common knowledge", but instead "preference" or "personal knowledge". I do think it's a fair response to say "can't it just read my package.json"? Probably this works in a handful of cases, but I've come to find that even so there are a few benefits to custom rules that I expect to hold true regardless of LLM progress: - It's more efficient to read a rule than to call a tool to read package.json on every request - Especially in large enterprise codebases, the majority of knowledge is highly implicit (oftentimes in detrimental ways, but so the world works)
But yeah this is a majorly important and interesting question in my mind. What types of customization will last, and which won't? A blog post would be amazing
Can you please share what are your favourite tools and for what exactly? Would be helpful
I've been using Cline a lot with the PLAN + ACT modes and Cursor for the Inline Edits but I've noticed that for anything much larger than Claude 3.7's context window things get less reliable and it's not worth it anymore.
Have you found a way to share knowledge packs? Any conventions? How do you manage chat histories / old tasks and do you create documentation from it for future work?
I wrote my own open source one here: https://github.com/drivecore/mycoder. Covered on hacker news here: https://news.ycombinator.com/item?id=43177117
I've also studied coding with it and wrote a lot about my findings here:
- https://benhouston3d.com/blog/lean-into-agentic-coding-mistakes
- https://benhouston3d.com/blog/building-an-agentic-code-from-scratch
- https://benhouston3d.com/blog/agentic-coder-automation
- https://news.ycombinator.com/item?id=43177117
- https://benhouston3d.com/blog/the-rise-of-test-theater
My findings are generally that agentic coders are relatively interchangeable and the reason they work is primarily because of the LLM's intelligence and that is a result of the training they are undergoing on agentic coding tasks. I think that both LLMs and agentic coding tools are converging quite quickly in terms of capabilities.
> Have you found a way to share knowledge packs? Any conventions? How do you manage chat histories / old tasks and do you create documentation from it for future work?
I've run into this wall as well. I am working on it right now. :) Here is a hint of the direction I am exploring:
https://benhouston3d.com/blog/ephemeral-software-in-the-era-of-ai
But using Github as external memory is a near term solution:
https://benhouston3d.com/blog/github-mode-for-agentic-coding
It would be great to run local models at the same level one day. I am sure that Claude is making your wallet feel quite light :)
https://benhouston3d.com/blog/building-an-agentic-code-from-scratch
I'm particularly fascinated by those last two links, along with your latest post about READMEs. It makes me wonder about a visual specification editor that provides GitHub-like task chronology around the spec, with the code as a secondary artefact (in contrast to GitHub, where code is primary).
BTW I'm working on ideas to make code a secondary artifact right now, sort of v2 of mycoder.
Fantastic!
Agentic task-offloading is already here; it is just unevenly distributed.
> Basically knowledge packs should be specified in each npm package.json or similar.
Our YAML-based file format for assistants (https://docs.continue.dev/reference) is hoping to do just this by allowing you "import knowledge packs".
Does it need to be decoupled from package.json, etc.? One of the most interesting reasons we decided not to go that route was it can be cumbersome for all of your many dependencies to taken into account at once. Another is the question of how the ecosystem will evolve. I definitely think that each package author should take the time to encode the rules and best practices of using their library, however it might be difficult for community to help out if this is gated by getting in a pull request.
At the same time, one of the soon-to-be-released features we are working on is the ability to auto-generate or suggest rules (based on package.json, etc.).
Knowledge packs should be decoupled from package.json just as eslint rules or commit-lint rules are. You can include them in package.json or in separate files. But including pointers to the main files in a package.json helps with discovery.
All packages across all languages should support AI friendly knowledge packages so a level of decoupling is required.
EDIT: After thinking about it I think README.md should just be written with Agentic Coders in mind. I wrote up my thoughts on that here: https://benhouston3d.com/blog/crafting-readmes-for-ai
> consider letting the LLM write it's own "Readme" for a package on the hub be scanning source/types of the package
This is something we're looking to ship soon
A lot of the benefits of rules are completely unique to your situation and the definition of “better” is likely to differ between people. I think the videos above are the best way I currently have to display this.
There are potential solutions though to measure improvement, and we actually made it possible for you to obtain the necessary data. If you add a “data” block to your custom assistant you can capture all of the accept/reject, thumbs up/down, etc. data and use it to do an analysis. We definitely will be working more in that direction
We'd actually love for them to take part in the standard we're building here—the more people build custom assistants together, the stronger the ecosystem can grow!
If I were to share any one reason why we continue to build Continue when there are so many other coding assistants, it really comes down to one word: choice. We hope to live in a world where developers can build custom prompts, rules, tools, etc. just like we currently build our own bash profiles, Vim shortcuts, and other personal or internal company tools. Lots of room and lots of space for many products, but we want to lead the way on allowing developer choice over models, prompts, and much, much more
I'd love it if you lean into pooled model usage, rather than it being an addon. IMO it is the biggest win for Cursor usage - a reasonable num of LLM calls per month, so I never have to do token math or fiddle with api keys. Of course, it is available as a feature already (I'm gonna try Continue) but the difference in response time b/w Cursor and Github copilot (who don't seem to care) is drastic.
Our Models Add-On is intended to give the same flat monthly fee as you’re accustomed to with other products. What did you mean by leaning into pooled, just making it more front-and-center?
An addon makes it seem like an afterthought, which I'm certain you are not going for! But still making is as seamless as possible would be great. For ex, response time for Claude in Cursor is much better than even the Claude web app for me.
It's basically VSCode - I just ported all extensions in Cursor settings, it installed existing VSCode extensions including Pylance and it just works...
This also allows developers to switch between projects quickly while simultaneously also switching the setup for the AI agent.
One interesting note is that rather than a pivot, the hub was just a continuation of work we'd already been doing—we had a configuration file that tons of people were customizing, but it was just a bit too complicated to get started, so we decided to make that "1 click" easy with the hub
In the long run, we feel that it's not the "features" in the IDE that will separate different AI coding tools (most are a matter of building out new UI), but that the ecosystem will be one of the biggest differentiators
Maybe you're right about the confusion...but given the velocity, that's going to be fixed also.
All the knowledge about the field of programming is digitized, one could argue that having a model that digested all that information in a right way, is better than separate.
Just a thought. I don't care all that much.
For users that end up benefitting from rules, it's typically because of encoding "personal knowledge" or "preferences". When building small side projects from scratch, this typically matters much less: you probably want it to "just work" using the canonical tech stack. Pretty quickly though projects end up with a lot of implicit knowledge and idiosyncratic practices that are great candidates for custom rules!
I guess you guys have some MCP connections too, but this seems like such a marginal value add (how often am I really pinging these services and do I really want an agent doing that).
Regardless congrats on the launch.
- https://hub.continue.dev/continuedev/playwright-e2e-test
- https://hub.continue.dev/continuedev/vscode
- https://hub.continue.dev/continuedev/service-test-prompt
Importantly, you don't have to pay to use custom assistants! You can think of hub.continue.dev like the NPM registry: it's just a medium for people to create, share, and pull the assistants they want to use. It's always possible to bring your own API key and we provide a Models Add-On mostly for convenience of not needing to keep track of API keys
Value prop of MCP is definitely early, but I would recommend giving Agent mode (https://docs.continue.dev/agent/how-to-use-it) a try if you haven't had the chance—there's something compelling about having the model take the obvious actions for you (though you can of course require approval first!)
- Mediocre knowledge of Erlang/Elixir
- Reluctance to use the new rune feature in Svelte 5
It sounds like I'd be able to point my local LLM to the official docs for Erlang, Elixir, Phoenix, and all the dependencies in my project. And same for Svelte 5.
Also might be interesting to take a look at these Phoenix rules that someone built: https://hub.continue.dev/peter-mueller/phoenix-rules
It's too large to be a Cursor rule though. But, if you dump it into Google Gemini (which is phenomenal at large context windows) it will write you a solid condensed version.
But Cursor has been much better with suggestions for elixir codebases.
Probably still not as good as JS/Python but way way way better than Copilot.
I don't claim that we're perfect and would love to hear how we can improve if you have the chance to give it a try
- Models like Relace's Instant Apply (https://hub.continue.dev/relace/instant-apply)
- Codebase context services like Greptile (https://hub.continue.dev/continuedev/greptile-context)
- MCP servers for services like Exa (https://hub.continue.dev/exa/exa-mcp)
Also cool that one can easily select different models for different modes.
Is there a competitor extension with similar offerings?
1. The Bitter Lesson extends to test-time compute (some call this the "Bitter-er Lesson" https://yellow-apartment-148.notion.site/AI-Search-The-Bitter-er-Lesson-44c11acd27294f4495c3de778cd09c8d), and we've bet that agentic LLMs will become a major transformation in how software is built. Agent mode (https://docs.continue.dev/agent/how-to-use-it) is here to stay. This means that models are going to take very extended action for you. It could be 1, 15, 60, or more minutes of work at a time without requiring interjection. As these trajectories become longer it becomes _more_, not less, important to give the model the correct initial conditions. This is the role of rules and prompts.
2. Cheap inference matters and the trend in frontier models (for those watching) is distillation, not increased parameter count. There's great reason to believe that we're headed toward a future where a few billion parameter model can contain all of the reasoning circuits necessary to solve difficult problems and that when combined with a massive context window will become the "engine" in every AI tool. The difficult part is obtaining that context, and if you watch the actions of people who work at companies, a large majority of their time is spent on reading, writing, sharing the right context with each other.
3. My co-founder Ty wrote a piece 2 years ago describing the path where language models automate increasing amounts of software and we use live coding interaction data to make them even better, in a positive feedback loop of automation: https://blog.continue.dev/its-time-to-collect-data-on-how-you-build-software/. If you believe in this future, then you're going to want to collect your own data to post-train (e.g. https://arxiv.org/pdf/2502.18449v1) rather than letting another tool absorb all of the intellectual property without giving it back. They aren't going to train a model that knows the private details of every company's workflows, they will train on a distribution that helps primarily with the most basic tech stacks.
4. No matter how many parameters a foundation model has, there's no way for it to know in the weights that "We (at some particular team within some larger company) organize our unit tests into separate files for selectors, actions, and tests" (e.g. https://hub.continue.dev/continuedev/playwright-e2e-test). This is purely team knowledge and preference, and is often private data. The next thought in the chain here is "can't it just use tools to inspect the repository and find this out?". And the answer is absolutely, but that quickly gets expensive, slow, annoying. And you're going to end up writing a rule to save both money and time. Next: can't the model just write the rules for me? Again, absolutely! We're working on this. And to us the natural outcome of this is that the model writes the rules and you want to share this potentially expensive "indexing" step with your team or the world.
5. Probably the most obvious, but worth saying: advanced language models will use tools much more. Hooking up the right MCP is a non-negotiable part of getting out of the way so they can do their work.
You could start here by adding a new block for docs: https://hub.continue.dev/new?type=block&blockType=docs
I think it would be great to have one on the front page as well if there's something you find works really well. The nice thing about assistants is that a lot of the work is just browsing and clicking to add the blocks you want, and then when you really end up going deeper to customize the rules, this is just writing plain english!
I don't believe Cursor has added support for assistant files (https://docs.continue.dev/reference) yet, but think it would be great if they did! We've designed the format to be totally client agnostic and hopefully to be a simple, portable way to share assistants across any tool
These are the two cases where Claude 3.7/windsurf shits in my bed. :(
But my problem with Continue has been the lack of stability. I'll often bounce from one tool to another, so I might not use it for a couple weeks. Almost every time I come back to it, the extension is broken in some way. I've reinstalled it many many times. I kinda gave up on it and stuck with Cody, even though I like the feature set of Continue better. (Cody eventually broke on me, too, but that's another can of worms.)
Is the Continue team aware of this stability issue and are you planning on focusing on that more now that you've launched? It seems like you've been moving fast and breaking things, which makes sense for a while, but I can't hitch my wagon to something that's going to break on me.
I tried to use it one day and was confronted by a cryptic auth error. It looked like a raw HTML error page but it was rendering in the side panel as plain text. So I tried logging out an logging back in again. That got me a different cryptic auth error. Then I noticed I had accidentally left my VPN on, so I turned that off, but the extension seemed to have gotten stuck in some state that it couldn't recover from. I'd either get an auth error, or it simply wouldn't ever complete auth. I even reinstalled, but couldn't get it to log me in.
So I contacted support. The experience didn't exactly spark joy. Once I got a response, the support person suggested I send more details, including logs. But they didn't say where I could find those logs. I'm a customer - how would I know where the logs are? Anyway, I uploaded a video of the bug on the web tracker, but later the support person said they never got it. The upload had apparently failed, but I didn't get an error when I uploaded it, so I didn't know that.
After I asked for the location of the logs, they sent me instructions for where to find them. But I was busy and couldn't respond for a few days, so then the system sent me an automatic message saying that since they hadn't heard from me, my issue would be closed. Ugh. I sent another email saying to keep the issue open. Then I sent the logs, and the support person told me to try logging in with a token and gave me instructions. That worked! It took about a week and a half to sort it out, so I asked for a refund for my trouble. I was told that no refund or credit would be given.
This left a sour taste in my mouth. It's not about the money. Credit for lost time using the service would have been around $2. It's more about what it means, that the company values my time and trouble, and this issue cost me a lot of time and trouble.
I hope that I'm not ruining this support person's day. My sense is that these kinds of things are usually due to training and policy, and they were probably just following their training.
It's a shame because Cody definitely has a much better UX than Continue. It does a lot of smart things by default that are really helpful. So I was ready to stick with it, but this experience definitely made me ready to try Continue again.
Hope this helps!
If you get the chance to try the 1.0, I'd love to hear whether you find it better, or if you think we can do even better—we think it's in a solid place and it'll always be improving from here.
You can build with ai to give the power to you and produce a regular (at best) product.
You can build a custom ai code assistant maker so that coders can use ai to produce ai products.
It's too much incest, I hate it, hope you guys eat your own tail
This looks like a genuinely refreshing and open source path to helping developers control their own ai stack. I don’t see the harm.
If we are to complain about tools that help make tools that help make products, then we should start decrying compilers and interpreters, for they too are tools that help make tools that help build products.
are they logging telemetry or other data?
We have opt-out telemetry that is described clearly here (https://docs.continue.dev/telemetry), and is very easy to toggle off. And we’re actually much more interested in helping folks collect their own data. In the hub, there are “data” blocks that let you send development data to a destination of your choice so you can better understand your own use of AI for development and eventually fine-tune models: https://docs.continue.dev/customize/deep-dives/development-data
I've been following the IDE + LLM space. What's Continue's differentiator vs GitHub Copilot, Cursor, Cline, Claude Desktop, etc. ?
What are you looking to build over the next year?
We're going to keep building at the edge of what's possible in the IDE, including focusing on Agent mode (https://docs.continue.dev/agent/how-to-use-it), next edit prediction, and much more. And we're going to keep making it easier to build custom assistants as the ecosystem grows!