The Cheap Model That Might Change Everything: What Happens When "Good Enough" Becomes "Almost Best"

For two (three?) years, serious agentic coding meant paying frontier prices (and keep increasing!!) to a few closed labs. DeepSeek 4, and V4.1 Flash in particular, suggests that rule is about to break.

For the past two years, agentic software development has followed a simple rule: if you wanted an AI that could reliably navigate a codebase, run commands, fix failing tests and iterate without supervision, you paid frontier prices to a handful of American labs. Cheaper and open-weight models existed, but they fell apart on exactly the long, messy, multi-step tasks that make coding agents useful.

That rule may be breaking. The next few months could be remembered as the moment agentic coding stopped being a premium service and became a commodity.

A Flash model that beat its own flagship

The story starts with DeepSeek V4, and it accelerated quickly. At the end of July, DeepSeek promoted V4-Flash from preview to official release, and a model with 13B activated parameters beat the 49B-active V4-Pro preview on all nine agentic benchmarks DeepSeek publishes. On DeepSeek's own table, that 0731 build was already close to Anthropic's previous flagship: 82.7 on Terminal Bench 2.1 against 85.0 for Opus 4.8, and 54.4 on DeepSWE against 58.0.

I'm currently

Then came V4.1 Flash. It shipped on 10 September 2026, and DeepSeek is retiring its own V4 Pro because the smaller model beats it on most tests. According to DeepSeek, at maximum reasoning effort V4.1 Flash outperformed OpenAI's GPT-5.6 Sol and Anthropic's Claude Opus 5 on Terminal-Bench 2.1. The headline numbers: Terminal-Bench 2.1 at 90.6, DeepSWE at 74.2, a Codeforces rating of 3471, and HLE-with-tools at 63.9, just past Claude Opus 5's 63.6.

I've been working on it for a week now, on a .NET 10 Core solution with more than 10,000 C# files, trying to push it further and further, and I have to say I'm honestly amazed, especially considering the cost! I don't want to advertise, but I'm currently using it through Ollama cloud, which costs less than the Deepseek API. I've also read that OpenCode cloud offers it at an even lower cost, but I haven't tried it yet because I prefer using Visual Studio 2026 or VS Code, at least for now.

What is interesting is where the gains came from. The model card describes a standard post-training recipe (SFT, RL and on-policy distillation) with no algorithmic changes; the substantive work went into the data pipeline, with large-scale automated synthesis of agent tasks and environments. In other words, agentic competence is turning out to be something you can train into a relatively small model, not something that requires trillion-parameter scale. That is a finding with consequences for the entire industry.

The price gap is not a gap, it is a canyon

Benchmarks alone would make this a good release. The pricing makes it potentially disruptive. Off-peak, V4.1 Flash costs $0.15 per million input tokens and $0.60 per million output, with peak hours doubling those rates. For comparison, Claude Opus 5 costs $5 per million input tokens and $25 per million output.

That is roughly a 20x to 40x difference per token, depending on the time of day. And agentic coding is precisely the workload where per-token cost matters most, because every tool result goes back into the context and the growing transcript is billed again on each turn. The architecture helps here too: a 20-layer encoder reads the input with just 8 billion active parameters, a 20-layer decoder writes the reply with 16 billion, and the KV cache shrinks to 890 bytes per token, about a quarter of V4 Flash's. Agent work is input-heavy, and this model is built to read cheaply.

When a task that cost ten dollars costs thirty cents, the economics of how you use agents change qualitatively. You stop rationing. You run five attempts in parallel and keep the best one. You let an agent grind on a refactor overnight. You put an agent on every pull request instead of only the ones that seem important.

The part nobody could do before: owning the model

Price is one axis. Control is the other, and this is where things get genuinely new. DeepSeek releases its weights under an MIT license, which means a near-frontier coding model is something you can run on hardware you own, with no API, no data leaving your network, and no provider swapping the model under you.

This is where Salvatore Sanfilippo, the creator of Redis, enters the picture. His project DwarfStar (ds4) aims to be the best way to run a few excellent large language models on consumer hardware, meaning hardware people can actually own, through a small native inference engine optimized first for DeepSeek V4 Flash and V4.1 Flash. It is deliberately narrow: rather than being a general-purpose runner, it specializes in a handful of models and tests everything together, from tool calls to KV state to a built-in coding agent. It targets Metal on Macs with 96 GB or more, NVIDIA CUDA with the DGX Spark as its main goal, and ROCm on Strix Halo systems such as the Framework Desktop.

