This is why I don't like open sourcing my projects anymore. Someone else with more resources just forks it and makes profits, thinking that merely acknowledging me pays my bills.
For years, ollama didn't acknowledge llama.cpp and r/localllama found it weird until they finally mentioned llama.cpp on their page, but the damage is done: most apps that support local LLMs only support ollama or LM Studio API, not the original llama.cpp.
Choose your license well. If you are using a permissive licence (MIT, Apache, BSD, etc...) you are begging for it. If that's what you want (and it may be what you want), go for it, but don't expect it to pay the bills.
If you are using a copyleft license, especially AGPL, you may not get paid either, but you may get valuable contributions in return. It is also a good way to avoid having big companies profit from your work, if that's what you want.
If you want to make money but still want to open source, use a non-free "source available" licence (ex: "non-commercial"). They tend to be unpopular in the open source community and it is probably not the best way to get known.
And then you can have dual-licences, like GPL + commercial. Qt is probably the most popular software using that scheme.
But I don't really understand the people who publish software under a permissive licences and get forked by some tech giant and complain. That's what permissive licenses are for!
From the POV of an indie dev selling closed-source binaries, would a source-available license gain any goodwill in this space? And how would you tackle pricing?
I don't really have a say since I don't buy nor sell software. As a technical guy, I may have an influence, but usually, finance decides and not always the way I'd like.
That being said, I highly value having access to the source code, even under a restrictive license. The source code is the best documentation, it doesn't lie. Also being able to make small changes, recompile with different libraries, etc... but for me, the "documentation" aspect is the most important. I don't do security, but I guess being able to audit the code is a good thing too.
For me, open source goes beyond the "freedom" aspect. Also, AFAIK, most commercial game engines are "source available" too.
I would prefer the BSL with some sort of trial period grant and source available to closed source.
Other nice thing about BSL is it converts to an Open Source license after 3-4 years which addresses the concern “what if the software vendor goes out of business”. You can support it yourself or another vendor can pick it up and support it after that time period.
> This is why I don't like open sourcing my projects anymore. Someone else with more resources just forks it and makes profits, thinking that merely acknowledging me pays my bills.
Then I would submit that you are picking the wrong license. The whole point of the GPL/AGPL family of licenses is to ensure that they can't just do this. They will be required to publish their changes, which benefits the original project (you). It's not a perfect solution, but it helps a great deal. The answer to this problem is not to close up and/or go proprietary.
then don't. the point of open source is not to earn money or profit. it's to have the software open so people can inspect it, be inspired by it, trust it, modify it without contacting you and possibly copy it. imagine sharing your idea with the world but not wanting anyone to implement or capitalize on it. it's an impossible ask.
i'm a bald head grey beard, at least in the 90's when we shared software it was for the reasons we outlined, there was no github stars, there was no trying to line a job. it was a true gift and pay it forward sort of thing to the world. it's been almost lost due to money, if you need to earn a living, start a business, get a job and make your open source project a hobby. don't mix them together.
> at least in the 90's when we shared software it was for the reasons we outlined...
With all due respect, that's not how most open source software is today [1]. A lot of CS students on the job market need Github stars or green tiles in case the employers check their page. So many open source projects are done only to boost resumes, not for the reasons you mentioned. Not to mention a lot of projects start as open source to lure users, only to become closed at some point (the notorious langchain is one example).
[1]: with the exception of some huge projects like ffmpeg, llama.cpp, etc.
- If your primary goal is to release open software that stays open, then release under a copyleft license (GPL)
- If your primary goal is to release software for no-strings-attached use (including incorporation into commercial services) then use a permissive license (MIT, BSD, etc.)
Interesting. So if you just configure continue with Mistral Medium 3 as the chat model and codestral as the autocomplete, you probably have exactly this. This is the setup I already use.
If that were the case, then the posted URL would be pure hype. I think it's more likely that they've developed something that is more bespoke than that. It's totally too hard to say though.
Knowing the enterprise space, my guess is that the only real changes are hardcoding continue to use only Mistral, and tying it into some sort of central enterprise licensing service. Holding back some novel models just for enterprise use seems unlikely, as does developing some novel agentic capabilities within Continue.
Enterprise deals are usually around compliance and security primarily. Companies want centralized billing and to be sure that their developers only use "sanctioned" AI and other tech.
That's very possible. You can already do that via the platform api easily (just feeding it your github project), so a light UI around that api would be very easy.
Originally as an experiment in using non-US services, as my company is not a US company and the possibility of tariffs on digital services is not at all unrealistic. The exercise was really enlightening. Not to derail the conversation the TLDR was that in some areas it was easy to move off US services, while in others (github) there are almost no alternatives.
I do have access to US models via Kagi to play around with and use for things Mistral doesn't work on. I've been meaning to try command a too, but haven't gotten around to it. I will say that the new mistral medium model is surprisingly good, though I've only just started using it. Codestral is definitely behind other models.
What feature of github is lacking in competetitors ?
I wouldnt use an AI LLM that has 50% of chance of me needing to reprompt or try another model, I prefer using direclty the best model directly. But yeah US vs. Europe is a real concern
Well that tidbit of information was definitely sweeped under the rug.
Strikes me as a weird combo to have a fork of a VS Code/JetBrains extension be a completely walled off enterprise only deal. Any other apps out there having success with this sort of model?
Same as others have said, with consumers wanting to try 20 different models all the time, you have to reduce the friction of trying out the model.
I hope this is just a huge mistake that they aren't allowing anyone to actually try it.
Word of mouth from HN and others (not just advertising a link or press release) is how I've started to use about pretty much every single AI feature I use.
Assuming this isn't a mistake, it says that this company has the wrong management/leadership structure if they think they can sell a brand new developer focused coding tool without letting actual developers try it. Maybe we don't know something?
> Do I need an active subscription to use Mistral Code?
> At the moment, Mistral Code is a premium feature only avaible to Enterprise customers.
> This means that to activate and use Mistral Code, your organization needs to have an active Enterprise agreement with Mistral AI that includes access to this tool.
> Individual users within such organizations can then log in on their own and use the extension autonomously, provided they've been attributed a Mistral Code seat by their organization's administrator (see How to manage Mistral Code seats for more details).
Mistral lags behind on model quality. Seems like they want to focus more on customization and customer relations. If they had a leading model they'd probably have transparent pricing.
It's the other way around - everybody wants to create products with mass appeal and have low marginal costs and print money. The people who can't manage to do that go the consultancy route and add "contact us" under their pricing.
I think the main differentiator here is the local installability and customizability. They're clearly targeting orgs that can't or won't use the actual cutting edge agentic models on the market for security or other reasons. Those places are going to need/want to work with a full enterprise sales pipeline, do the security reviews, BAAs, etc.
"Contact Us" is a dealbreaker for a lot of orgs, but for the ones that are the real intended customers here it's not a huge impediment.
The higher up the food chain you can go the more effective this is. Someone who thinks that negotiating is part of their job and/or persona is more willing to call the place they think they can get a deal on rather than the fixed price offering.
Whether they're correct is a separate question, but it's an effective strategy if you're targeting that buyer.
I worked for enterprise software companies for a number of years.
I’m not personally a fan of “call us” pricing, but it is indeed effective, and the companies that sell software this way do so because they prioritize establishing human relationships between a salesperson and the buyer.
In the long run, this leads to more sales/upsells.
Also not only just establishing human relationships, sometimes software might not be available at all for plug and play and require client level tuning to be effective. Even in cursor, setting up a good .cursorrules seems to have quite a big effect.
I don't think "call us" is an effective inbound sales tactic though, but Mistral does have folks in sales who can do outbound sales.
This is a key point. A customer that buys $100K+ worth of software is automatically a future debook risk if they can't/don't implement it successfully and start seeing value right away.
The high touch approach ensures they're getting support at every step of the way and increases the chances that they'll use the software and renew later.
I'm not sure how many of these factors are in play for Mistral, but to your point, it's easy to imagine some scenarios.
This is a fairly cynical way to frame this. There is absolutely bad behavior in the enterprise software space, but that is certainly not universal, and is not inherent to the "call us" approach.
> If you're too small, they won't even talk to you.
This is often true. Some of the software I worked on was extremely expensive to host, and there was indeed a minimum threshold that was many multiples of $10K.
It's not that the company didn't want smaller players to use the software, but that smaller players just weren't large enough to benefit from the minimum buy-in, and selling the software at a lower cost for those smaller customers would have just been pure loss. Over time, they were able to lower the minimum threshold due to improvements in the architecture and economies of scale, but the point here is just that these minimums often exist for good reasons.
> Knowing your client happens regardless of showing pricing or not.
It really does not. Many software companies have a minimal relationship (if any) with their customers. For some customers and some product types, this is perfectly fine. But when a company is buying software that will cost the company millions/year, having a direct line to a real person who in turn can arrange conversations with product management, customer success, etc. is table stakes, and is often not possible or available with smaller vendors.
You can dislike the model, but I'd suggest digging in to some of the why before dismissing it too reductively.
dismissals of negative reactions as 'cynical' rarely acknowledge the fact that a 'cynical' response is often no more cynical than the cynicism of the target.
bespoke pricing is a cynical tactic, no matter how you dress it up. it provides a legal shroud, and i've no more patience in me to give the benefit of the doubt to any profit-motivated enterprise that can't at least be upfront about what they want to charge for their services.
I think you overestimate the degree to which some software can be standardized and sold in a set of well-defined SKUs, and the degree to which some buyers want to be intimately familiar with extremely granular pricing (e.g. something like AWS).
Again, speaking only for the places I worked, part of the reason pricing wasn't simple was that larger customer deployments were tuned to the customer based on a myriad of factors ranging from the specific software modules the customer purchased, use cases they intended to deploy and the load characteristics of those use cases, etc.
Setting aside for a moment any potential bad behavior, the bottom line is that for some kinds of software, bespoke pricing is a more accurate reflection of the reality of the deployment than trying to force some kind of standardized label on it. The places I worked also had pricing books they'd show customers, but due to their complexity, they would not publish these publicly.
> bespoke pricing is a cynical tactic, no matter how you dress it up
We'll have to agree to disagree. Having worked with quite a few large vendors over the years, there are clear and obvious differences between them, better and worse reasons for this type of pricing, and there's a reason that some companies have earned a negative reputation while others have not.
It's also not clear to me why you've concluded that this is all inherently cynical.
maybe i overestimate. maybe i just appreciate the difference between the product and support for the product. for support, i understand a more-bespoke pricing model, but it'd be nice if there was at least some upfront inkling of how much i have to open my organization's veins in exchange for a working implementation.
interacting with capital is a cynical act. capitalism is predatory but it's necessary to interact with it. if you're not cynical, you risk being taken for a worse ride than you have to be. this isn't me handwaving things; it's a fundamental aspect to how i see the world. cynicism doesn't have to be a simple doom-and-gloom "well, everything is bad, end of discussion" (regardless of my personal feelings about it) - it can be a tool to make sure you're able to interact with systems in ways that benefit you and others while retaining whatever modicum of control you can - because even if you aren't, your vendor is (or they're on their way to being out of business as a profit-motivated entity).
> maybe i just appreciate the difference between the product and support for the product. for support, i understand a more-bespoke pricing model
I'm trying to frame this sentence so it doesn't sound like a jab because that's not my intent, but based on what you've written, I don't think you understand the kind of software I'm describing.
In your mind, what is the distinction between the two, especially for an enterprise solution hosted by a vendor? In my experience, the two are often not so different at all, and the clean lines you imagine here are not lines that exist in practice. This will depend on the nature of the software, and the kind of support customers need (i.e. infrastructure vs. implementation).
> but it'd be nice if there was at least some upfront inkling of how much i have to open my organization's veins in exchange for a working implementation.
You are assuming this is not part of the model, but it is. Not publicly listing a pricing sheet does not in any way mean a customer doesn't have clarity about how much their deployment will cost before they sign a contract.
> interacting with capital is a cynical act.
Your use of "cynical" is in a different category than what I was describing above. If we go with your definition, there is no reason to differentiate between bespoke pricing and up-front published pricing.
I think your argument is supported by the fact that many companies, in and outside of AI, have pricing upfront. That's for cloud platforms, OS's, frameworks like Sciter, shrink-wrap, semi-custom with value adds ("starts at..."), per-token pricing on models, etc.
Then, some companies wont give the slightest hint of pricing unless we talk to their paid salespeople. It's definitely a game to extract more money out of you. While they may or may not, they often ignore low-volume customers who could easily buy the product if it was on an online store. Your skepticism is warranted.
> While they may or may not, they often ignore low-volume customers who could easily buy the product if it was on an online store. Your skepticism is warranted.
Setting aside any qualms about how the pricing is published, if a business chooses a strategy in which they focus on large customers and choose not to take on small customers, why is this an issue? Especially when the market is filled with alternatives?
The support model, predictability of yearly renewals, per-customer overhead, etc. look quite different when selling to larger customers vs. small/low-volume customers.
It depends on one's moral philosophy. One kind would see it as discrimination with a negative, long-term impact on people and markets. Others would say they can do whatever they want. Subjectivists and capitalists would encourage them to do so to maximize selfish gains, esp money and power.
If about selfish gain, then you should have no concern with people calling out their practice to warn others. They're doing what they want to do. They're also helping others with a warning to avoid harms, like lock-in and overcharging, that are more likely with "call us for a quote" type companies. The warnings are also market signals for buyers.
In my case, I also tell people to encourage good practices like having prices up. Posts like mine might also inspire regulations that force prices to be shared ahead of time. They might also inspire people to use or develop lock-in-free alternatives which some out there are doing.
To make sure I understand your comment, are you saying that a company that sells a product with a $50K minimum buy-in — a number determined to be the threshold at which the company can recoup development costs and make a reasonable profit — is engaging in some kind of immoral behavior because it can only be purchased by larger companies?
> One kind would see it as discrimination with a negative, long-term impact on people and markets. Others would say they can do whatever they want.
This is quite the false dichotomy.
There are many valid reasons to sell to specific customer segments/markets that do not amount to “we’re doing it because we want to”.
In the early days of 3D printing, such hardware was prohibitively expensive and primarily sold to businesses. Even now, there are classes of 3D printer that cost many multiples of $10K. It would be strange to classify this as discrimination vs. acknowledging the realities of the market and the fact that it only makes sense target specific customer types depending on the product.
> They might also inspire people to use or develop lock-in-free alternatives which some out there are doing.
Lock-in is orthogonal to this pricing structure. It sounds like your primary issue is with companies that behave badly and use dark patterns. I share those concerns. But those issues are not inherent (or limited to) to “Call Us” pricing.
I buy Enterprise software too and unless there is a good reason (there are no other alternatives, or I have complex requirements), I'll also quite often negatively factor being dropped into a sales funnel, with all it entails.
If you're buying actual business critical software, you always want a signed contract. Even if they have transparent pricing and a checkout form. Most of these services will reserve the right to terminate service if they detect any violation of terms. A signed contract usually precludes them from doing that.
This is a little embarrassing and I'm a little shocked HN hasn't flagged it to death.
I seriously doubt Mistral was able to create something actually useful (or at least better than Aider/Claude Code/etc) and hiding behind enterprise sales is cowardly. Surely anyone with half a brain isn't going to roll the dice on something completely untested and coming from a company like Mistral. They have no track record in this area and their models aren't considered SOTA.
What are the alternatives? Let's say you're something like Deutsche Bank and you need an AI solution for your dev team that is fully compliant with EU privacy laws.
While enterprise stuff is dead on arrival, their models for OCR and niche languages are indeed SOTA. Also, their local/small models are likely SOTA too if you are running in a constrained environment.
I think their selling point is self hosting - I mentioned ollama because you can self host it. You're right though that ie. copilot ie via vscode is something that most enterprises can do as they already have contracts with github/microsoft so they're fine with code flying there (because it's already there).
Pricing is worse than contact us, it's contact us and tell us your company size and revenue wtf Mistral, I wanted to maybe pick this up, as we're an european company and I want an European ai company to succeed but this is ridiculous
Yea but for Mistral it's not just the enterprise plan. It's all variants of the "Mistral Code". So pretty useless to launch on HN if the only CTA is booking a demo.
Yea but this little tator just wanted to use the coding agent, I don't expect enterprise features.
Unfortunately there's no alternative to enterprise, so no way to support an European alternative :)
Why are all these code assistants apps coming out now? Is it because it takes two years to make these apps? Or is it because LLM performance is plateauing so the way to capture more of the market is via these apps?
>Mistral Code Enterprise is a fork of Continue. All due credit to the original creators of Continue.
Here's the problem with AI company revenue, I want this to be local, Continue is open source, my company laptop is powerful enough to run a usefully sized LLM locally more or less just as fast, and there are plenty of open models available publicly (including by Mistral, latest dev related called devstral).
As hardware progresses and LLM efficiency increases, I really don't think LLM programming has any future doing remote execution unless maybe as a chatbot kind of experience, but definitely not in an IDE.
Putting together a good developer experience with the open-ish and free-ish things available is still an exercise in cobbling a bunch of things together, but it's going to be streamlined soon and finding a way to compete with "zero cost and local" is going to be very hard for AI businesses.
it’s wild cause the underlying tech might be sick but this enterprise gatekeeping ruins the whole arc. not every dev wants to fake a cto title just to see a pricing page.. tbh at this point just put a playground, let people touch it, break it, love it. if it’s good, it spreads. no need to run it like you're guarding the source of life.
maybe it’s a leaner model actually tuned for coding, not just another wrapper. fast, scoped, trained right and but zero clarity. all potential, no real explanation.
> Mistral Code Enterprise is a fork of Continue. All due credit to the original creators of Continue.
Source: https://marketplace.visualstudio.com/items?itemName=mistrala...
Link destination: https://www.continue.dev/
This is why I don't like open sourcing my projects anymore. Someone else with more resources just forks it and makes profits, thinking that merely acknowledging me pays my bills.
For years, ollama didn't acknowledge llama.cpp and r/localllama found it weird until they finally mentioned llama.cpp on their page, but the damage is done: most apps that support local LLMs only support ollama or LM Studio API, not the original llama.cpp.
Choose your license well. If you are using a permissive licence (MIT, Apache, BSD, etc...) you are begging for it. If that's what you want (and it may be what you want), go for it, but don't expect it to pay the bills.
If you are using a copyleft license, especially AGPL, you may not get paid either, but you may get valuable contributions in return. It is also a good way to avoid having big companies profit from your work, if that's what you want.
If you want to make money but still want to open source, use a non-free "source available" licence (ex: "non-commercial"). They tend to be unpopular in the open source community and it is probably not the best way to get known.
And then you can have dual-licences, like GPL + commercial. Qt is probably the most popular software using that scheme.
But I don't really understand the people who publish software under a permissive licences and get forked by some tech giant and complain. That's what permissive licenses are for!
From the POV of an indie dev selling closed-source binaries, would a source-available license gain any goodwill in this space? And how would you tackle pricing?
I don't really have a say since I don't buy nor sell software. As a technical guy, I may have an influence, but usually, finance decides and not always the way I'd like.
That being said, I highly value having access to the source code, even under a restrictive license. The source code is the best documentation, it doesn't lie. Also being able to make small changes, recompile with different libraries, etc... but for me, the "documentation" aspect is the most important. I don't do security, but I guess being able to audit the code is a good thing too.
For me, open source goes beyond the "freedom" aspect. Also, AFAIK, most commercial game engines are "source available" too.
I would prefer the BSL with some sort of trial period grant and source available to closed source.
Other nice thing about BSL is it converts to an Open Source license after 3-4 years which addresses the concern “what if the software vendor goes out of business”. You can support it yourself or another vendor can pick it up and support it after that time period.
Licenses only work if it's copyrightable and weights, almost certainly, aren't.
The code would be, but I'm not sure that's much of a barrier.
> But I don't really understand the people who publish software under a permissive licences and get forked by some tech giant and complain
They want to have their cake and eat it.
> This is why I don't like open sourcing my projects anymore. Someone else with more resources just forks it and makes profits, thinking that merely acknowledging me pays my bills.
Then I would submit that you are picking the wrong license. The whole point of the GPL/AGPL family of licenses is to ensure that they can't just do this. They will be required to publish their changes, which benefits the original project (you). It's not a perfect solution, but it helps a great deal. The answer to this problem is not to close up and/or go proprietary.
then don't. the point of open source is not to earn money or profit. it's to have the software open so people can inspect it, be inspired by it, trust it, modify it without contacting you and possibly copy it. imagine sharing your idea with the world but not wanting anyone to implement or capitalize on it. it's an impossible ask.
i'm a bald head grey beard, at least in the 90's when we shared software it was for the reasons we outlined, there was no github stars, there was no trying to line a job. it was a true gift and pay it forward sort of thing to the world. it's been almost lost due to money, if you need to earn a living, start a business, get a job and make your open source project a hobby. don't mix them together.
> at least in the 90's when we shared software it was for the reasons we outlined...
With all due respect, that's not how most open source software is today [1]. A lot of CS students on the job market need Github stars or green tiles in case the employers check their page. So many open source projects are done only to boost resumes, not for the reasons you mentioned. Not to mention a lot of projects start as open source to lure users, only to become closed at some point (the notorious langchain is one example).
[1]: with the exception of some huge projects like ffmpeg, llama.cpp, etc.
The MPL 2.0 is a great compromise. it's basically as permissive as the MIT, but the source code must be made available.
https://www.tldrlegal.com/license/mozilla-public-license-2-0...
This is completely within your control:
- If your primary goal is to release open software that stays open, then release under a copyleft license (GPL)
- If your primary goal is to release software for no-strings-attached use (including incorporation into commercial services) then use a permissive license (MIT, BSD, etc.)
Interesting. So if you just configure continue with Mistral Medium 3 as the chat model and codestral as the autocomplete, you probably have exactly this. This is the setup I already use.
If that were the case, then the posted URL would be pure hype. I think it's more likely that they've developed something that is more bespoke than that. It's totally too hard to say though.
Knowing the enterprise space, my guess is that the only real changes are hardcoding continue to use only Mistral, and tying it into some sort of central enterprise licensing service. Holding back some novel models just for enterprise use seems unlikely, as does developing some novel agentic capabilities within Continue.
Enterprise deals are usually around compliance and security primarily. Companies want centralized billing and to be sure that their developers only use "sanctioned" AI and other tech.
Who knows though with that contact us sales wall.
The page suggests it's possible to fine-tune models on your code base
That's very possible. You can already do that via the platform api easily (just feeding it your github project), so a light UI around that api would be very easy.
Interesting, why do you use those models ? They feel inferior
Originally as an experiment in using non-US services, as my company is not a US company and the possibility of tariffs on digital services is not at all unrealistic. The exercise was really enlightening. Not to derail the conversation the TLDR was that in some areas it was easy to move off US services, while in others (github) there are almost no alternatives.
I do have access to US models via Kagi to play around with and use for things Mistral doesn't work on. I've been meaning to try command a too, but haven't gotten around to it. I will say that the new mistral medium model is surprisingly good, though I've only just started using it. Codestral is definitely behind other models.
What feature of github is lacking in competetitors ?
I wouldnt use an AI LLM that has 50% of chance of me needing to reprompt or try another model, I prefer using direclty the best model directly. But yeah US vs. Europe is a real concern
Well that tidbit of information was definitely sweeped under the rug.
Strikes me as a weird combo to have a fork of a VS Code/JetBrains extension be a completely walled off enterprise only deal. Any other apps out there having success with this sort of model?
Same as others have said, with consumers wanting to try 20 different models all the time, you have to reduce the friction of trying out the model.
I hope this is just a huge mistake that they aren't allowing anyone to actually try it.
Word of mouth from HN and others (not just advertising a link or press release) is how I've started to use about pretty much every single AI feature I use.
Assuming this isn't a mistake, it says that this company has the wrong management/leadership structure if they think they can sell a brand new developer focused coding tool without letting actual developers try it. Maybe we don't know something?
Poolside does the same thing, though
Pricing is 'contact us'.
Since this is a fork of continue.dev I wonder about the legal implications of monetizing the project.
Isn't Continue released under Apache 2?
There are no conflicts with monetizing open source projects as long as the source is available.
yes there are, depending on the license.
Dead on Arrival
How will companies engage with Mistral if their developers can't just install the thing and test it?
--
Here's a FAQ for Mistral Code: https://help.mistral.ai/en/collections/732571-mistral-code
For example: https://help.mistral.ai/en/articles/333875-do-i-need-an-acti...
> Do I need an active subscription to use Mistral Code?
> At the moment, Mistral Code is a premium feature only avaible to Enterprise customers.
> This means that to activate and use Mistral Code, your organization needs to have an active Enterprise agreement with Mistral AI that includes access to this tool.
> Individual users within such organizations can then log in on their own and use the extension autonomously, provided they've been attributed a Mistral Code seat by their organization's administrator (see How to manage Mistral Code seats for more details).
Mistral lags behind on model quality. Seems like they want to focus more on customization and customer relations. If they had a leading model they'd probably have transparent pricing.
They could get away with 'contact us' if they were leaders. Maybe they're courting the EU-only segment.
It's the other way around - everybody wants to create products with mass appeal and have low marginal costs and print money. The people who can't manage to do that go the consultancy route and add "contact us" under their pricing.
I think the main differentiator here is the local installability and customizability. They're clearly targeting orgs that can't or won't use the actual cutting edge agentic models on the market for security or other reasons. Those places are going to need/want to work with a full enterprise sales pipeline, do the security reviews, BAAs, etc.
"Contact Us" is a dealbreaker for a lot of orgs, but for the ones that are the real intended customers here it's not a huge impediment.
How do you launch a dev tool with a “contact us” call to action?
It’s like Mistral is choosing to fail here.
Edit: I can't even tell if its a CLI tool, an IDE plugin or a standalone IDE!
Edit 2: oh man! it's at the bottom of the page
Edit 3: "Mistral Code Enterprise is currently only available with an enterprise license." :D
The higher up the food chain you can go the more effective this is. Someone who thinks that negotiating is part of their job and/or persona is more willing to call the place they think they can get a deal on rather than the fixed price offering.
Whether they're correct is a separate question, but it's an effective strategy if you're targeting that buyer.
Presumably their market is different than the typical developer or low-level manager armed with with a shadow IT company card.
I think unfortunately Enterprise Call Us sales tactics are actually extremely effective.
Are they? I never look at such software again unless forced by my boss.
I worked for enterprise software companies for a number of years.
I’m not personally a fan of “call us” pricing, but it is indeed effective, and the companies that sell software this way do so because they prioritize establishing human relationships between a salesperson and the buyer.
In the long run, this leads to more sales/upsells.
Also not only just establishing human relationships, sometimes software might not be available at all for plug and play and require client level tuning to be effective. Even in cursor, setting up a good .cursorrules seems to have quite a big effect.
I don't think "call us" is an effective inbound sales tactic though, but Mistral does have folks in sales who can do outbound sales.
This is a key point. A customer that buys $100K+ worth of software is automatically a future debook risk if they can't/don't implement it successfully and start seeing value right away.
The high touch approach ensures they're getting support at every step of the way and increases the chances that they'll use the software and renew later.
I'm not sure how many of these factors are in play for Mistral, but to your point, it's easy to imagine some scenarios.
No, they specialize in knowing how to extract every single penny from you they can. Find out how big the company is, and bleed them as best possible.
If you're too small, they won't even talk to you.
That's what besoke pricing is.
Knowing your client happens regardless of showing pricing or not.
This is a fairly cynical way to frame this. There is absolutely bad behavior in the enterprise software space, but that is certainly not universal, and is not inherent to the "call us" approach.
> If you're too small, they won't even talk to you.
This is often true. Some of the software I worked on was extremely expensive to host, and there was indeed a minimum threshold that was many multiples of $10K.
It's not that the company didn't want smaller players to use the software, but that smaller players just weren't large enough to benefit from the minimum buy-in, and selling the software at a lower cost for those smaller customers would have just been pure loss. Over time, they were able to lower the minimum threshold due to improvements in the architecture and economies of scale, but the point here is just that these minimums often exist for good reasons.
> Knowing your client happens regardless of showing pricing or not.
It really does not. Many software companies have a minimal relationship (if any) with their customers. For some customers and some product types, this is perfectly fine. But when a company is buying software that will cost the company millions/year, having a direct line to a real person who in turn can arrange conversations with product management, customer success, etc. is table stakes, and is often not possible or available with smaller vendors.
You can dislike the model, but I'd suggest digging in to some of the why before dismissing it too reductively.
> This is a fairly cynical way to frame this.
dismissals of negative reactions as 'cynical' rarely acknowledge the fact that a 'cynical' response is often no more cynical than the cynicism of the target.
bespoke pricing is a cynical tactic, no matter how you dress it up. it provides a legal shroud, and i've no more patience in me to give the benefit of the doubt to any profit-motivated enterprise that can't at least be upfront about what they want to charge for their services.
I think you overestimate the degree to which some software can be standardized and sold in a set of well-defined SKUs, and the degree to which some buyers want to be intimately familiar with extremely granular pricing (e.g. something like AWS).
Again, speaking only for the places I worked, part of the reason pricing wasn't simple was that larger customer deployments were tuned to the customer based on a myriad of factors ranging from the specific software modules the customer purchased, use cases they intended to deploy and the load characteristics of those use cases, etc.
Setting aside for a moment any potential bad behavior, the bottom line is that for some kinds of software, bespoke pricing is a more accurate reflection of the reality of the deployment than trying to force some kind of standardized label on it. The places I worked also had pricing books they'd show customers, but due to their complexity, they would not publish these publicly.
> bespoke pricing is a cynical tactic, no matter how you dress it up
We'll have to agree to disagree. Having worked with quite a few large vendors over the years, there are clear and obvious differences between them, better and worse reasons for this type of pricing, and there's a reason that some companies have earned a negative reputation while others have not.
It's also not clear to me why you've concluded that this is all inherently cynical.
maybe i overestimate. maybe i just appreciate the difference between the product and support for the product. for support, i understand a more-bespoke pricing model, but it'd be nice if there was at least some upfront inkling of how much i have to open my organization's veins in exchange for a working implementation.
interacting with capital is a cynical act. capitalism is predatory but it's necessary to interact with it. if you're not cynical, you risk being taken for a worse ride than you have to be. this isn't me handwaving things; it's a fundamental aspect to how i see the world. cynicism doesn't have to be a simple doom-and-gloom "well, everything is bad, end of discussion" (regardless of my personal feelings about it) - it can be a tool to make sure you're able to interact with systems in ways that benefit you and others while retaining whatever modicum of control you can - because even if you aren't, your vendor is (or they're on their way to being out of business as a profit-motivated entity).
> maybe i just appreciate the difference between the product and support for the product. for support, i understand a more-bespoke pricing model
I'm trying to frame this sentence so it doesn't sound like a jab because that's not my intent, but based on what you've written, I don't think you understand the kind of software I'm describing.
In your mind, what is the distinction between the two, especially for an enterprise solution hosted by a vendor? In my experience, the two are often not so different at all, and the clean lines you imagine here are not lines that exist in practice. This will depend on the nature of the software, and the kind of support customers need (i.e. infrastructure vs. implementation).
> but it'd be nice if there was at least some upfront inkling of how much i have to open my organization's veins in exchange for a working implementation.
You are assuming this is not part of the model, but it is. Not publicly listing a pricing sheet does not in any way mean a customer doesn't have clarity about how much their deployment will cost before they sign a contract.
> interacting with capital is a cynical act.
Your use of "cynical" is in a different category than what I was describing above. If we go with your definition, there is no reason to differentiate between bespoke pricing and up-front published pricing.
I think your argument is supported by the fact that many companies, in and outside of AI, have pricing upfront. That's for cloud platforms, OS's, frameworks like Sciter, shrink-wrap, semi-custom with value adds ("starts at..."), per-token pricing on models, etc.
Then, some companies wont give the slightest hint of pricing unless we talk to their paid salespeople. It's definitely a game to extract more money out of you. While they may or may not, they often ignore low-volume customers who could easily buy the product if it was on an online store. Your skepticism is warranted.
> While they may or may not, they often ignore low-volume customers who could easily buy the product if it was on an online store. Your skepticism is warranted.
Setting aside any qualms about how the pricing is published, if a business chooses a strategy in which they focus on large customers and choose not to take on small customers, why is this an issue? Especially when the market is filled with alternatives?
The support model, predictability of yearly renewals, per-customer overhead, etc. look quite different when selling to larger customers vs. small/low-volume customers.
It depends on one's moral philosophy. One kind would see it as discrimination with a negative, long-term impact on people and markets. Others would say they can do whatever they want. Subjectivists and capitalists would encourage them to do so to maximize selfish gains, esp money and power.
If about selfish gain, then you should have no concern with people calling out their practice to warn others. They're doing what they want to do. They're also helping others with a warning to avoid harms, like lock-in and overcharging, that are more likely with "call us for a quote" type companies. The warnings are also market signals for buyers.
In my case, I also tell people to encourage good practices like having prices up. Posts like mine might also inspire regulations that force prices to be shared ahead of time. They might also inspire people to use or develop lock-in-free alternatives which some out there are doing.
> It depends on one's moral philosophy.
To make sure I understand your comment, are you saying that a company that sells a product with a $50K minimum buy-in — a number determined to be the threshold at which the company can recoup development costs and make a reasonable profit — is engaging in some kind of immoral behavior because it can only be purchased by larger companies?
> One kind would see it as discrimination with a negative, long-term impact on people and markets. Others would say they can do whatever they want.
This is quite the false dichotomy.
There are many valid reasons to sell to specific customer segments/markets that do not amount to “we’re doing it because we want to”.
In the early days of 3D printing, such hardware was prohibitively expensive and primarily sold to businesses. Even now, there are classes of 3D printer that cost many multiples of $10K. It would be strange to classify this as discrimination vs. acknowledging the realities of the market and the fact that it only makes sense target specific customer types depending on the product.
> They might also inspire people to use or develop lock-in-free alternatives which some out there are doing.
Lock-in is orthogonal to this pricing structure. It sounds like your primary issue is with companies that behave badly and use dark patterns. I share those concerns. But those issues are not inherent (or limited to) to “Call Us” pricing.
You're not the target audience.
I buy Enterprise software too and unless there is a good reason (there are no other alternatives, or I have complex requirements), I'll also quite often negatively factor being dropped into a sales funnel, with all it entails.
A form of pre-qualification, so.
That's the idea, they are trying to have your boss force you to look at such software.
If you're buying actual business critical software, you always want a signed contract. Even if they have transparent pricing and a checkout form. Most of these services will reserve the right to terminate service if they detect any violation of terms. A signed contract usually precludes them from doing that.
Yes, but how likely were you to spend tens of thousands of dollars or more on software?
yup, got lost as well. Is it like a VS-code, continue alternative?
This is a little embarrassing and I'm a little shocked HN hasn't flagged it to death.
I seriously doubt Mistral was able to create something actually useful (or at least better than Aider/Claude Code/etc) and hiding behind enterprise sales is cowardly. Surely anyone with half a brain isn't going to roll the dice on something completely untested and coming from a company like Mistral. They have no track record in this area and their models aren't considered SOTA.
What are the alternatives? Let's say you're something like Deutsche Bank and you need an AI solution for your dev team that is fully compliant with EU privacy laws.
While enterprise stuff is dead on arrival, their models for OCR and niche languages are indeed SOTA. Also, their local/small models are likely SOTA too if you are running in a constrained environment.
> Surely anyone with half a brain isn't going to roll the dice
the evidence points to the empty half, then
Do they know all this stuff (agentic coding, mcp integration etc) is available through zed + ollama for free?
Same for VSCode which is ubiquitous and offers free Github Copilot quotas with SoTA models, for 6 months now:
https://code.visualstudio.com/blogs/2024/12/18/free-github-c...
Mistral needs to realize they don't stand a chance against AI giants that are giving out stuff for free or nearly free.
I think their selling point is self hosting - I mentioned ollama because you can self host it. You're right though that ie. copilot ie via vscode is something that most enterprises can do as they already have contracts with github/microsoft so they're fine with code flying there (because it's already there).
Is it open source?
Tired to fake open source companies pulling the rug once they generate goodwill.
Pricing is worse than contact us, it's contact us and tell us your company size and revenue wtf Mistral, I wanted to maybe pick this up, as we're an european company and I want an European ai company to succeed but this is ridiculous
OpenAI will not sell you enterprise unless you can bring in a certain amount of money. Same for Anthropic. Demand is too high for small potatoes.
Yea but for Mistral it's not just the enterprise plan. It's all variants of the "Mistral Code". So pretty useless to launch on HN if the only CTA is booking a demo.
They aren't "launching" on HN. The user that shared this link is well known as a bulk submitter.
Yea but this little tator just wanted to use the coding agent, I don't expect enterprise features. Unfortunately there's no alternative to enterprise, so no way to support an European alternative :)
We ought all to write this down and remember it well when the tide changes.
There is so many of these at this point, is there a page anywhere that has a nice table comparing all of them with their features/pricing?
How is this different than using aider-chat with mistral as the backend llm?
It's a fork of Continue, so you can basically just compare the features to Aider here: https://github.com/continuedev/continue
Why are all these code assistants apps coming out now? Is it because it takes two years to make these apps? Or is it because LLM performance is plateauing so the way to capture more of the market is via these apps?
because it's a much better experience than copy-pasting into a webapp
Ai labs are moving up the chain, the money is in the application layer.
It's also a way to have some sort of lock in.
[dead]
What's the best set of vim plugins for llm coding?
I’ve been most happy with Neovim and Avante. Using it with several hosted models on OpenRouter and a couple running on my gaming rig.
Instruct "add docstrings" to JS code :shrug:
I'd like to try it, but enterprise only?
>Mistral Code Enterprise is a fork of Continue. All due credit to the original creators of Continue.
Here's the problem with AI company revenue, I want this to be local, Continue is open source, my company laptop is powerful enough to run a usefully sized LLM locally more or less just as fast, and there are plenty of open models available publicly (including by Mistral, latest dev related called devstral).
As hardware progresses and LLM efficiency increases, I really don't think LLM programming has any future doing remote execution unless maybe as a chatbot kind of experience, but definitely not in an IDE.
Putting together a good developer experience with the open-ish and free-ish things available is still an exercise in cobbling a bunch of things together, but it's going to be streamlined soon and finding a way to compete with "zero cost and local" is going to be very hard for AI businesses.
it’s wild cause the underlying tech might be sick but this enterprise gatekeeping ruins the whole arc. not every dev wants to fake a cto title just to see a pricing page.. tbh at this point just put a playground, let people touch it, break it, love it. if it’s good, it spreads. no need to run it like you're guarding the source of life.
> it’s wild cause the underlying tech might be sick
How is their underlying tech different from any other AI VSCode extension?
maybe it’s a leaner model actually tuned for coding, not just another wrapper. fast, scoped, trained right and but zero clarity. all potential, no real explanation.
"Advanced models such as Codestral and Devstral under the hood"
IDK man, I liked their API for a while due to its low latency but after a few requests the API crashes with 90% probability.
The underlying tech is the same exact stuff as the other frontier models.
[dead]
[flagged]
what is this basis on???? elaborate more
N/A
Are you sure what are you saying? The VSCode extension link [0] also redirect to the enterprise version, with no other option being available.
0: https://marketplace.visualstudio.com/items?itemName=mistrala...
The extension seems to be enterprise only.
https://marketplace.visualstudio.com/items?itemName=mistrala...
I don't see any options for Pro or Team licenses for Mistral Code. That's only chat
Seems they're purely targeting this towards enterprise
Is it?
Mistral Code is available with enterprise deployments.
Contact our team to get started.
nothing about this shit page is "obvious". learn about CTA because this isn't it.