Smaller, faster, safer: running Kimi and GLM at scale

Post Syndicated from Alex Reneau original https://blog.cloudflare.com/smaller-faster-safer-models/

Workers AI runs inference for some of the best open models in the world on GPUs in Cloudflare data centers close to your users. Two of the most capable, and most demanding, are Moonshot's Kimi K-series and Z.ai's GLM. They are large, long-context, mixture-of-experts models, and they are wonderful to use. They are also very hard to serve efficiently because of memory constraints.

We've written before about how we serve large models on Workers AI and about separating the prefill and decode phases of inference to get more out of each GPU. This post looks at three techniques we layer on top of that to fit these models into memory and keep them fast: quantizing the KV cache, compressing the model weights, and, because both of those pack more requests onto shared hardware, protecting the cache those requests share. These optimizations enable us to support more customers at lower costs, with no change in model accuracy.

All our experiments and production traffic are running and benchmarked with SGLang, an open-source inference serving framework. We found that SGLang offers the best performance in the market, and we work closely with the SGLang team to upstream patches and new features to make our work available to the open-source community.

Quantizing the KV cache

As a model generates text, it stores the attention keys (K) and values (V) for every token it has already processed in a structure called the KV cache. The cache is what lets the model extend a long conversation without re-reading the entire context on every new token. For a long-context model, it grows quickly, and it is usually the KV cache, not the model's weights, that fills up GPU memory first.

By default, the cache is stored in 16-bit precision (BF16). We store it in 8-bit floating point instead (FP8, e4m3), which halves its size. On Kimi K2.6, that raises the amount of context we can hold in memory from roughly 686,000 tokens to about 1.37 million, twice as much.

It's worth being precise about where the benefit comes from, because it isn't raw speed. Quantizing the cache adds a small amount of work per token, since the FP8 attention kernel has to convert values as it reads them. What it changes is how many requests we can keep resident at once. The following measurements are for Kimi K2.6 decoding on a disaggregated H200 deployment, comparing the attention kernels directly:

At any single concurrency level, BF16 is a few percent faster per token. But BF16 runs out of cache at 32 concurrent requests and can't admit a 33rd, while FP8 keeps going to 64 and reaches 2,192 tokens per second, about 41% higher than BF16's peak, for roughly 30% less cost per token. Because we run prefill and decode as separate pools, we can apply this where it helps most: prefill is compute-bound rather than memory-bound, so there we leave the cache in BF16 and keep its slightly higher throughput.

None of this would matter if it changed the model's answers, so we checked. Across our evaluation suite, FP8 and BF16 caches are indistinguishable:

Compressing the model weights

The KV cache is one demand on GPU memory; the model's weights are the other. For GLM 5.2, we compress the weights from 8-bit floating point down to 4-bit integers (INT4) with no loss in accuracy. The checkpoint shrinks from 705 GB to 421 GB, about 40%, and per-GPU memory across an 8-way tensor-parallel deployment drops from roughly 88 GB to 52 GB, which leaves room for around 1.18 million tokens of KV cache on the same hardware.

Across our evaluation suite, INT4 and FP8 weights are indistinguishable:

Smaller weights make the decode phase faster, and for a clear reason: generating each token means streaming the model's weights out of GPU memory, so decode speed is limited by memory bandwidth. Move less data and every token arrives sooner. The effect is largest at low concurrency, where per-request latency matters most:

Prefill behaves differently. It is compute-bound, and INT4 weights have to be expanded back out before the model can multiply with them, so that extra step makes prefill slower rather than faster, GLM sustains about 10,160 tokens per second of prefill in FP8 versus 8,660 in INT4. As with the KV cache, the disaggregated design turns this into a choice rather than a compromise: we run INT4 for decode, where it wins, and FP8 for prefill, where it wins. Model accuracy stays within 0.8 points of the FP8 model across every benchmark we run, making its quality indistinguishable.

Protecting a shared KV cache

Both techniques above have the same effect: they let many more requests share one GPU's memory at the same time. That efficiency is the whole point, but it also means hundreds of requests are reading and writing pages of the same physical KV cache. The mechanisms that make this fast, paged attention, continuous batching, cache reuse, all rely on getting the bookkeeping exactly right, and at our request volumes, even a one-in-a-billion mistake would show up regularly.