The practical results are striking. For V4 Flash, a first run on a 96 or 128 GB machine starts with the Q2 quantization, and SSD streaming lets even machines without enough RAM run it at a decent speed. The heavier V4.1 Flash is more demanding: Q2 runs with SSD streaming on a single 128 GB Mac or Spark, or fully resident across two Macs or two Sparks linked via RDMA. The included server also works with Pi, OpenCode, Codex CLI or Claude Code, so developers can keep their existing tooling and swap the brain underneath.

There is a meta-lesson in the project itself. Sanfilippo is open that ds4 is developed with strong assistance from AI coding agents, with humans leading the ideas, testing and debugging. He even suggests users treat coding agents as the interface to the project, asking them to tune performance for their specific hardware. The tool for running local coding agents is itself a product of coding agents. That feedback loop is exactly what becomes explosive once the agents are cheap and local.

Why the next few months matter

Put the pieces together. A near-frontier agentic coding model exists. It costs a small fraction of the frontier per token. Its weights are free to download. And there is now a focused, well-engineered path to running it on a single high-end workstation that a freelancer or a small company can buy outright.

Any one of those facts would be notable. Together they threaten the business model that has defined the field: the assumption that serious agentic coding means a recurring subscription to a closed lab. Expect startups to rebuild their agent products on open weights, enterprises with strict data policies to finally approve coding agents because the model never leaves the building, and frontier labs to face real pressure on pricing for the "workhorse" tier of their lineups.

The honest caveats

It would be a mistake to declare the frontier dead. Most of these numbers are vendor-reported, and the picture changes on harder tests: V4.1 Flash drops to 30.0 on Terminal-Bench 3.0, handling standard terminal tasks well but struggling with the more demanding agentic suite. On pure reasoning without tools it also trails: on Humanity's Last Exam it scores 36.8, well under GPT-5.6 Sol at 44.5 and Claude Opus 5 at 56.3. Even its better results leave room for doubt; one analysis notes that a 54.8 on Automation-Bench means it still fails roughly half of complex workflows.

There are practical issues too. The hosted API raises data-governance questions for some organizations, and local hardware capable of running the larger model is still a serious investment. And the frontier labs will not stand still.

But revolutions rarely require the challenger to be better. They require it to be good enough, much cheaper, and in the hands of more people. For agentic software development, DeepSeek 4 and projects like DwarfStar suggest we may be crossing that threshold right now.

A European view: the geopolitics of open weights

There is an uncomfortable question hanging over all of this, and for a European reader it cannot be avoided: should we be building on Chinese models at all?

Let us start from reality rather than wishful thinking. Europe sits firmly within the American sphere of influence, and for the foreseeable future that is not going to change. Our security architecture runs through NATO, our cloud runs largely on American hyperscalers, our phones, operating systems and productivity suites are American, and the frontier AI labs we rely on are American. Talk of "digital sovereignty" is valuable as an aspiration, but Europe does not currently have the capital, the compute or the industrial scale to replace that ecosystem. Being part of the Western bloc is, at least for now, a given.

Accepting that, however, does not mean Europe should treat every technology coming from China as radioactive. The key is to distinguish between two very different things that often get lumped together under the same name.

A Chinese service is not the same as a Chinese model

Using a Chinese service means sending your prompts, your source code and your data to servers in the People's Republic, subject to Chinese law and outside any European oversight. That is a legitimate concern, and it is the reason several European regulators, starting with Italy's data protection authority, moved against DeepSeek's consumer app early on.

Running Chinese open weights is a different proposition entirely. The weights are a file. Once downloaded and executed on a workstation in Perugia, a server in Frankfurt or a GPU cluster run by a European or American provider, the model has no way to phone home, no account tied to Beijing, and no data flow leaving the infrastructure you control. The MIT license means no one can revoke your right to use it or change it under your feet. In a very literal sense, an open-weight model running locally is more under your control than any closed Western model you access through an API.

This is precisely why tools like DwarfStar matter beyond the technical achievement. They turn a model trained in China into a piece of European infrastructure, running on hardware owned by Europeans, governed by European law.

Pragmatism, not alignment

