andrewpareles

I think a good use of time while waiting for an LLM is to ask another LLM for something. Until then Slack will do :)

This is completely true, and it's a really common objection.

I don't imagine people will want to fully visualize codebases in a giant unified diagram, but I find it hard to imagine that we won't have digests and overviews that at least stray from plaintext in some way.

I think there are a lot of unexplored ways of using AI to create an intelligent overview of a repo and its data structures, or a React project and its components and state, etc.

I should have been more careful with my wording - I was talking about major VS Code-based IDEs as alternatives. Zed is very impressive, and we've been following them since before Void's launch!

Thanks for writing! Can you try mentioning the file with "@"? Smaller models sometimes don't realize that they should look for files and folders, but "@" always gives the full context of whatever is in the file/folder directly to them.

Small OSS models are going to get better at this when there's more of a focus on tool-use, which we're expecting in the next iteration of models.

Just want to share our thinking on terminal-based tools!

We think in 1-2 years people will write code at a systems level, not a function level, and it's not clear to us that you can do that with text. Text-based tools like Claude Code work in our text-based-code systems today, but I think describing algorithms to a computer in the future might involve more diagrams, and terminal will not be ideal. That's our reasoning against building a tool in the terminal, but it clearly works well today, and is the simplest way for the labs to train/run terminal tool-use agents.

Yep, Void is a VSCode fork, but we're definitely not wed to VSCode! Building our own IDE/browser-port is not out of the picture. We'll have to see where the next iteration of tool-use agents takes us, but we strongly feel writing typescript/rust/react is not the endgame when describing algorithms to a computer, and a text-based editor might not be ideal in 10 years, or even 2.

We considered Theia, and even building our own IDE, but obviously VSCode is just the most popular. Theia might be a good play if Microsoft gets more aggressive about VSCode forks, although it's not clear to us that people will be spending their time writing code in 1-2 years. Chances are definitely not 0 that we end up moving away from VSCode as things progress.

Agreed - this is one of the better solutions today.

This is a good point.We've stayed away from documentation assuming that it's more of a browser agent task, and I agree with other commenters that this would make a good MCP integration.

I wonder if the next round of models trained on tool-use will be good at looking at documentation. That might solve the problem completely, although OSS and offline models will need another solution. We're definitely open to trying things out here, and will likely add a browser-using docs scraper before exiting Beta.

Thanks for the feedback. We'll definitely add a feature list. To answer your question, yes - we support Cursor's features (quick edits, agent mode, chat, inline edits, links to files/folders, fast apply, etc) using open source and openly-available models (for example, we haven't trained our own autocomplete model, but you can bring any autocomplete model or "FIM" model).

We don't have a repomap or codebase summary - right now we're relying on .voidrules and Gather/Agent mode to look around to implement large edits, and we find that works decently well, although we might add something like an auto-summary or Aider's repomap before exiting Beta.

Regarding context - you can customize the context window and reserved amount of token space for each model. You can also use "@ to mention" to include entire files and folders, limited to the context window length. (you can also customize the model's reasoning ability, think tags to parse, tool use format (gemini/openai/anthropic), FIM support, etc).

Interesting, thanks for sharing! We planned on spinning up a new Git branch and shallow Git clone (or possibly worktree/something more optimized) for each agent, and also adding a small auto-merge-with-LLM flow, although something more granular like this might feel better. If we don't use a versioning tool like JJ at first (may just use Git for simplicity at first), we will certainly consider it later on, or might end up building our own.

We think terminal tools like Claude Code are a good way for research teams to experiment with tool use (obviously pure text), but definitely don't see the terminal as the endgame for these tools.

I know some folks like using the terminal, but if you like Claude Code you should consider plugging your API key into Void and using Claude there! Same exact model and provider and price, but with a UI around the tool calls, checkpoints, etc.

Continue is doing great work, but they're an extension (plugin)!

Yes, you can bring OpenRouter or any other provider and connect directly! (We don't route your messages through a backend like others).