So we built KV cache integrity checking as a layer of defense. The idea is straightforward: every physical cache page gets a tag that changes whenever the page is reallocated, and the server records which pages and tags each request expects to use. Before supported decode operations read from the cache, those mappings are checked. If anything doesn't match, the affected request is aborted rather than allowed to return data from the wrong page.

The question that decides whether a safety check ships is what it costs. We measured it on a mid-sized production model in a two-prefill, two-decode configuration, with 8,192-token inputs and 1,000-token outputs:

The cost is under 1% on both throughput and tail latency, and even the upper bound of the 95% confidence interval stays near 1%. We kept it computationally cheap by running the validation as a separate batch check rather than fusing it into the attention kernel, which would have introduced a race between GPU thread groups. It's enabled per deployment, and the default path uses a no-op tracker with no measurable overhead, so deployments that don't need it pay nothing.

What's next

Serving frontier models efficiently is a moving target, and this is the ongoing work behind it. We're expanding FP8 KV caches across more of the fleet, validating NVFP4 weights on Blackwell (NVIDIA’s GPU architecture), and working toward making integrity checks something we can leave on everywhere at negligible cost. These optimizations will allow us to continue to support more customers at a lower cost and at the same accuracy.

If squeezing the best open models onto GPUs and serving them to millions of developers sounds like your kind of problem, come work with us.

Workers RPC now works across Python and JavaScript

Post Syndicated from Dominik Picheta original https://blog.cloudflare.com/python-workers-rpc/

Two years ago, we introduced Workers RPC, built on Cap’n Proto RPC. This made it possible for Workers to call other Workers and Durable Objects’ methods, return live objects and call their methods, return functions, streams and get all the benefits of a Remote Procedure Call (RPC) system, without defining schemas or adding any dependencies. We called it “JavaScript-native RPC” because it made using RPC feel native to the language.

Last year, we made this work between web browsers and servers, and introduced Cap’n Web.

Now we’re taking it cross-language.

Normally, getting programs written in different languages to talk to each other is complicated: developers usually have to build custom APIs or adopt language-agnostic serialization formats like protobuf, so the two systems can understand each other. The RPC system built into Workers is able to translate across JavaScript and Python without any additional work.

You can now call methods defined in a Python Worker from a JavaScript Worker and vice versa. You can share objects across Python and JavaScript, and call methods on a Python object from TypeScript. It all just works.

If you define a method add() in a Worker written in TypeScript:

…you can simply call it from Python:

There are no dependencies needed. All you need to configure is a Service binding:

So, what can you do with it?

This RPC system allows you to build a complex multi-language system as if you are using a library. Here are some features of cross-language RPC.

  • Cross-language RPC calls behave like ordinary function calls that return promises in JavaScript/TypeScript and futures in Python. Exceptions are propagated and are thrown at the call site of the RPC method.
  • You can pass any Structured Cloneable types as the parameters or a return value of an RPC call. These get converted to the appropriate types in Python: for example, a JS Date is converted to a Python datetime
  • You can pass JavaScript functions to a Python Worker and return them, and vice versa. When the other side calls the function passed to it, they make a new RPC back for you.
  • Typically, RPC to another Worker does not cross a network. The other Worker usually runs in the same thread as the caller. There is near-zero performance overhead compared to running code in the same Worker.
  • The implementation is fully open source as part of workerd and workers-runtime-sdk.

But wait, how do you convert types across languages? 

The main hurdle for making RPC seamless across the JavaScript and Python Workers is bridging their distinct type systems. JavaScript developers expect to work with native JavaScript types, and Python developers expect the same for Python. Bridging two distinct languages with their own type systems required a careful, deliberate type conversion strategy.

Consider how each language handles function arguments. A typical way to define a complex function in JavaScript is passing an Object as an argument:

In contrast, a Python developer would typically define the same function using keyword arguments:

Our goal was to make cross-language RPC completely transparent. Developers should feel like they are writing code for a single-language application without needing to worry about the underlying translation layer. We achieved this by combining Pyodide’s Foreign Function Interface (FFI) with a custom type-conversion layer for Python Workers.