Refusing to use open Chinese models out of principle would not make Europe more Western; it would only make it poorer and more dependent. It would mean paying frontier API prices for work that a near-equivalent model could do on our own machines, and it would mean giving up one of the few levers that actually strengthens European autonomy: the ability to run capable AI without asking anyone's permission.

There is also a competitive argument. Open weights from DeepSeek, Qwen and others put pressure on prices across the whole market, including on American providers. Europe benefits from that competition as a customer, and it benefits even more if its own companies and researchers learn from, fine-tune and build on top of these models instead of watching from the sidelines.

The objections worth taking seriously

None of this means the risks are imaginary. Weights are opaque: a model can carry biases or subtle behaviours from its training that are hard to detect, and Chinese models are known to follow the official line on politically sensitive topics. Some security researchers also worry about models being trained to insert weaknesses into generated code, a risk that is hard to rule out for any model, but one that a geopolitical rival has more motive to exploit. And there is a political dimension: in a period of tension between Washington and Beijing, European companies that depend heavily on Chinese technology could find themselves caught in future trade or export restrictions.

These concerns argue for caution, not for a ban. The sensible response is the same one we should apply to any model, Western or not: run it on infrastructure we control, keep humans reviewing what goes into production, test it independently, and never let a single supplier become irreplaceable. Used this way, open Chinese models are not a threat to Europe's place in the West. They are one more tool that lets Europe be a little less dependent on everyone.

---

Sources

• DeepSeek-V4.1-Flash model card (Hugging Face)
• DeepSeek V4 Flash 0731 official release (Hugging Face blog)
• DeepSeek V4.1 Flash: pricing, benchmarks, and what changed (eesel)
• DeepSeek-V4.1-Flash outpaces GPT-5.6 Sol on some agentic tests (TheElec)
• DeepSeek V4.1 Flash: features, benchmarks, pricing (DataCamp)
• DeepSeek-V4.1-Flash: more efficient prefill for coding agents (Baseten)
• Claude Opus 5 pricing (eesel)
• DwarfStar / ds4 by Salvatore Sanfilippo (GitHub)

The Quiet Disappearance of the Programmer: AI Coding Agents

A quick look at where AI coding agents actually stand today, what the data says about their effect on the software engineering profession, and a few scenarios for where this goes next.

A job that is changing faster than its job title

Ask a software engineer in 2026 what they did yesterday, and there's a good chance the honest answer is: "I reviewed what an AI wrote." (!). Tools like Claude Code, Cursor, GitHub Copilot's agent mode, OpenAI's Codex-based agents, and autonomous systems such as "Devin" no longer just autocomplete a line — they take a ticket, plan the work, write across multiple files, run the tests, and open a pull request. The title "programmer" hasn't disappeared from job boards, but the day-to-day activity behind it has shifted dramatically, and the shift is accelerating.

This isn't speculative marketing anymore. It's showing up in hard numbers, in the public statements of the people building these systems, and in hiring data.

Where the technology actually stands

The clearest way to track progress in agentic coding is a metric popularized by the AI safety research group METR: the length of a task an AI system can complete independently, with a reasonable success rate. METR's research has shown this "time horizon" has been doubling every few months — models that once needed hand-holding for a five-minute task can now often handle multi-hour, multi-step engineering work with minimal supervision. Extrapolated even conservatively, that trend implies agents capable of tackling week-long projects within a small number of years.

The people at the frontier labs are saying so publicly and bluntly. In September 2026, Anthropic CEO Dario Amodei stated that he personally no longer writes code, and predicted that AI could replace human software engineers within roughly six to twelve months for large classes of programming work. Notably, in that same window, Amodei — joined by OpenAI's Sam Altman — also called for a deliberate slowdown in frontier AI development, a striking signal from the executives with the most direct visibility into these systems' trajectories: they are moving fast enough to worry the people building them.

The gap between the frontier and the daily reality

It would be a mistake, though, to read the frontier demos as the median experience. Stack Overflow's 2026 developer survey found that AI tool usage among professional developers has reached roughly 84%, yet genuine trust in the accuracy of AI-generated code remains remarkably low — only a small single-digit percentage of developers say they fully trust it. Most describe a familiar pattern: the AI is fast and often right, but confidently wrong often enough that every output still needs a human who understands the system well enough to catch a hallucinated API, a subtly broken edge case, or a security hole introduced three files away from where anyone was looking.

