Tabnine, or a code assistant that stopped being for everyone

Tabnine, or a code assistant that stopped being for everyone

Tabnine was for years among the first code completion assistants and long the most popular alternative to offerings from cloud vendors, largely thanks to its emphasis on privacy.

That position changed, and the change is fundamental enough to open this text. The free plan was withdrawn in early 2025, and the plan for individual developers disappeared in the autumn of the same year. Today the offering covers company plans alone, billed annually.

If you are looking for an assistant for your own projects or for work as an independent, this tool is no longer for you, and you can skip straight to the alternatives section. If you represent a company with requirements about where code goes, below I describe what you get for the price.

A second change followed it, a fresher one. On 30 July 2026 the vendor was acquired by Tricentis, a supplier of software testing tools, which announced it would build the Tabnine context engine into its own platform. The product still sells under its own name and with the same offering, but under an annual contract it pays to ask about the roadmap in writing, since priorities often shift after an acquisition.

Privacy as the product

The whole proposition rests on one thing: code does not leave your control, and the vendor does not retain it.

Requests are processed ephemerally, solely to generate a suggestion, and discarded immediately afterwards. There is no store accumulating your code and no training of models on what your developers wrote.

That distinction deserves understanding, since this category has several levels. An assurance that code is not used for training is common. An assurance that it is not stored at all is rarer. The ability to run everything without an internet connection is exceptional.

Four deployment variants are available, ordered from the most convenient to the most closed. A service managed by the vendor. A deployment in your private cloud. A deployment on your own servers. And a variant entirely cut off from networks, with no outbound connectivity whatsoever.

That last one is the genuine differentiator here. A financial institution, a defence sector organisation, or a team working on classified data cannot use a tool sending anything outward, and for them the choice is considerably narrower than code assistant comparisons suggest.

What you get beyond completion

The offering expanded beyond suggesting next lines, and knowing where it stands today pays off.

Code completion works in the editor and is where everything began. Suggestions account for project context rather than the current file alone.

A task performing agent is the newer layer and the subject of the more expensive of the two plans. It covers changes spanning many files, test generation, and reviewing changes before merging.

Code review works to rules set by the organisation rather than to general principles alone. That matters in companies with their own standards, where a generic tool flags irrelevant things and misses important ones.

Adapting to your own code deserves separate mention. The model learns patterns from your repositories, so suggestions start resembling the way your organisation writes rather than an averaged style from public code.

A caveat: that last one works best with a large and consistent codebase. On a repository of a dozen or so thousand lines, written by three people in three styles, the gain is small.

Pricing and who this is for

Billing runs per person per month with an annual commitment. The plan with code completion and chat grounded in your repository costs 39 dollars per person per month, and the plan covering the agentic layer and the context engine costs 59. Both rates sit noticeably above competitors aimed at individual developers. Closed deployments, the air gapped variant included, are priced individually.

The per person rate is not the whole bill, though, and that is the thing the price list records with an asterisk. Unlimited usage covers working on your own model alone, run on your premises or behind your own cloud endpoint. Reach for the models the vendor supplies and a charge for a token quota reserved up front joins it, computed from the model provider prices plus a five percent handling fee.

The conclusion is simple and deserves stating without hedging. For a team of ten the annual cost runs into thousands of dollars, so the justification must lie beyond suggestion quality alone. That justification is usually compliance: a requirement that code not leave your infrastructure, which cannot be met otherwise.

If you have no such requirement, competitors offer comparable quality for less. That is not a charge against the product but a description of the market: the vendor deliberately left the segment where price competition is fierce and focused where it holds an advantage.

Price the self hosted variant too. Deploying on your own servers means hardware, upkeep, and updates, so items absent from a managed service join the per person rate.

An annual commitment adds one more thing worth noting: no quick way out. A tool bought for a year has to be used for a year, even if after two months it turns out the team does not touch it. That makes a trial period before signing more important here than with monthly billing, where a mistake costs one month.

What an air gapped deployment means

The thread deserves developing, since the term sounds unambiguous while in practice covering several things at once and bringing concrete obligations to your side.

The model runs on your hardware, so you need graphics cards. That is the first cost item and simultaneously the most often underestimated, since serving a few dozen developers requires more than one machine.

Updates stop happening by themselves. A new model version or a security fix arrives as a package somebody must install, test, and deploy. In an air gapped environment that process is often formal and slow.

Diagnostics are yours too. When suggestions stop working there is no remote support looking at your logs, so somebody in the organisation must understand how it works.

In return you get something no contract provides: certainty following from the physical impossibility of sending data out. That is a qualitative difference from retention assurances, and under some formal requirements the only one that counts.

A practical hint for such a deployment: establish at the start who on your side owns its upkeep, and count their time in the cost. A solution without a named owner works until the first failure and then becomes a tool nobody fixes.

Whatever tool you pick, it also pays to check what actually sits in the repository and could reach an index. This one command usually produces surprises.

git ls-files | grep -iE '\.(env|pem|key|p12|pfx)$|secret|credential'
git log --all --diff-filter=A --name-only --pretty=format: | sort -u | grep -iE '\.env'