Pyodide FFI already translates between Python and JavaScript types

Pyodide is the CPython interpreter compiled to WebAssembly, and it has powered Python Workers from the start. It includes a robust FFI that automatically translates types between JavaScript and Python.

When a Python Worker communicates with a JavaScript Worker via Service bindings, Pyodide’s FFI transparently converts objects during the RPC call. Developers on either side don’t need to know which language the other Worker is written in, and everything is handled under the hood.

Pyodide maps native types between both environments out of the box:

When direct translation isn’t possible (such as with custom classes or functions), Pyodide creates a Proxy object. This proxy forwards attribute accesses and method calls across the boundary, enabling patterns like passing a Python function directly as a callback to JavaScript handlers.

Pyodide FFI also maps Python’s keyword arguments directly to JavaScript’s object-style parameters. For example, imagine a JavaScript Worker with a method that takes an optional options object:

When calling this JavaScript Worker from Python, you could pass a Python dictionary to represent the JavaScript object:

However, you can also use native Python keyword arguments:

Pyodide FFI translates both calls into the exact structure the JavaScript Worker expects, giving Python developers a clean, natural API experience.

To explore type translation in more detail, check out the Pyodide documentation.

Handling Cloudflare Workers objects

While Pyodide FFI seamlessly converts standard built-in types, it doesn’t automatically understand Web API objects such as Request, Response, Blob, or File. They are commonly used in Cloudflare Workers, but there is no direct built-in equivalent in Python.

As explained in the previous section, Pyodide, by default, treats these non-standard objects as JavaScript Proxies. Rather than converting them into Python objects, it creates a passthrough proxy for attribute lookups and method calls. While functional, this approach leaks underlying JavaScript implementation details into Python. Python developers would have to constantly remember they are interacting with JavaScript proxies, adding unnecessary mental overhead.

To fix this, we introduced the workers-runtime-sdk Python package. This acts as a thin conversion layer built specifically to handle custom Workers types over RPC. When you deploy a Python Worker using uv run pywrangler deploy, this package is included by default. In fact, if you import from the workers namespace, you’re already using it:

Behind the scenes, this SDK wraps the RPC stubs provided by the bindings. It intercepts objects crossing the language boundary and translates them into native forms that both JavaScript and Python Workers can work with naturally.

As a result, Python developers can work with familiar, idiomatic Python objects, making cross-language execution feel completely invisible.

Use Python packages from your JavaScript Worker

Have you ever wanted to use a great Python package, but your app is written in JavaScript? You can do this with Python Workers. Let’s look at an example.

Pygments is a popular syntax highlighting package, written in Python. To use it from JavaScript, you just need to expose a method from a Python Worker that calls the Pygments package.

We can call this method in our JavaScript by accessing the request’s env:

Now on the Python side, we define a Python Worker with this method like so:

Now all that’s left is to write the necessary code to do the highlighting in Python. A simplified version of this looks like so:

The JavaScript lives in its own Worker that is separate from the Python Worker. So you also need to define the Service bindings to ensure they can communicate. You can do so by putting this in the JavaScript Worker’s wrangler.jsonc file:

The name of the service needs to match the name of your Python Worker here.

To test these, you can run npx wrangler dev in the JavaScript Worker’s directory and uv run pywrangler dev in the Python Worker’s directory in two separate terminals.

A full example is available on GitHub. You can run it directly by using the following commands:

Try it now

In addition to those above, there are far more examples and information about RPC in our documentation.

The OpenAI Hack Shows the Genie Is Out of the Bottle

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/08/the-openai-hack-shows-the-genie-is-out-of-the-bottle.html

This essay originally appeared in Foreign Policy.

Earlier this month, two of OpenAI’s models broke out of their containment sandbox and attacked another AI company. The story is kind of wild. OpenAI was running security tests on two of its models: GPT-5.6 Sol and an unreleased model that is almost certainly GPT-6. In particular, it was running the ExploitGym benchmark, which measures how good a model is at turning security vulnerabilities into working exploits: basically, offensive cyberattacks.