In other words, the bottleneck hasn't disappeared — it has moved. Writing code was never really the hard part of software engineering; understanding the problem, the system, and the consequences of a change always was. Right now, that understanding is still a human responsibility, even when the typing isn't.

The profession is bifurcating before it's disappearing

Where the disruption is real and measurable is at the entry level. An August 2026 update from Stanford's Digital Economy Lab ("Canaries in the Coal Mine?") found that the employment gap between young workers in AI-exposed occupations — software development prominent among them — and their less-exposed peers has widened to about 19%. The researchers were careful to note this isn't evidence of mass, economy-wide displacement; overall employment hasn't collapsed. But it is clear evidence that the traditional entry point into the profession — the junior developer who learns by doing the small, well-specified tasks — is the part of the job that AI agents now do most easily and most cheaply.

That creates a strange dynamic: demand is rising for senior engineers who can specify problems precisely, review AI-generated systems critically, and take accountability when something breaks in production — while the traditional pipeline that used to produce those senior engineers, by having them cut their teeth on junior work, is eroding. It's less that "programming" is vanishing and more that the career ladder into it is losing its bottom rungs.

Four scenarios for where this goes

Nobody can say with confidence which of these plays out, and elements of all four could coexist in different corners of the industry. They're offered here as a map of plausible futures, not a prediction.

1. Full autonomy for routine software

If the METR capability curve keeps compounding, agents could handle most conventional application development — CRUD apps, internal tools, routine features, boilerplate integration work — largely unsupervised within a few years. Under this scenario, "programmer" as a job of writing code mostly disappears for standard software, surviving chiefly in novel, safety-critical, or highly ambiguous domains where human judgment about what to build (not how to type it) remains the scarce resource.

2. A plateau, and augmentation rather than replacement

Scaling has hit friction before — diminishing returns on training data, the cost and reliability ceiling of long autonomous task chains, and the accumulating "review debt" from AI-generated code that Stack Overflow's trust-gap data hints at. In this scenario, agents plateau as extremely capable but imperfect collaborators, much as compilers, IDEs, and high-level languages transformed programming without eliminating programmers. The job persists, redefined around specification, architecture, and verification.

3. A bifurcation that causes its own talent shortage

If junior roles keep disappearing at the current pace, the industry may simply stop producing experienced engineers over the next decade — because there's no longer a normal path to becoming one. This could quietly create a scarcity of senior talent precisely as demand for skilled oversight peaks, forcing companies and universities to invent new apprenticeship-style paths built around supervising, auditing, and correcting AI systems rather than writing code from scratch.

4. A trust and regulatory correction

A handful of high-profile security incidents or system failures traced to autonomously generated code could trigger the same kind of regulatory response seen in other safety-critical industries: mandatory human sign-off, liability rules tied to code provenance, audit requirements for AI-assisted systems. In this scenario, economics and law reassert the value of verified human judgment, at least in regulated or high-stakes software, slowing the shift even if the underlying technology keeps improving.

The honest conclusion

The evidence right now supports a specific, narrower claim rather than the sweeping one: the entry-level, routine-task version of "programmer" is disappearing quickly, while the version of the job built on judgment, specification, and accountability is becoming more valuable, not less — for now. Whether that holds depends on whether AI capability keeps compounding at its current rate or hits the kind of wall that's stalled other technologies at this stage. The people building these systems are themselves divided enough on that question to be publicly calling for the brakes to be applied. That alone is worth paying attention to.

Further reading:

• METR — Measuring AI Ability to Complete Long Software Tasks
• Forbes — Anthropic CEO Dario Amodei Calls For A Slowdown In Frontier AI
• Yahoo Finance — Anthropic CEO Predicts AI Models Will Replace Software Engineers In 6-12 Months
• Stanford Digital Economy Lab — Canaries in the Coal Mine? (August 2026 update)
• Stack Overflow — Closing the AI Trust Gap for Developers

Free PHP, HTML, CSS, JavaScript editor (IDE) - Codelobster PHP Edition

For valuable work on creation of sites you need a good comfortable editor necessarily. There are many requiring paid products for this purpose, but we would like to select free of charge very functional and at the same time of simple in the use editor - Codelobster PHP Edition .

Let us consider some important possibilities and advantages of this program:

