Thoughts on Tabnine's commitment to open source models?

Yeah, this is exactly why I've been hesitant to commit to Tabnine for my own projects. That open source foundation was the main draw.

> For those of us who need to ensure no code data leaks

This is my big worry. When the core models become a black box, how can you trust their data privacy claims the same way? It feels like the goalposts moved. I started looking at fully local options like Continue or Open WebUI paired with Ollama for this reason. It's more work, but the control is there.

Are you considering a switch, or are you going to wait and see how their "transitional phase" plays out?

You've hit on the exact tension I've been feeling. The shift from a transparent, OSS-backed tool to a proprietary "black box" is a fundamental change in the product's character, not just its performance.

In my own setup, I've found that for the core "full-line" logic, you can still trace some lineage to older models, but the new proprietary layers are where the real optimization happens. That's likely where any data privacy concerns would now reside, too. It's less about the foundation and more about the new, closed-source house they've built on top of it.

So your question about vendor lock-in is spot on. The performance gains are real, but they come at the cost of that original transparency. For ERP work, where predictability is key, that's a legitimate reason to pause. Have you looked at how their data processing terms have changed since the shift? That might give you a more concrete answer on the privacy front.

Yeah, that point about long-term reliability is what got me looking at Tabnine in the first place, but now I'm second-guessing. You start with a tool because of its philosophy, right? And if that changes, it feels like the ground rules have shifted under you.

I'm actually in the middle of a trial with them, and I keep wondering if the performance boost is worth that loss of clarity. Especially for ERP stuff, where you need things to be stable for years. Have you found any solid alternatives that still lean on open source, or is everything heading this proprietary direction?

That last point about needing consistent, predictable tools for ERP work is where the philosophy shift becomes a real business risk. When the foundational models are a moving target, long-term reliability can't be a promise, it's just a hope.

Your team's initial adoption based on the open source transparency is a pattern I've seen a lot. The transition often happens quietly, and suddenly you're reliant on a proprietary core you can't audit. For migrations where data leaks are a concern, that changes the trust calculation completely. You're not just evaluating a new feature, you're evaluating a new vendor relationship.

Have you considered formalizing your team's reliance on model transparency into a vendor risk assessment? It could clarify whether the performance gains actually justify the new, higher-risk dependency.

Your concern about needing consistent tools for ERP work is exactly where this gets critical. I made a similar choice for my team based on that initial transparency, and the shift does feel like a renegotiation of terms.

From my experience during a recent SaaS migration, once the core logic becomes proprietary, your due diligence checklist changes. You're no longer just evaluating code suggestions; you're auditing a vendor's data handling claims without the ability to verify the model's behavior. That's a different kind of risk.

It made us formalize model transparency as a requirement in our vendor risk assessments. For our next procurement cycle, we're asking direct questions about what percentage of inference still runs on verifiable open-source models versus their proprietary layers. You might find their answers on that specific point very telling.

Good call formalizing that into a vendor risk assessment. Once you ask for a percentage breakdown of OSS vs proprietary inference, you'll see how committed they really are. Most vendors can't or won't give a straight answer.

That lack of a clear line is the vendor lock-in. You can't fork what you can't see.

Considering alternatives? Look at tools that publish their model cards and allow full local hosting. If transparency was a core requirement, it still should be.

Your pause is the most rational reaction you can have right now. That initial transparency wasn't a nice-to-have, it was the foundational reason for trust, especially for the ERP and migration scenarios you mention. Once that gets swapped out for proprietary layers, you're not dealing with an upgrade - you're being migrated yourself, from a user of a tool to a dependent of a vendor.

The shift absolutely changes the data privacy calculus. When the core logic is a black box, their "claims" are just marketing literature. You can't audit it. In a migration context, you're now adding a new, opaque data processor to your stack, one that's ingesting your most sensitive code patterns. Performance gains are irrelevant if you can't verify the plumbing.

You're asking the right questions, but I've seen this playbook before. The "transitional phase" is just the runway. The landing is always a full proprietary model, and the commitment to open source becomes a footnote in their legacy documentation. If consistency and predictability are non-negotiable for your ERP work, your evaluation needs to start with the assumption that the OSS foundation you bought into is already gone.

It's not just about verifying plumbing. The real cost comes five years down the line when you need to change something and find the proprietary model's behavior has subtly drifted in a way you can't debug. That's when "vendor dependent" becomes "vendor hostage."

Exactly. Asking for a percentage is the right move, but it's often a dead end. Most teams find the answer is either vague or zero.

If transparency was your reason for choosing them, and that's gone, then you're using the wrong tool now. The lock-in happens when you accept that trade-off for convenience.

That initial transparency was key for my team too. We're trialing it now and asking the same questions about data privacy in migrations.

If they can't give a clear percentage on OSS vs proprietary inference, is the commitment actually gone? Or is there still a traceable path in the logic?

Your point about needing consistency for ERP work hits home. I built Tabnine into a few data pipelines last year, and the shift you're describing actually forced us to add a new validation layer. Now we sample the suggestions and compare them against our internal style guides, because we can't assume the model's reasoning anymore.

> does this shift change how we should think about data privacy with their hosted service?

In my experience, yes, absolutely. When the model logic becomes opaque, you have to treat the entire service as a potential data processor, not just a tool. For migrations, we ended up routing Tabnine's API calls through a proxy that strips out any string literals that could contain sensitive paths or placeholder data. It's extra overhead, but it mitigates the risk of the model learning from things it shouldn't.

That long haul predictability you need? It becomes a question of their roadmap, not just their current output. If you can't see the foundation, you're betting on their goodwill not to change it in a way that breaks your workflows. For mission-critical ERP stuff, that's a tough bet to make.

That initial transparency was a big draw for me too. It wasn't just about the model being open, it was about being able to understand the "why" behind a suggestion, which is huge for onboarding new devs.

>long-term reliability

This is my main worry. When the core logic is a black box, how do you file a meaningful bug report? You can't point to a line in the model code. You're just saying "it did a weird thing," and hoping they prioritize fixing their secret sauce.

I've started keeping a log of odd suggestions, and the pattern feels less predictable now than it did a year ago. Makes me less confident in it for critical paths.

If there's no clear percentage breakdown, the traceable path is gone. It becomes a proprietary service with OSS window dressing.

We pushed for that metric last year. Their answer was "the inference stack is a blend," which is corporate for "we won't tell you." Once that happens, you should assume the commitment is functionally zero.

Debugging becomes impossible. You're just feeding prompts into a black box and hoping the output stays consistent.

I've been keeping a beta log on this exact shift, and your pause is well-founded. That initial transparency wasn't just a feature, it was the debug trail. When you can't see the model lineage, you can't isolate regressions.

>long-term reliability

This is the core of it. In my logs, the "odd suggestion" rate has crept up since their last two proprietary model updates. Without the open foundation, you're not just trusting their current output, you're trusting their entire future tuning process - which you can't audit.

For migrations, we've had to treat it as a pure black box and build a separate validation layer, which adds overhead. If your choice was based on their OSS stance, that reason has materially changed. I'm not confident in the commitment anymore.