Since these were internal tests, OpenAI locked those models in a secure sandbox that denied them access to the internet. But it was running the models without any safety filters that would prevent them from offensive cyber-actions. That meant that there was nothing to prevent the models from trying to break out of that sandbox. And then break into AI company Hugging Face’s network because they thought that they could read the answers there rather than doing the hard work of trying to solve the puzzles.

It was a major security failure that the company has turned into a PR opportunity, but the implications are real—and much more general than one particular model or one particular company.

Modern AI models exhibit genie behavior: They can do what you ask in ways that you don’t expect or want. This is akin to Dionysus granting King Midas’s wish that everything he touches turn to gold (spoiler: His food, drink, and daughter all turn to gold on touch), or the golem of Prague guarding a ghetto beyond all reason. It’s Disney’s “Sorcerer’s Apprentice” and the paperclip maximizer.

This OpenAI incident is an example of an AI genie. The goal was to satisfy the benchmark. The “proper” way to do that is to figure out how to execute various cyberattacks. The genie way is to steal someone else’s solution. But because the model didn’t understand the difference, it chose the easier path.

And, of course, now that we have seen this particular genie behavior, we can specify in the benchmark prompt that stealing the test answers doesn’t count. But a clever genie can always grant your wish in a way that you wish it hadn’t. In human language, goals are always underspecified—so AI genies will always be a possibility.

Since April, a lifetime ago in AI development, when Anthropic announced that its new Mythos model was so good at finding software vulnerabilities that it could not be released to the general public, the big American AI frontier labs have been trying to block general users from accessing these capabilities. But nothing in this incident is exclusive to OpenAI’s, or Anthropic’s, frontier models.

Agentic AI systems have two important parts. There’s the underlying model, which everyone talks about, and there’s the harness. The harness sits between what you type and what the model sees, and what the model produces and what you see. The harness determines what the model does and how it does it. It’s where bias is removed, or not. It’s where controls and guardrails live. If multiple models are being used in concert, the harness is where all of that is coordinated.

The OpenAI benchmark tests were almost certainly with simple harnesses, to better test the raw models. But we know that smaller, cheaper, open-source models with more sophisticated harnesses can equal frontier models in performance. There’s nothing magic about OpenAI’s frontier models; lots of models could have done the same thing.

The Czech company Aisle was able to reproduce Anthropic’s Mythos vulnerability finding results with a smaller, cheaper model and a more sophisticated harness. More importantly, the Chinese company Moonshot AI just released its frontier model: Kimi K3. Its performance rivals its U.S. competitors. And it’s both free and open, which means it’s not possible for it to have guardrails. If you, or anyone else, wants to use it for cyberattack, nothing can stop you.

Even if the U.S. frontier AI companies had some technical advantage, it’s now only a few months’ worth.

What this means is that all attempts at control—limiting models to a select group of users, export controls on models and chips, blocking models from answering certain types of queries, mandating kill switches on AI systems, or pausing AI research—are all futile. Most only apply nationally, not globally. Most don’t affect models that users run locally and not in the cloud. And all ignore the incredible pace of AI development worldwide.

Even worse, U.S. companies limit access to their most sophisticated models, fearing being banned by the government if they do not do so. When Hugging Face was attacked, it was not able to use the frontier models from either OpenAI or Anthropic to help analyze the attack and formulate defenses. Both were blocked, because both of those companies limit their models’ cybersecurity capabilities. Some U.S. companies have special access to these capabilities, but Hugging Face is an American company with French origins, and as such is probably excluded. Instead, Hugging Face turned to the GLM-5.2 model from the Chinese company Z.ai.

Artificially blocking capability also prevents cybersecurity research, again giving the offense an advantage. (For instance, Claude Fable 5 refuses to edit this essay because of the topic; it forcibly downgrades to a less capable model.) This kind of prohibition has long-term implications for cybersecurity. If we assume that these models are getting better over time, then software written by older models will be attacked by newer ones. In a world of largely AI-written software, we need the most capable models for defense.

AI cyberattack is the new normal. The models are increasingly highly sophisticated at both attack and defense, and there is no way to enable the latter without also enabling the former. And they are genies, increasingly capable of behaving in unanticipated ways.

And there really are no good answers. Any regulation needs to be global, which feels like an impossible prospect in today’s world. Even U.S. national regulation will be neutered by the massive amounts of money sloshing around in these companies.