• All code highlights depending on a type, the also mixed code is thus supported, so the area of HTML will be highlighted as HTML, PHP as PHP, and Javascript as Javascript in a the same file. Thre is possibility of choice from color schemes, including popular IDEs.
• Powerful autocompletion for HTML, PHP, CSS and Javascript, including HTML5 and CSS3. For PHP the structure of project is fully recognized, and the complete list of methods falls out in the proper places.
• HTML/CSS inspector on the type of Firebug, which allows easily to correlate the selected elements of page with a code and proper style.
• Context help on all supported languages. By pressing F1 key the page with detailed description for current tag, attribute or function will be opened.
• PHP debugger. PHP debugger allows to execute PHP scripts incrementally, watching the values of all variables in every line.
• SQL manager allows to produce all necessary actions with a database - to add, delete, edit a structure and records in tables, to export data, execute SQL queries. Highlighting and autocompletion works for SQL files also.
• Support of FTP allows to work straight with a remote server and to do all necessary changes with files;

The portable option allows to use editor without the preliminary installation.

Other useful utilities: pair highlighting, possibility of blocks selection, collapsing, tooltips, navigation on descriptions of functions and included files at withholding of the key of CTRL, viewing of structure of files and project, preview in a browser, book-marks, and all other standard possibilities for work with a code.

Also there are special plugins for work with:

• CMS: Drupal, Joomla
• PHP frameworks: CakePHP, CodeIgniter, Symfony, Yii 
• JavaScript libraly: JQuery
• WordPress blogging engine
• Smarty template engine

Developer	Codelobster Software
Web Site	http://www.codelobster.com/
Language	English, Russian, German, Spanish, French, Portuguese
Supported OS	Windows 2000, Windows XP, Windows Vista, Windows 7

Git push error: RPC failed; result=55, HTTP code = 0

Today I had some problem pushing my data on a git repository.
The data was some MB and the error message when I did the push was

   fatal: The remote end hung up unexpectedly
   error: RPC failed; result=55, HTTP code = 0

If you get this error, it's because you are trying to push a large delta to the repository and your push buffer is not big as needed.

The solution is to increase your buffer size with this command:

   git config http.postBuffer 1024000

This will add a line in your config file with the specified value.
Set the value to what you need.
The http.postBuffer configuration value is exactly the maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system (source).

EDIT: 2014/02/06
An user (Matej Sychra) in a commet report you need a value bigger than 1024000 for lager repository.
Thanks Matej!

Automapper upper and lower case properties mapping

Yesterday I face some sort of common problem: mapping an class to another one (a DTO).
The first class was a generated entity using Entity Framework 4.
The database is a legacy one, and of course untouchable and the name of the columns are are all upper case.
To map these entities to a DTO class, I'm using best tool for .NET on the way: I'm talking about AutoMapper of course.
As you probably know, AutoMapper is a convention-based object-object mapping library.
In a basic usage, AutoMapper maps your property automatically to another one, if the property have the same name.
In my case this convection (the default one) doesn't work because of the upper-case properties, different by the properties of the DTO.

The solution.

AutoMapper, as said is convention based, so you have simply to say to it, to consider one said of the mapping with upper-case property.

How to do it?
First of all write your Naming Convention class:

public class UppercaseNamingConvenction : INamingConvention
{
   private static readonly Regex _splittingExpression
         = new Regex("(\\p{Lu}0-9]+)");

   #region Implementation of INamingConvention

   public Regex SplittingExpression
   {
      get { return _splittingExpression; }
   }

   public string SeparatorCharacter
   {
      get { return string.Empty; }
   }

   #endregion
} 

As you can see, we use a splitting regular expression with a upper case specification.

The next is to define an Automapper profile to specify a different configuration usage.
Write the code below where you configure your application at startup.

Mapper.CreateProfile("first_profile"
   , expression =>
   {
      expression.SourceMemberNamingConvention
         = new UppercaseNamingConvenction();
   });

Mapper.CreateProfile("second_profile"
   , expression =>
   {
      expression.SourceMemberNamingConvention
         = new UppercaseNamingConvenction();
   });

So you will have two profiles: "first_profile" and "second_profile".
To use this configuration, simple specific the profile when you define a mapping strategy:

Mapper.CreateMap<DtoClass, MyDbEntity>().WithProfile("first_profile");

Of course the strategy is the same if you have lower case properties: you have only to change the regular expression.

Have a nice mapping ;)