Solver

🎬 SEE SOLVER IN ACTION

Tutorial: Solver Walkthrough

Tutorial: Fixing a Bug in Solver's Platform

Demo: Building with Solver's Projects feature

Tutorial: Execution Environment Setup

Demo: Web Research - Solver Creates a Resume for Alan Turing

@zot This is a good question and I would like to see the author's answer

@zot  @irina_arty_ Great question, and thanks for the support! Aside from Solver's own training on a large number of real-world tasks, Solver backstops its own work by frequently actually running the code it's modifying, all in its own isolated container. That lets it get important feedback about the blast radius of changes it's making in real time.

We've also put a lot of work into the cloud platform that Solver lives in. Behind the scenes, there's a journaled filesystem where pretty much everything is transactional. If Solver does something you don't like, it's contained and very easily undoable/redoable! And then one final layer on that: that everything is still based on a standard Git workflow. Solver will never truly commit code (i.e. push to a remote) unless you tell it to explicitly by using one of our UI affordances.

@sentry_co Thank you so much for your support! We actually have this activity going on as we speak. In fact, in preparation for this launch, we were literally solving the current backlog of the `ruff` repo repeatedly! We haven't opened the PRs yet because we're focused on this launch. And in addition to that, we're very sensitive to the time and attention of open source maintainers. It wouldn't be fair for us to open several dozen PRs that we haven't spent the time to vet ourselves. We'd like to establish and maintain a helpful and symbiotic relationship with OSS and not be perceived as "using them for marketing". Stay tuned!

Well. I mean there millions of repos to pick from. You can even make a synthetic one. If it was not for the teams background, The claims on the website with no evidence, would be a huge red flag. Because it takes so little time to prove this case. half a day tops. Also the price is a bit of a red flag. It should be 10-100x more expensive. I use 100$ on O1 per day in cursor. And its not even agentic usage. I presume you do things agenticly, and with that you would also want to use the absolute best models so that you dont just add AI slop to commits. Sorry for roasting a bit, but I really want something like this to work soon 🙏 Love the mission tho! And seems like a fantastic team!

@sentry_co Thank you so much for the kind words! We're actually doing a lot behind the scenes to deliver value from the best models at our current price point. We are very grateful to our (large) beta audience, who in the fourth quarter of last year gave us enough daily usage data to improve efficiency and to create a metered pricing model that is as generous as possible to our users. And while we allot a large number of credits to our Pro tier, our paid users also have the ability to purchase more a la carte, and I can share with you here that we have some users who are getting enough value out of Solver that they're actually spending closer to the amount you're saying! Very exciting and humbling for us to see.

And message received about the size of the OSS community; the community writ large will never run out of issues to solve, and we can't wait to have "created by Solver" PRs accepted to active projects. There are a lot of those in Solver's own repos!

@mark_gabel Yeah. I think pay as you go here is the sweet spot, time is money after all. Have good launch! And looking forward to seeing this progress. I followed the linkedin page 😸

@jonurbonas Thanks for the support, Jonas, and great questions! We've worked on a large variety of projects in our collective careers and we know that no two are alike. Here are some things we've done to keep Solver individualized:

• We have a first-class "memories" feature, which allows you to store nuggets of repo-specific knowledge and reuse them in all future sessions (without any credit deduction!). And occasionally, Solver will even proactively suggest new memories on its own for you to review.

• Solver builds an index of your repository and "gets to know it" very well, all when you first "activate" that repo in our UI. That index is then incrementally updated for whatever session you're on. That index gives Solver strong code search and code understanding capabilities, all native, that allow it to pivot more into "domain specific engineering" very quickly.

• For truly custom workflows, where you perhaps want to use Solver outside of the Solver webapp, we actually have a public API that will soon be separately launched! Today, that API powers much of Solver, especially our Slack integration (if you have the time and inclination - check that out. Tagging `@Solver` in a Slack thread and having the work just get done feels so futuristic), but soon we'll be opening it up to all devs and seeing what they build. We're particularly excited about the possibility of automatically proposing fixes to issues reported in observability tracking systems like Datadog.

@jonurbonas  @Solver  @mark_gabel If you're looking to integrate Solver with specific coding practices/toolchains you can combine the memories feature with Solver's execution environment to give Solver a dev environment just like the one you use. If you ask Solver to use any tools (e.g. we use `ruff` to enforce a codestyle) it will install the tools and you can then use a memory to have Solver always run those tools before it completes a task.

@nico_rako put together a great tutorial video on how to do this that @mark_gabel linked in a different reply. If that route still isn't flexible enough you can bring your own docker image and Solver will use that as its executin environment for even more flexibility!

Thanks so much for your support and the kind words,@chrismessina!

@maria_kud all of them! Solver is mostly language-agnostic and will work with any Github repo. That said, we've built-in some additional integrations with common languages like Python, JavaScript/Typescript and others.

If your language/toolchain of choice isn't well-supported natively, you can always configure Solver by configuring a custom Docker image for its environment and/or create Memories that tell Solver how to operate effectively in your repo.

We're always eager to hear how you use Solver and whether there are native improvements we can make to facilitate your workflows!

@thefullstack great question! High-level, we've built Solver from the ground-up for operating more autonomously and asynchronously. We love Cursor, Claude Code, and others, but these are fundamentally built to involve the user in a tight, single-threaded loop – if you close your laptop, these tools take a break as well. On the other hand, Solver is cloud-native, with its own independent developer environment, and will work while you focus on something else (or go make some coffee).

Re: MCP – this is a fantastic set of abstractions and it's exciting to see the community build on them. That said, I'm sure you've noticed that the magic is in how an MCP client leverages the capabilities exposed by the MCP server(s). We've embedded deep domain expertise into Solver's dev environment, its use of software tools, its awareness of best-practices, etc.