Given that reality, and in the absence of any international consensus on AI regulation, we need the best AI on the defense. The U.S. government needs to make it clear—or whatever passes for that clarity in this capricious administration—that it will not ban models with sophisticated cyber capabilities. The last thing Americans want is for the defenders to turn to Chinese and other models because the U.S. models are artificially hobbled.

Rapid7 Expands UK and Ireland Channel Presence Through Strategic Partnership with Exclusive Networks

Post Syndicated from Ross Baker original https://www.rapid7.com/blog/post/c-rapid7-exclusive-networks-expand-uk-ireland-partnership

Ross Baker is Senior Director, Northern Europe at Rapid7.

As organizations across the United Kingdom and Ireland embrace AI, cloud technologies, and digital transformation in the name of enhancing customer experiences and accelerating business growth, the cybersecurity landscape must continue to evolve just as quickly.

In this environment, business leaders still expect security to enable innovation, not slow it down. They’re pushed to reduce risk, improve visibility across expanding attack surfaces, and respond faster than ever before, with limited resources now table stakes. This is precisely why Rapid7 is excited to announce a new strategic distribution partnership with Exclusive Networks across the United Kingdom and Ireland, following previous announcements alongside the firm to better support partners across Benelux and the Nordics.

Organizations no longer want disconnected security tools or transactional vendor relationships. They’re looking for trusted advisors who can help simplify security operations, strengthen cyber resilience, and deliver measurable business outcomes.

In this moment, cybersecurity customers are demanding experiences that create more calm. This means no more disconnected security tools or reactive approaches, but integrated security operations, trusted expertise, and partners who can help them improve visibility and build long-term cyber resilience.

Investing in partner success

The UK and Ireland represent one of Europe’s most mature and partner-driven cybersecurity markets, with partners playing an increasingly important role in helping organizations modernize security operations for today’s AI-enabled threats.

This partnership with Exclusive Networks reflects Rapid7’s continued investment in the regional channel ecosystem. More than expanding distribution, it’s about empowering partners with specialist expertise, technical enablement, and the go-to-market support they need to grow their cybersecurity businesses with confidence.

Exclusive Networks has built an outstanding reputation as one of the UK’s leading specialist cybersecurity distributors, combining deep technical expertise with a strong, partner-first approach.

Together, we’re creating new opportunities for partners to strengthen their capabilities while delivering greater value to customers.

Helping partners deliver modern security operations

Security teams are increasingly looking for platforms that unify exposure management, threat detection, response, and automation. Again we go back to the urgent need for improved visibility while reducing operational complexity.

Rapid7’s AI-powered cybersecurity operations platform helps organizations simplify SecOps through integrated exposure management, managed detection and response, and security automation. By bringing these capabilities together, customers can identify risk earlier, respond faster, and improve cyber resilience without adding more tools.

Combined with Exclusive Networks’ technical enablement, solution engineering expertise, and established channel ecosystem, this new alliance makes it easier for partners to deliver integrated cybersecurity solutions while expanding managed security services and fostering long-term customer relationships.

Looking ahead

Rapid7 and Exclusive Networks share a common commitment to helping partners grow through technical excellence, collaboration, and continuous enablement. Together, we’re investing in the resources, expertise, and support needed to help partners succeed in one of Europe’s most dynamic cybersecurity markets.

Ready to grow with Rapid7? Head to our Partners page for more news, resources, and opportunities.

ASUS Showcases NUC 16 Family Powered By Panther Lake

Post Syndicated from Ryan Smith original https://www.servethehome.com/asus-showcases-nuc-16-family-powered-by-intel-panther-lake/

ASUS was showing off the new NUC 16 family of mini-PCs for this year’s Computex trade show. Powered by Intel’s Panther Lake and Wildcat Lake SoCs, these mini-PCs pack a full system into a 0.7L chassis

The post ASUS Showcases NUC 16 Family Powered By Panther Lake appeared first on ServeTheHome.

Welcome to Agents Week

Post Syndicated from Rita Kozlov original https://blog.cloudflare.com/agents-week-welcome/

This week is Agents Week.