The second command matters more than the first, since it shows files that ever entered history, even if they are absent from the working tree today. A file deleted a year ago still sits in history and is still readable by anything that indexes the repository.

Keep the exclusion list in the repository, since it carries across tools when you change vendors.

.env
.env.*
**/*.pem
**/*.key
infra/secrets/
test-data/production-*.json

Completion versus an agent

The split into two plans corresponds to two different ways of working, and knowing which you need pays off, since the price difference is substantial.

Completion works in the background while you type. It suggests the end of a line, the next statement, sometimes a whole function. It does not interrupt, requires no instructions to be phrased, and is what raises typing speed by a dozen or so percent without changing how you work.

An agent works differently. You describe a task, it makes changes across several files, runs tests, and returns with a result. That changes how you work rather than merely how fast, and with well described tasks the gain is considerably larger.

Settle this from how the team works today rather than from impressions. The answer can be computed from repository history.

git log --since="3 months ago" --pretty=format:%H --no-merges |
  while read h; do git show --stat --format= "$h" | tail -1; done |
  awk '{print $1}' | sort -n | uniq -c

The distribution of files per change states plainly which plan you need. A predominance of one and two file changes means the team gains most from completion while typing. A large share of changes spanning five or more files, migrations or adding a field that runs through the whole application for instance, means the agent layer has something to show.

Do not buy the more expensive plan hoping the team will start using it. The agentic layer requires changing habits, and habits change when somebody demonstrates it works rather than when it appears in a licence.

Tabnine against the alternatives

The last row deserves honest consideration, since for individuals it is today a real answer to the same question. A model run through Ollama and wired into an editor gives code completion without sending anything outward, at a cost in suggestion quality and hardware requirements.

Choosing between the first row and the rest comes down to one question: do you have a formal requirement or a preference. A requirement narrowing vendors to those offering air gapped deployment justifies the price difference. A preference that code not travel the internet is understandable and cheaper to satisfy another way.

How to evaluate such a tool

For a company scale purchase, an evaluation method beyond a feature list pays off, since those look similar everywhere.

Start by asking about retention in writing. Not whether code is used for training, but whether it is stored, for how long, and where. An answer of "we do not use it for training" does not answer that question.

Check what exactly leaves your network in the chosen variant. Even with a deployment on your own servers, some solutions contact the vendor about licensing, telemetry, or updates, and knowing exactly what is transmitted pays off.

Measure suggestion quality on your own code rather than on examples. A week of two people working on a real project says more than any comparison, since it measures your language, your libraries, and your way of writing.

For that week to mean anything, record the result in numbers rather than impressions. A simple log kept by the participants suffices.

date,person,task,accepted,rejected,minutes
2026-08-03,anna,payment form,34,51,95
2026-08-03,marek,endpoint migration,12,9,140

Two columns settle it. An acceptance share below a third means the tool gets in the way more than it helps, since every rejected suggestion costs a fraction of a second of attention. Task time compared with a similar task from before the rollout tells you the rest.

Price the full cost, deployment and upkeep included. With an air gapped variant, hardware, its replacement, and a person to run it join the bill.

One last thing: check what happens after a contract ends. A code assistant creates no data to migrate, so leaving is cheap, and that is an argument for trying rather than for postponing the decision.

Common mistakes

The first is looking for an individual plan. None has existed since autumn 2025, and material describing cheap individual plans is out of date.

The second is confusing not training on code with not storing code. Those are two different things and deserve asking about separately.

The third is buying for privacy without a formal requirement. If nobody demands an air gapped deployment, competitors offer comparable quality for less.

The fourth is skipping upkeep costs on a self hosted deployment. Hardware, updates, and operations are items absent from a managed service.

The fifth is evaluating from examples rather than your own code. Suggestion quality depends on language and libraries, so general comparisons say little.

The sixth is expecting a large gain from model adaptation on a small codebase. That feature works well with a large and consistent repository. On a dozen or so thousand lines written in three styles it changes next to nothing.

The seventh is signing an annual contract without a trial period. A mistake then costs a year rather than a month, so testing on a real project before deciding is worth considerably more here than usual.

FAQ

Does Tabnine still have a free plan?

No. The free plan was withdrawn in early 2025, and the plan for individual developers disappeared in the autumn of the same year. Only company plans remain, billed annually.

How does it differ from other code assistants?

In the option of a deployment entirely cut off from networks, with no outbound connections, plus an assurance that code is not stored after a suggestion is generated. That narrows the field of real alternatives for organisations holding such a formal requirement.

Does code genuinely never leave the company?

In the air gapped variant there are no outbound connections, so there is nothing to send it with. In the managed variant code reaches the vendor's service, is processed ephemerally, and discarded. Under a formal requirement, ask for that in writing.

What should an individual choose?

This tool is no longer available outside company plans. With an emphasis on privacy, consider a locally run model, through Ollama for instance; with an emphasis on suggestion quality, options such as Cursor or GitHub Copilot.

How do I check whether it is worthwhile?

Through a week of two people working on a real project rather than on documentation examples. Measure how many suggestions get accepted and whether they match your style. Leaving a code assistant is cheap, since it leaves no data to migrate, so a trial costs less than lengthy deliberation.

The privacy approach is described on the vendor's site, and plan details in the price list.