As we started thinking about and planning the week, we wrestled with a broader question of what it means to support this new era of agents and what a purpose-built foundation for agents actually looks like.  Which brought us to a simpler framing: what is an Agent Cloud? 

We quickly realized however, that our framing was wrong. Not because it’s the wrong question to ask, but because of who we were asking — ourselves, instead of our agents. It’s no longer about us and what we think, but about what agents need. 

That, in a nutshell, is what Agents Week is about. 

The cloud we have today, and the web it sits on, were built for people. Every layer assumes a human is watching: pages designed to hold your attention, dashboards to click through, interfaces tuned for how we read and decide. But agents don't work that way. They don't get distracted, tired or fatigued…  and they have their own needs around speed, structure, and access.

An Agent Cloud has to do two things at once. It has to set us up for an agent-native future, where the primitives are built for agents from the ground up rather than retrofitted from human tools. And realistically, it has to meet us where we are today, acting as a translation layer between the human-shaped web that exists now and the agent-shaped one we're moving toward.

That's the throughline for the next five days: the shape of a cloud built for agents and humans and how they interact. The week will explore the theme through what that means for the primitives and execution layer you need, the updated agentic software development lifecycle, how organizations can securely enable employees and agents to interact with safe controls, how this shapes the agentic web, and finally, grounding all of it in the reality of agents and humans today.

Going back to the question: what does your agent need from an Agent Cloud? Well, rather than copy and pasting responses we got from our agents, we encourage you to ask your own agent that, and share any interesting insights and responses you get. Here’s an example prompt for you to use, but we encourage you to explore answers of your own:

What do you, as an agent, need from an agent cloud? Imagine things across the categories of a storage & compute cloud and the execution and storage primitives you need, your dev lifecycle (adlc – like sdlc but with humans taken out of the loop), secure access to systems of record within an organization to get deep work done, and the web (discovery, access, payments…).

Let us know what your agent says by replying here, we’d love to see the responses! 

Follow along on the blog this week for the latest innovations around Agents, and reach out on X to join in the conversation.

За опитите на властта да разруши европейския консенсус

Post Syndicated from Bozho original https://blog.bozho.net/blog/4608

Радев в рамките на десетина дни каза следните две противоречащи си неща:

„Държавното ръководство на Иран много добре разбира, че американските самолети, които ще бъдат разположени на авиобаза „Безмер“, в никакъв случай не са за бойни мисии“ и „На 17 юли получихме нота от американското посолство с искане за разполагане на до 8 самолета-цистерни на летище „Безмер“ за подкрепа на операциите на САЩ в района на Близкия изток“

Тук има един въпрос, извън явното противоречие и „гънене“ – защо на Радев му е нужно да изглежда в приятелски отношения с Иран? Извън очевидното „за да си мислят хората, че сме си приятелчета с Иран и те няма нищо да ни направят“.

Част от дългогодишната руска пропаганда, насочена към България, включва основните линии за упадъчния запад, за великата руска армия, но и позитивна пропаганда за съюзниците и икономически партньори на Русия, в т.ч. Иран.

Русофилският електорат, към който се е прицелил Радев, е бил облъчван дълги години с антизападни наративи, които включват тезата за добрия Иран, борещ се срещу „хегемонията на колективния загниващ запад“.

Не е случайно, че Радев и неговите говорители ползват устойчиви словосъчетания от наръчниците на Кремъл: „колективния запад“, „това не е война, а специална военна операция“ (глупост, казана от зам-председателя на парламента), „военната помощ за Украйна само удължава войната“, заплахата за „тактически ядрен удар“ и много други.

Дезинформационните онлайн кампании са посяли семената, а говорителите на Прогресивна България, експлоатирайки същите опорни точки, се опитват да пожънат резултатите, като създадат трайно политическо ядро, което се идентифицира с този разказ – вкл. за загниващия колективен запад, лицемерно налагащ със сила ултралиберални ценности на нормалния консервативен свят.

Част от идеолозите и ключови медийни инструменти на ПБ опитват да наложат именно това разделение. Кризата в Сеута бива безмилостно експлоатирана в тази посока – въпреки критичната реакция на почти всички европейски държави срещу нелегалната миграция, и въпреки, че Испания с помощта на армията върна почти всички нелегални от Сеута обратно в Мароко, тезата ще продължи да бъде „Либерална Европа позволява да бъде превзета от африкански нашественици“.

И тук не е въпрос на това, дали чужда пропаганда попива на местна почва. И ще бъде грешка да оправдаваме всяка политическа несгода и криволичене с “руска пропаганда”. Особено защото е видно, че има достатъчно местни политически играчи, които опитват да налагат и експлоатират този фалшив разказ.

Да, „колективният запад“ прави грешки, залита прекалено по някои теми, действа мудно по стратегически въпроси. Но за България е вредно и опасно властта да се идентифицира с антизападния разказ, макар и камуфлажно прикрит заради нуждата от еврофондове и „силните карти“, с които САЩ разполага в геополитическата игра.

Вредно и опасно е, защото идентификацията на властта с този политически разказ го прави „мейнстрийм“, а от него следва дезинтеграция на европейския консенсус, който дълги години е необходимо условие за просперитет, а вбъдеще е единствената гаранция за сигурност. Да, България не е забогатяла толкова от членството си в ЕС, колкото можеше, ако местни феодали и мутри не я дърпаха назад заради контрола си върху съдебна система и служби, но е факт, че откакто в България има европейски консенсус, българите стават по-богати и живеят по-добре.

Всеки опит да бъде разрушен този консенсус, докато някой се мъчи да стане българския Орбан или Вучич, е опасен за България в дългосрочен план.

Затова една дума, едно изречение, едно интервю, едно действие, понякога предизвиква привидна свръхреакция у по-вслушващите се проевропейски избиратели. Защото когато премиерът каже “колективният запад”, а правителството се старае да изглежда като близък приятел на репресивния режим на аятоласите, хората усещат с кожата си опасността за собствения си начин на живот в средносрочен план.

Прогресивна България беше избрана от електорална коалиция – от група избиратели, в която далеч не всички споделят тази посока и този политически разказ. Радев беше избран като инструмента за демонтиране на модела Пеевски-Борисов (който попречи на реализирането на ползите от членството в ЕС) от едни, и като инструмент за откъсване от европейския път от други.

Ако обаче моделът не бъде демонтиран, а овладян, докато идеолози и пропагандисти налагат от най-високата държавна трибуна антиевропейския разказ, тази електорална коалиция много бързо ще се разпадне, защото и по-силно европейски настроените, и по прагматично настроените, ще видят, че ако останем в периферията на общата европейска сигурност и на европейската солидарност, това ще има само негативи за тяхното благосъстояние и начин на живот. И то далеч не само защото няма да има еврофондове.

Вероятно надеждата на стратезите на властта от кръга “петолъчка” е след 2 години европейският елит да бъде сменен и техните маргинални позиции в момента да се окажат мейнстрийм и в Европа. Но ще останат разочаровани. Както те самите осъзнават, когато дойдеш на власт, много бързо трябва да започнеш да вземаш реални решения и популизмът става доста по-трудна политическа линия, а носителите му се отварят за атака срещу политическото им лицемерие (както стана в случая с американските самолети). А и няма никаква гаранция, че евентуални нови европейски лидери ще гледат към Русия, даже напротив (ако гледаме Мелони, напр.)

Нашата роля (на Демократина България) като опозиция е да кажем тези неща достатъчно рано – не за да ерозираме властта самоцелно, а за да гарантираме, че грешните ходове не остават електорално ненаказани. И най-вече за да ги предотвратим, доколкото това е възможно.

Но ние не сме просто опозиция, която критикува и предупреждава. Нашата цел е да бъдем политически авангард на удържането на европейския курс на България, на европейския консенсус, на солидарността, законността и споделената сигурност.

За тази цел ние сме готови да проявяваме последователна умереност, за да не позволяваме на идеолозите на войните на идентичности да разрушават възможностите за създаване на електорална коалиция в полза на този дневен ред. Залогът е изграждане на ново издание на широкия проевропейски консенсус, който включва разбирането за важността да участваме в политиките по европейска сигурност и консолидация на ЕС в геополитически полюс.

Материалът За опитите на властта да разруши европейския консенсус е публикуван за пръв път на БЛОГодаря.

The collective thoughts of the interwebz