Add Laguna XS 2, XS 2.1, and S 2.1 support to the MLX model and create paths.

Read the source config to apply one quantization policy across dense and routed MoE layers. Keep the tied output head and router at source precision, quantize supported attention and expert projections, selectively promote sensitive expert down projections, and emit per-tensor metadata for mixed quantization blobs.

Correct dense expert loading, BF16 source-layout handling, expert global-scale shapes and dtypes, routing-score scaling, and mixed-precision expert dispatch. Gate/up and down projections select quantized or dense execution independently so promoted BF16 down projections do not force quantized gate/up weights through the dense fallback.

Optimize the forward pass with compatible gate/up fusion, sorted standard GatherMM and GatherQMM operations for larger prefills, model-local mlx.Compile closures for elementwise MoE work, and cache-backed 512-token prefill chunks. This keeps the implementation on maintained MLX operations without custom kernels.

Add focused tests for Laguna configuration variants, quantization policy and metadata, dense and routed expert loading, mixed-precision dispatch, compiled-versus-eager parity, fused projections, routing, and prefill chunking.

• review comments and S 2.1 performance fixes

Address renderer/parser selection and mixed-precision expert quantization review feedback.

Keep Laguna weights resident on Metal to prevent repeated paging of its large, sparsely accessed expert buffers. Scope this policy to Laguna GPU execution.

Remove obsolete 512-token prefill chunking now that the runner's 2048-token path is faster.

• review comments addressed

• fix create

Every year, Google I/O brings new announcements and resources across ecosystems and products, including Android development. As development shifts toward AI and agent-assisted tooling, we’ve expanded our offerings to better support you, however you decide to build for Android.

To help you stay up to date, here is a summary of the top 3 announcements for Android Developer Productivity at I/O.

1. Android CLI is now stable

Android CLI is now stable at version 1.0, with more capabilities and integrations.

The latest version of Android CLI introduces many new features, like programmatic version lookup and support for Journeys, and bridging capability to allow agents to integrate directly with Android Studio, via the studio command.

Running Android Studio alongside the agent and Android CLI enables more efficient navigation in your project, more precise output, and access to Android Studio’s unique tooling, such as performance profilers, Compose Previews, and Android Device Streaming.

Android CLI now integrates seamlessly with Android Studio

Additionally, Google Antigravity now officially supports Android development, with the Android resources bundle, which includes the Android CLI and skills.

You can either install the bundle during onboarding after installation, or later from the Settings > Customizations > Build With Google Plugins menu. This provides Antigravity with all the powerful tools and knowledge of Android CLI to enable it to perform core tasks—from creating projects to deploying your app on a new virtual device—much more easily and efficiently.

Google Antigravity now offers the Android resources bundle

Android CLI is now available through more package managers: like npm and homebrew. For more information, check out the Android CLI blog post and official documentation.

2. Android skills keep growing

To help models gain expertise for specific development patterns that follow our best practices, we are continuing to expand our repository of Android skills, available through Android CLI and GitHub.

Android skills ground LLMs in specialized workflows and domain knowledge, for the most common and more complex user journeys they might struggle with. We’ve shipped a fresh new batch of skills, with now more than 17 skills for areas such as:

• Adaptive UI
• Display Glasses and Jetpack Compose Glimmer for XR
• Migration to CameraX
• Perfetto SQL and Trace Analysis
• Jetpack Compose Styles API
• AppFunctions
• Verified email retrieval with Android Credential Manager
• Engage SDK integration
• Testing setup
• Wear OS Jetpack Compose Material3

Android skills keep growing

You can browse skills and install using the Android CLI commands:

android skills list
android skills add –skill=<skill-name>

For more information, check out the official documentation.

3. Android Bench adds new models

Earlier this year, we launched Android Bench - our leaderboard for testing LLMs on real-world Android development challenges and tasks, with the goal of accelerating model improvements, so you have more helpful options for AI assistance.

Latest results from Android Bench leaderboard

You asked us to evaluate open models. So, at I/O, we added more commonly used ones, including our local model Gemma 4, to the leaderboard. We also added the latest models including Gemini 3.5 Flash.

We are also working on increasing the difficulty of challenges we’re giving LLMs, including creating long running tasks, to continue encouraging improvements. These tasks will be coming soon to Android Bench. Check out the Android Bench leaderboard to see the latest results.

Android development anywhere

By expanding our AI-assisted Android development offerings to Antigravity, through Android CLI and Android skills, and solidifying with the pro capabilities and production grade polish of Android Studio, we’re supporting Android developers wherever they choose to build.

Have fun bringing your ideas to life faster and easier than ever before - we’re excited to see what you build in this new era of agentic development.

Check out the full Developer productivity at Google I/O 2026 YouTube playlist for more information.

Today we're releasing Android 17 and making it available on most supported Pixel devices. Look for new devices running Android 17 in the coming months.

Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance. We'll cover all that in this post, as well as how we're bringing together next generation tools, libraries, and agent skills to help your apps embrace the opportunity.

Throughout the past year, from our Canary channel to our Beta releases, we’ve collaborated with you in the developer community to build a platform you and your users can trust. To that end, this moment marks the availability of the source code at the Android Open Source Project (AOSP). This allows you to examine the source code for a deeper understanding of how Android works.

Let's dive deeper into Android 17.

An intelligence system

With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps. To that end, Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state.

The Jetpack library, currently in alpha, makes adding AppFunctions as easy as annotating a class and adding KDoc comments.

/**
 * A note app's [AppFunction]s.
 */
class NoteFunctions(
    private val noteRepository: NoteRepository
) {
    /**
     * Adds a new note to the app.
     *
     * @param appFunctionContext The execution context.
     * @param title The title of the note.
     * @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
        appFunctionContext: AppFunctionContext,
        title: String,
        content: String
    ): Note {
        return noteRepository.createNote(title, content)
    }
}

We’ve also launched an AppFunctions agent skill that analyzes your app’s key workflows, automatically generates the required Kotlin code, optimizes your KDocs for LLM tool-calling, and provides ADB commands for testing and debugging.

The Gemini integration is currently in a private preview with trusted testers, but you can begin preparing your apps now. In addition to ADB commands to execute your AppFunctions, we've provided a test agent app that includes an interface to discover and execute your app functions and simulate an AI agent integration. Join our integration early access program at goo.gle/eap-af for a chance to be among the first apps to deploy AppFunctions to production.

Adaptive-first

Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments. Now, with over 580 million large screen devices in the hands of users and the forthcoming launch of Googlebooks, the next generation of ChromeOS built on the Android stack, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users, which is one of the reasons we're shifting to an adaptive-first development standard.

No resizability/orientation restrictions on large screens

To ensure apps deliver a premium experience across all form factors, including mobile devices running in desktop mode on connected displays, Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp) for apps targeting API level 37. The system will ignore legacy manifest attributes and runtime APIs, including screenOrientation, setRequestedOrientation(), resizeableActivity=false, and aspect ratio constraints (minAspectRatio/maxAspectRatio). Games (based on app category in Google Play) remain exempt. Your app must be ready to adapt to any window size, respect the user's preferred device posture, and support free-form windowing natively.

Next-gen multitasking: App Bubbles, Bubble Bar, and desktop interactive PiP

Android 17 introduces powerful new windowing capabilities that redefine how users multitask, demanding even greater layout flexibility from your apps:

• App Bubbles: Moving beyond the messaging bubbles API, users can now transform any app into a floating bubble by long-pressing its icon on the launcher. This feature is available across phones, foldables, and tablets, enabling lightweight multitasking for any workflow.
• The Bubble Bar: On large screens (tablets and foldables), the system taskbar now includes a dedicated Bubble Bar to organize, transition between, and dock these floating app bubbles.
• Desktop interactive PiP: In desktop environments, Android 17 introduces interactive Picture-in-Picture (PiP). Unlike traditional PiP windows which are read-only, these pinned windows remain fully interactive while staying always-on-top of other application windows.

App Bubbles and Bubble Bar in action

Activity recreation updates

To prevent disruptive state loss and stutter, Android 17 updates the default behavior for Activity recreation. The system will no longer restart activities by default for typical configuration changes that do not require a full UI redraw (including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE).
Instead, running activities will receive these updates via onConfigurationChanged(), enabling smooth transitions. If your application explicitly relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute.

Continue On

Android 17 adds Continue On to help users seamlessly transition a task between Android devices. The user sees a suggestion for the most recently opened app from their mobile device in their tablet taskbar, providing a one-tap affordance to launch the app and deep-link where they left off. Continue on can support app-to-web transitions, including falling back to using the web if the app isn't installed.

Handoff Suggestion on a Tablet

class MyHandoffActivity : Activity() {

    ...

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Do stuff
    ...
    // Enable handoff
    setHandoffEnabled(true, null)
  }

  // Override and implement onHandoffActivityDataRequested
  override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData {
    // Create and return handoff data
  }
}

Go adaptive-first with Jetpack Compose

To help you adapt your apps to meet the new Android 17 requirements, we've launched the Jetpack Compose adaptive skill. This AI-powered developer workflow helps you implement the best adaptive practices:

• Adaptive navigation: Automatically transition between bottom navigation bars on mobile and edge-anchored navigation rails on large screens using NavigationSuiteScaffold from the Material 3 Adaptive library.
• Multi-pane layouts: Implement list-detail and supporting pane layouts natively using Navigation 3 Scenes (ListDetailSceneStrategy and SupportingPaneSceneStrategy) instead of fragile fragment transactions.
• FlexBox & Grid APIs: Utilize Compose 1.11's dynamic layout components to easily adjust row and column spans on the fly, ensuring your content always fills the space beautifully.
• Advanced non-touch input: Leverage Compose 1.11's enhanced trackpad and mouse support, including native focus rings and new APIs (like TrackpadInjectionScope and performTrackpadInput) to easily test and deliver a true "laptop-class" experience on Googlebooks and Desktop Mode.
• Dynamic window states: Leverage Compose's reactive state model to seamlessly adapt your UI when the app transitions from full screen to a floating App Bubble or an interactive Desktop PiP window, ensuring a premium experience even at minimal dimensions.

Android is Compose-first

Compose offers the easiest way to build adaptive apps, and that's just one of the many reasons we believe that all Android UI should be built with Compose. To that end, Android development is now Compose-first. All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features.

TIP
Ready to migrate? Use our AI-driven XML to Compose Migration Skill to automatically analyze your legacy View layouts and convert them into highly-adaptive Compose code.

Performance & efficiency

App performance means a smooth user interface, fast app start times, and efficient multitasking; Android 17 has impactful improvements in all of these areas.

App memory limits

Memory usage is one of the silent foundations of overall performance. When a foreground app or service grows unchecked, memory management spikes CPU and battery utilization and eventually leads to the termination of other well-behaved cached apps and background jobs, ultimately forcing slower cold starts and impaired multitasking. 

Starting in Android 17, the system will enforce strict app memory limits based on a device's total RAM, abruptly terminating offending processes. New things to help you navigate these tighter requirements:

• R8 Optimizer: The R8 optimizer significantly reduces your app's bytecode memory footprint by shrinking classes, methods, and fields into shorter names, and stripping out unused code and resources. Use R8 in full mode along with the new R8 configuration analyzer to make sure your app is getting the most from R8.
  

• LeakCanary in Android Studio Panda: The profiler now features native LeakCanary integration as a dedicated task, fully integrated with your IDE and source code.
• ApplicationExitInfo: If your app is terminated by these limits, getDescription() from ApplicationExitInfo will return "MemoryLimiter:AnonSwap".
• On-Device Anomaly Detection: Part of ProfilingManager, you can leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached.

val profilingManager = applicationContext
   .getSystemService(ProfilingManager::class.java)

val triggers = ArrayList<ProfilingTrigger>().apply {
  add(ProfilingTrigger.Builder(
    ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())
}
profilingManager.addProfilingTriggers(triggers)

And, we're working to surface more in-field memory metrics to you within Google Play Console.

Generational garbage collection

Android 17 introduces more frequent, less resource-intensive young-generation collections to ART's Concurrent Mark-Compact garbage collector (GC). By separating short-lived objects from stable, long-lived ones, the system runs frequent, lightweight "young-generation" sweeps rather than expensive full-heap scans, drastically reducing CPU usage, power drain, and UI stutter. Our testing has shown significant improvements in GC interference with application threads and a reduction in the maximum memory resident set size (RSS). ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates.

Lock-Free MessageQueue

For apps targeting SDK 37 or higher, the core android.os.MessageQueue now implements a lock-free architecture, significantly reducing missed frames, improving app startup time, and radically improving the performance of busy queues in multithreaded scenarios. Note: This can break apps that use reflection on private MessageQueue fields and methods.  The peekWhen and poll APIs have been added to TestLooperManager for instrumentation testing without relying on MessageQueue internals.

Static final fields now truly final

Starting from Android 17, apps targeting SDK 37 or higher won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (or deep reflection) will lead to an IllegalAccessException being thrown. Modifying them via JNI’s SetStatic<Type>Field methods family will immediately crash the application.

Custom notification view restrictions

To reduce memory usage we are further restricting the size of custom notification views. This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher.

Privacy & Security

Maintaining user trust is at the heart of the Android ecosystem. Android 17 introduces robust features that protect sensitive data while simplifying user experiences.

Privacy-preserving choices

Historically, apps required broad, permanent permissions to access information like contacts, precise location and media files. Android 17 continues the shift toward privacy-preserving choices that grant temporary, session-based access only to the data the user explicitly selects:

• System-Level Contact Picker: Utilizing ACTION_PICK_CONTACTS, apps can request temporary access only to specific fields (e.g., email or phone number) chosen by the user, eliminating the need for the broad READ_CONTACTS permission. It also fully supports work/personal profile separation.
• Customizable Photo Picker aspect ratio: UsingPhotoPickerUiCustomizationParams, you can customize the system photo picker to show thumbnails in portrait mode. This is perfect for apps that always display photos and videos in portrait such as video based social media apps.
• System-rendered Location Button: A new system-rendered location button that you can embed in your app grants precise location access for the current session only.
• EyeDropper API: A new system-level API, ACTION_OPEN_EYE_DROPPER, allows your app to create a system-powered eyedropper enabling the user to select color from any pixel on the display. This provides a secure, privacy-preserving color-picking experience that eliminates the need for broad, sensitive screen capture or media projection permissions.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
   if (result.resultCode == Activity.RESULT_OK) {
       val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
       // Use the picked color in your app
   }
}
fun launchColorPicker() {
   val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
   eyeDropperLauncher.launch(intent)
}

Picking a color from anywhere on the screen with the system EyeDropper

Local network access

Apps targeting Android 17 now either require the ACCESS_LOCAL_NETWORK runtime permission or the use of system-mediated, privacy-preserving device pickers for local network communication, such as talking to smart home devices or casting receivers. Because ACCESS_LOCAL_NETWORK falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again.

SMS OTP protection

Android 17 expands SMS one-time-password (OTP) protection by delaying access to SMS messages for three hours:

• WebOTP Format: Delayed for all apps that are not the intended recipient (domain mismatch).
• Standard SMS OTP: Delayed for all apps targeting SDK 37+.
• Exemptions: Default SMS, assistant, and connected companion apps are exempt. Apps are strongly encouraged to migrate to the SMS Retriever or SMS User Consent APIs.

Post-Quantum Cryptography (PQC)

Android 17 is ready for the next generation of cryptographic security:

• Keystore Integration: Supported devices can generate ML-DSA (Module-Lattice-Based Digital Signature Algorithm) keys in secure hardware to produce quantum-safe signatures, exposed via standard JCA APIs.
• Hybrid APK Signing: Introducing the v3.2 APK Signature Scheme, which combines classical signatures with ML-DSA signatures to secure app delivery.

Safer native dynamic code loading 

Smarter password protection for physical inputs

With Android 17, we're making it safer to enter passwords, PINs, and other secrets when using a physical keyboard by no longer showing the last typed character by default.

Users can still easily customize these display settings to match their preferences (availability may vary by device manufacturer).

These enhanced privacy protections are automatically supported byAndroid's built-in SDK components and will be supported in Compose 1.12 for SecureTextFields.

Media and camera features that empower creators and delight users

Android 17 introduces new creator features that give access to pro-quality cameras and media, all while improving the experience for consumers.

• Eclipsa Video: HDR video standard built upon the SMPTE ST 2094-50 specification that introduces new metadata to help devices adapt content for their display headroom and ambient light conditions, as well as improve the simultaneous display of standard and HDR content.
• RAW14 image format: New support for the RAW14 image format provides a way for your professional camera app to capture the highest level of detail and color depth from compatible camera sensors.
• Vendor-defined camera extensions: Vendor-defined extensions enable hardware partners to define and implement custom camera extension modes, providing access to the best and latest camera features.
• Extended HE-AAC software encoder: A new system-provided Extended HE-AAC software encoder, supports both low and high bitrates using unified speech and audio coding, providing significantly better audio quality for voice messages in low-bandwidth conditions, including support for loudness metadata.
• Versatile Video Coding (H.266): Enables OEMs to add codec support by defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor.
• Camera device type: New APIs that query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera.
• Constant Quality for Video Recording: SetVideoEncodingQuality in MediaRecorder configures a constant quality (CQ) mode for video encoders to ensure uniform visual fidelity across the entire video.

Better support for hearing aids

• Bluetooth LE Audio hearing aid support: Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids with the new AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, so your app can distinguish hearing aids from regular headsets to provide a tailored experience for users with assistive listening devices.
• Granular audio routing for hearing aids: Android 17 allows users to independently manage where specific system sounds are played. They can choose to route notifications, ringtones, and alarms to connected hearing aids or the device's built-in speaker, helping to avoid unwanted in-ear interruptions while maintaining a Bluetooth connection for hearing aid management apps.

CameraX and Media3

CameraX and Media3 have been updated for Android 17. They are there to do the heavy lifting, smoothing the rough edges of media development and simplifying building reliable camera capture, smooth media playback, and creative and complex editing experiences.

We've released an agent skill that can migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX.

Note: You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices.

Get your apps, libraries, tools, and game engines ready!

If you develop an Android SDK, library, tool, or game engine, it's critical to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your downstream developers know if updates are needed to fully support Android 17.

Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 17 Beta 4. Work through all your app's flows and look for functional or UI issues. Each release of Android contains platform changes that improve privacy, security, and overall user experience; review the app impacting behavior changes for apps running on and targeting Android 17 to focus your testing, including the following:

• Resizability on large screens: Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens.
• Dynamic code loading: If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.
• Enable CT by default: Certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)
• Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access.
• Background audio hardening: Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs. Based on your feedback, we’ve made some changes since beta 2, including targetSDK gating while-in-use FGS enforcement and exempting alarm audio. Full details available in the updated guidance.
• NPU access declaration: Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate, vendor-specific SDKs, as well as the deprecated NNAPI.

Get started with Android 17

Your Pixel device should get Android 17 shortly if you haven't already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 17 Beta 4.1 and have not yet taken an Android 17 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 17 over the air.

Getting the Android 17 beta on partner devices

Android 17 is available in beta on handset, tablet, and foldable form factors from partners including Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo, and Xiaomi.

For the best development experience with Android 17, we recommend that you use the latest Canary build of Android Studio Quail. Once you’re set up, here are some of the things you should do:

Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or Android Emulator running Android 17 and extensively test it.

Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 17, and have plans to bring you updates in a fast-paced release cadence going forward.

For complete information on Android 17 please visit the Android 17 developer site.

In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

Many paths to needing Rust

The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.

"Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO

Rust learning resources

Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

"I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

"The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

"Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

"We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

Beginner stumblings and unlearning habits

It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.

"There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)

"In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT

We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.

"I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab

Learning to work with the borrow checker

We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.

The compiler as teacher

Rust's diagnostics did the teaching on their own, especially around lifetimes.

"If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs

"Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer

Learning by doing

Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.

"I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust

"Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider

Letting go of "clone guilt"

Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.

"On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university

The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.

We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.

Multi-paradigm, but not the OOP some are used to

The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.

"Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM

"I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company

Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.

"My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries

"The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO

Teaching Rust in academia

We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.

"I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust

The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.

What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.

Learning using LLMs

Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.

"I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate

"I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust

For some learners, an LLM is just another way to find answers, no different than a search engine.

"So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space

One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.

"At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company

We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.

Organizational considerations for Rust learners

We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.

"[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)

"So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider

"We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation

Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.

"They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM

The community and helping each other aspect seems to grow bonds as organizations mature.

"Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company

Silent attrition

We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.

"All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -– A second University Professor

There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.

"We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)

We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.

"Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust

While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.

"People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider

Feedback on near-bounces from survey

We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:

"I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A

Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.

One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.

Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.

Need more focused work on silent attritrion

The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.

Conclusions

Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.

That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.

What seems worth trying

Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.

Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.

Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.

Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.

How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.

Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.

What we still don't know

The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

The New Jersey plates that were allegedly stolen from the LA dealer were 34 03 DTM, not 34 10 DTM. But when the police report was created and the plate was entered into Flock’s system, it was just recorded as 34 DTM. Just the five large characters, no little number in the middle. And Flock’s AI tech wasn’t registering that non-standard little number when it began picking up the Range Rover around town. It just saw ...

Beste Grafikkarte aller Zeiten? 👑

Die NVIDIA GeForce GTX 1080 Ti kam 2017 für 819 € – mit 11 GB VRAM, 3.584 CUDA-Kernen und mehr Leistung als die teurere Titan X. Fast 10 Jahre später läuft die Pascal-Legende noch erstaunlich gut in 1080p: kein DLSS, kein Raytracing – einfach rohe GPU-Power.

Welche Grafikkarte verdient für dich Legendenstatus? 👇
-
#GTX1080Ti #NVIDIA #Grafikkarte #PCGaming #gaminghardware

► Zum PC-WELT T-Shirt-Shop:
https://pcwelt.myspreadshop.de

► Unterstützt uns, werdet Kanalmitglied für nur 99 Cent im Monat und erhaltet exklusive Vorteile (jederzeit kündbar):
https://www.youtube.com/pcwelt/join

► News, Tests und Tipps zum Thema Gaming & eSports: https://www.pcwelt.de/gaming

► PC-WELT auf Instagram: https://instagram.com/pcwelt/
► PC-WELT auf Facebook: https://www.facebook.com/pcwelt/
► PC-WELT auf Twitter: https://twitter.com/pcwelt

--------

Unser Equipment (Affiliate-Links):

🎥Kameras:
https://amzn.to/3WUf0Ud
https://amzn.to/44VCdHC
https://amzn.to/3KdbGMe


🔭Objektive:
https://amzn.to/3uLfZ9p
https://amzn.to/2NkGoFd
https://amzn.to/3iXV3GJ

➡️ Stative:
teuer: https://amzn.to/2DIlCeV
günstig: https://amzn.to/2IHm026
Einbein: https://amzn.to/2T0WbPG

📺Field Monitore:
Atomos Ninja: https://amzn.to/4dR0q5Y

🎤Mikros:
Lavalier: https://amzn.to/2IxIlzm
Headset: https://de-de.sennheiser.com/hsp-essential-omni
Shotgun: https://amzn.to/2HdVKIT

➡️ Kamera-Cages & Zubehör:
SmallRig-Cages: https://amzn.to/4atoPM4
Damit habt Ihr alles im Griff:https://amzn.to/2SmfptN

➡️ Schulter-Rig: https://amzn.to/3Rm9ZQX

--------

Auf dem PC-WELT-Kanal findet Ihr alles rund um das Thema PCs & (Gaming-)Hardware. Bei uns gibt's alle wichtigen Infos, Tests und Hands-ons rund um die spannendsten Geräte.

--------

Einige Links können Affiliate-Links sein. Kauft Ihr über einen solchen Link ein Produkt, erhalten wir eine kleine Provision. Am Kaufpreis ändert sich für Euch dadurch nichts.

--------

► Alle News, Hands-ons und Gewinnspiele findet Ihr in dieser Playlist:
https://www.youtube.com/playlist?list=PLVC_WMwVwvSjZfr6GlSyy-bNEXm9b-lN3

Add Laguna XS 2, XS 2.1, and S 2.1 support to the MLX model and create paths.

Read the source config to apply one quantization policy across dense and routed MoE layers. Keep the tied output head and router at source precision, quantize supported attention and expert projections, selectively promote sensitive expert down projections, and emit per-tensor metadata for mixed quantization blobs.

Correct dense expert loading, BF16 source-layout handling, expert global-scale shapes and dtypes, routing-score scaling, and mixed-precision expert dispatch. Gate/up and down projections select quantized or dense execution independently so promoted BF16 down projections do not force quantized gate/up weights through the dense fallback.

Optimize the forward pass with compatible gate/up fusion, sorted standard GatherMM and GatherQMM operations for larger prefills, model-local mlx.Compile closures for elementwise MoE work, and cache-backed 512-token prefill chunks. This keeps the implementation on maintained MLX operations without custom kernels.

Add focused tests for Laguna configuration variants, quantization policy and metadata, dense and routed expert loading, mixed-precision dispatch, compiled-versus-eager parity, fused projections, routing, and prefill chunking.

• review comments and S 2.1 performance fixes

Address renderer/parser selection and mixed-precision expert quantization review feedback.

Keep Laguna weights resident on Metal to prevent repeated paging of its large, sparsely accessed expert buffers. Scope this policy to Laguna GPU execution.

Remove obsolete 512-token prefill chunking now that the runner's 2048-token path is faster.

• review comments addressed

• fix create

The post Windows 11 now supports resuming WhatsApp from Android, but you’ll wait longer for the app to load appeared first on Windows Latest

Black Hat USA 2026 isn't just bigger... It's built differently, and Black Hat is closing the gap between knowing and doing. 

This video walks through some of our new features, the team building them explain what's coming and why it matters:

Arsenal Labs is reunited with Arsenal. The Interface showcases CTF arenas, including scenarios across healthcare, retail, and more, VR breach investigations, and escape rooms. Our NOC Outpost allows you to step beyond the glass and work alongside the team protecting the event in real time. Bricks and Picks introduces real-world physical security scenarios. The Main Stage moves to the Business Hall floor. A First-Timers Program launches for anyone walking into their first Black Hat. Networking is easier throughout the new Cyber District.

Timestamps:
0:00 — Why 2026 is different: active learning, hands-on experiences
2:06 — Arsenal + Arsenal Labs: 115 sessions, Drone Zone, The Lab, The Interface
5:51 — Summit Leaders Lounge, Community Conversations, Picture Point
8:21 — NOC Outpost: step beyond the glass, see agentic AI in action
9:48 — Bricks and Picks: lock picking + Lego, physical security scenarios
12:19 — Main Stage + Startup Spotlight (now a global competition)
13:51 — Startup City + AI Zone content stages
16:09 — First-Timers Program (Tuesday 5-7pm)
16:54 — Cyber District: 13 sponsor venues across the week

Black Hat USA 2026
August 1–6, 2026 | Las Vegas
Register at blackhat.com
Full feature breakdown: Black Hat USA 2026 | Features

One Step Ahead.

 

Black Hat USA 2026
August 1–6, 2026 | Las Vegas
Register at blackhat.com
Full feature breakdown: Black Hat USA 2026 | Features

 

One Step Ahead.

The post Unsloth vs Axolotl vs TRL vs LLaMA-Factory: A Fine-Tuning Framework Comparison on Speed, VRAM, and Multi-GPU appeared first on MarkTechPost.

The New Jersey plates that were allegedly stolen from the LA dealer were 34 03 DTM, not 34 10 DTM. But when the police report was created and the plate was entered into Flock’s system, it was just recorded as 34 DTM. Just the five large characters, no little number in the middle. And Flock’s AI tech wasn’t registering that non-standard little number when it began picking up the Range Rover around town. It just saw ...

The post Best Local LLMs You Can Run on a Single 24GB GPU in 2026: Qwen, Gemma, Mistral, DeepSeek Compared appeared first on MarkTechPost.

This article How to mount GPU memory (VRAM) as a RAM disk on Windows computer first appeared on TheWindowsClub.com.

Lange Zeit galten fallende Hardware-Preise als Naturgesetz: Wer ein paar Monate wartete, bekam mehr Leistung für weniger Geld. Mitte 2026 gelten diese Regeln leider nicht mehr. Der gigantische Hunger der Rechenzentren nach KI-Beschleunigern saugt die Produktionskapazitäten der großen Halbleiterfertiger leer – Besserung ist erst einmal nicht in Sicht. Für Endverbraucher bedeutet das: Wer jetzt einen neuen Desktop-PC braucht, sieht sich mit einem äußerst angespannten Markt konfrontiert.

PROMOTION

Ihr Laptop kann nur ein Ding? Dieses 2-in-1-Modell passt sich Ihrem Workflow an

Das HP OmniBook 5 Flip bietet dank 360°-Scharnier vier Nutzungsmodi – vom klassischen Laptop bis zum Tablet. Der Intel® Core™ 7 Prozessor sorgt für flüssiges Arbeiten im Alltag. Das 14 Zoll 2K-Touchdisplay (1.920 x 1.200) stellt Inhalte gestochen scharf dar, 16 GB RAM und 512 GB SSD bieten Leistung und Platz für Ihre Projekte. Die Fast-Charge-Funktion bringt Sie schnell zurück auf 50 % Akkuladung.

Erfahren Sie mehr über das HP OmniBook 5 Flip

Gleichzeitig ist die technische Verlockung groß: Mit Nvidias Blackwell-Architektur (RTX 50-Serie) und AMDs effizienten Ryzen-9000-Prozessoren stehen technologische Schwergewichte in den Regalen, die einen massiven Leistungssprung versprechen. Lohnt sich also das Warten auf bessere Preise? Die klare Antwort lautet: Nein, zumindest nicht in absehbarer Zeit. Wer jetzt einen neuen PC braucht, muss nicht warten – sollte aber clever konfigurieren, um die aktuellen Stolpersteine der Industrie zu umschiffen.

Foundry

Drei Beispiel-Konfigurationen: Für jeden Anspruch das richtige Setup

Die strategischen Fragen sind geklärt, wir machen uns ans Eingemachte. In den folgenden drei Setups listen wir die besten Kernkomponenten für ein optimales Preis-Leistungsverhältnis auf. Um Ihnen maximale Flexibilität zu ermöglichen, nennen wir innerhalb der Konfigurationen unterschiedliche Komponenten: So können Sie je nach persönlicher Vorliebe gezielt den Preis beeinflussen, mehr Leistung herausholen oder zwischen AMD und Intel wechseln, wenn sich das sinnvoll anbietet.

Konfiguration 1: Der Office- und Alltags-PC

AMD

Konfiguration 1: Zuverlässigkeit, leiser Betrieb und strikte Budgetkontrolle

Fürs Home-Office, Webbrowsing und die gelegentliche Medienwiedergabe braucht es keine teure High-End-Hardware. Hier greift der erwähnte DDR4-Rettungsanker: Durch den bewussten Verzicht auf die neueste Plattform lassen sich Hunderte Euro sparen. Ein zusätzlicher Vorteil dieser Konfiguration ist ihre Zuverlässigkeit: Die Plattform ist ausgereift, günstig und bietet mehr als genug Leistung für typische Office- und Alltagsanwendungen.

• Preisrahmen: ca. 600 – 700 Euro (Kern-PC, zzgl. Peripherie & OS)

• Prozessor (CPU):
  • Standard: AMD Ryzen 5 5600G – Sechs Kerne und eine starke integrierte Grafikeinheit (iGPU). Keine extra Grafikkarte nötig.
  • Alternative: Intel Core i3-14100 – Reicht für reine Office-Arbeiten ebenfalls völlig aus. Wichtig: Achten Sie darauf, nicht aus Versehen die 14100F-Variante zu kaufen, weil dieser Version die Grafikeinheit fehlt.
• Mainboard: Gigabyte B550M DS3H (für AMD) oder Asus Prime B760M-K D4 (für Intel). Beide Boards setzen auf den günstigeren DDR4-Standard. Trotz des niedrigen Preises bieten sie alle wichtigen Anschlüsse für den Alltag, darunter schnelle USB-Ports, M.2-Steckplätze für NVMe-SSDs und genügend Erweiterungsmöglichkeiten für spätere Upgrades.
• Arbeitsspeicher (RAM): 16 GB DDR4-3200 (z.B. Patriot Memory Viper Elite II DDR4 2x8GB, CL18). Dieser Arbeitsspeicher ist für flüssiges Arbeiten und Multitasking völlig ausreichend. Selbst bei zahlreichen geöffneten Browser-Tabs, Videokonferenzen und Office-Anwendungen gleichzeitig geraten 16 GB nur selten an ihre Grenzen.
• Speicherplatz: 500 GB PCIe 4.0 NVMe SSD (z.B. Crucial P310 SSD 500GB M.2 NVMe). Die SSD sorgt für blitzschnelle Boot- und Zugriffszeiten. Wer viele Fotos, Videos oder große Dokumentensammlungen lokal speichert, sollte direkt zur 1-TB-Variante greifen.
• Gehäuse: Das Montech Air 100 ist ein kompaktes Micro-ATX-Gehäuse, das für rund 70 Euro vorbildlich verarbeitet ist. Es bietet ab Werk vorinstallierte Lüfter und eine Mesh-Front für leisen, kühlen Betrieb.
• Netzteil: Mit 450 Watt sind Sie in diesem Segment bestens bedient. Sie können zum Beispiel zum be quiet! System Power 11 450W greifen – das ist ein grundsolides und effizientes Netzteil, das mit seiner moderner ATX-3.1-Zertifizierung zukunftssicher ist. Weil bei diesem Setup keine separate Grafikkarte versorgt werden muss, bleiben die Leistungsreserven selbst unter Last komfortabel.
  
  

Konfiguration 2: Casual-Gaming und Videoschnitt-PC

Asus

Wer aktuelle Spiele flüssig genießen oder mit Adobe Premiere und DaVinci Resolve kreativ werden möchte, kommt um die aktuelle Hardware-Generation nicht herum – das beinhaltet aber auch den derzeit teuren DDR5-RAM. Dafür gibt es starke Leistung und hervorragende Effizienz.

• Preisrahmen: ca. 1.800 – 2.100 Euro (Kern-PC, zzgl. Peripherie & OS)

• Prozessor (CPU):
  • Standard: Der Intel Core Ultra 5 245KF bietet derzeit ein attraktives Preis-Leistungs-Verhältnis. Für rund 150 Euro liefert der moderne 14-Kerner reichlich Leistung für flüssiges 1440p-Gaming und anspruchsvolle Videoschnitt-Projekte.
  • Alternative: Der AMD Ryzen 7 9700X ist eine hocheffiziente 8-Kern-CPU von AMD. Sie verbraucht unter Volllast etwas weniger Strom und bietet beim Gaming minimale Vorteile, ist aktuell im Handel aber etwas teurer.
• Mainboard: Das Asus TUF Gaming Z890-Plus (für Intel) oder das MSI MAG B650 Tomahawk WiFi (für AMD). Beide bieten moderne PCIe-Slots und solide Kühlung für die Spannungswandler.
• Arbeitsspeicher (RAM): 32 GB DDR5-6000 CL30 Kit (z.B. Patriot Viper Venom DDR5-6000 2X16GB, CL30). Angesichts der aktuellen Marktlage ist das eine Investition (450 Euro), die sich für flüssigen 4K-Videoschnitt und moderne Spiele aber auszahlt.
• Grafikkarte (GPU):
  • Standard: Nvidia GeForce RTX 5060 mit 8 GB (z.B. Asus Prime GeForce RTX 5060 8GB OC Edition). Diese Karte ist eine solide Wahl für klassisches 1440p-Gaming, die dank NVENC-Encoder sowie DLSS 4 auch für Content Creation gut geeignet ist. 8-GB-VRAM reichen für die meisten aktuellen Titel aus, können bei anspruchsvollen AAA-Spielen aber zum Flaschenhals werden. Für spürbar mehr Leistungsreserven im 1440p-Gaming können Sie auch zum Ti-Modell greifen (+ 80 Euro).
  • Preis-Alternative: AMD Radeon RX 9060 XT mit 8 GB (z.B. Gigabyte Radeon RX 9060 XT 8GB). Wer ein reines AMD-System bevorzugt, kann zu diesem aktuellen RDNA-4-Modell greifen. Für rund 300 Euro bietet sie hervorragende native Rasterleistung in 1440p und moderne KI-Upscaling-Features.
• Speicherplatz: 2 TB PCIe 4.0 NVMe SSD (z.B. WD_BLACK SN850X NVMe SSD). Moderne Videoprojekte sind äußerst speicherintensiv. Diese schnelle NVMe-SSD bietet reichlich Kapazität und sorgt für verzögerungsfreie Arbeitsabläufe.
• Gehäuse: Fractal Design North XL – ein echter Ästhetik-Hingucker. Mit einer Front aus Walnuss- oder Eichenholz fügt es sich elegant ins Zimmer ein. Dabei bietet es genug Platz und Airflow auch für Komponenten mit hoher Wärmeentwicklung.
• Netzteil: 750 Watt ATX 3.1 (z.B. Seasonic Focus GX ATX 3.1) – Dieses Netzteil bietet den modernen 12V-2×6-Anschluss für RTX-Karten und genügend Puffer für Leistungsspitzen.
  
  

Konfiguration 3: High-End-System für Gaming und Content Creation

Gigabyte

Dieses System ist für Enthusiasten konzipiert, die im Grafikmenü keine Kompromisse eingehen wollen. Hier zählt pure, ungebremste Leistung. Hinweis: Die große Preisspanne dieser Konfiguration ergibt sich vor allem durch die Wahl der Grafikkarte.

• Preisrahmen: 3.300 – 7.200 Euro (Kern-PC, zzgl. Peripherie & OS)

• Prozessor (CPU):
  • Standard: AMD Ryzen 9 9900X3D – Dank des aufgestockten 3D-V-Cache gehört diese CPU zu den schnellsten Gaming-Prozessoren überhaupt. Sie verspricht maximale Framerates auch in modernen und anspruchsvollen Spielen.
  • Günstigere Alternative: AMD Ryzen 9 9900X – minimal langsamer in Spielen, aber ein absolutes Kraftpaket, falls der PC primär für 3D-Rendering, simulationslastige Anwendungen oder rechenintensiven Videoschnitt genutzt wird.
• Mainboard: Asus ROG Strix X870E-E Gaming – Ein ATX-Powerhouse für den Sockel AM5. Das Board wurde entwickelt, um das Potenzial der AMD-Ryzen-9000er-Serie voll auszuschöpfen. Mit zwei nativen USB4-Anschlüssen, Wi-Fi 7 und voller PCIe‑5.0‑Unterstützung bietet es moderne Konnektivität.
• Arbeitsspeicher (RAM): 32 GB DDR5-6000 CL30 Kit (z.B. Patriot Viper Venom DDR5-6000 2X16GB, CL30). Auch im High-End-Segment bringen 64 GB beim reinen Gaming kaum messbare Vorteile. Das Budget ist in der Grafikkarte besser investiert. Nur wer sein System professionell nutzt – etwa für aufwendige 4K-Videobearbeitung oder intensives 3D-Rendering, greift zum 64-GB-Kit und muss den Preissprung zwangsläufig hinnehmen.
• Grafikkarte (GPU):
  • Standard: Nvidia GeForce RTX 5080 mit 16 GB (z.B. MSI GeForce RTX 5080 16GB GDDR7) – Das Werkzeug für kompromissloses 4K-Gaming. Sie bewältigt selbst rechenintensives Path-Tracing ohne Einknicken und korrigiert mit den 16 GB schnellem GDDR7-Videospeicher endlich den Geiz vergangener Nvidia-Tage – was man sich allerdings auch teuer erkauft.
  • Highend-Alternative: Nvidia GeForce RTX 5090 mit 32 GB (z.B. Gigabyte Aorus GeForce RTX 5090 32 GB GDDR7). Das absolute Spitzenmodell im Consumer-Markt. Die Grafikkarte richtet sich an Enthusiasten, die für maximale Workstation-Leistung oder extremes 4K-Path-Tracing die höchste Ausbaustufe anpeilen und bereit sind, den entsprechenden Premium-Preis zu zahlen.
• Speicherplatz: 2 bis 4 TB PCIe 5.0 NVMe SSD (z.B. Crucial T710 SSD 4TB M.2 NVMe PCIe 5.0) – Für kürzeste Ladezeiten dank DirectStorage: Diese Technologie erlaubt es der Grafikkarte, Spieldaten ohne Umweg über die CPU direkt von der SSD zu laden.
• Gehäuse:
  
  • Standard: be quiet! Shadow Base 800 FX Black – ein geräumiger Full-Tower, der ab Werk mit vier Light-Wings-140mm-PWM-Lüftern und einer integrierten Lüfter-Steuerung geliefert wird. Das Gehäuse bietet ausreichend Platz für große 420-mm-Radiatoren und überlange Grafikkarten.
  • Design-Alternative: Lian Li O11 Dynamic EVO XL – Ein modularer Full-Tower, der sich spiegelverkehrt aufbauen lässt. Durch die abnehmbare Ecksäule bietet das Gehäuse freien Einblick auf die Hardware. Es fasst E-ATX-Mainboards, Grafikkarten bis 460 mm Länge und erlaubt die gleichzeitige Montage von bis zu drei 420-mm-Radiatoren für aufwendige Wasserkühlungen.
• Netzteil: 1000 Watt ATX 3.1 (z.B. Corsair RMx Shift oder be quiet! Straight Power 12). Die RTX-50-Serie kann unter Last eine hohe Leistungsaufnahme erreichen. Ein hochwertiges 1000-Watt-Netzteil mit ATX-3.1-Unterstützung bietet dafür ausreichende Reserven.

Ihre Kauf-Checkliste für 2026

Anucha Tiemsom/Shutterstock.com

Bevor Sie Ihre Komponenten in den Warenkorb legen, sollten Sie diese Punkte noch einmal kritisch prüfen. Hier verstecken sich die häufigsten Fehler beim PC-Kauf:

• Airflow bei Gaming-Systemen beachten: Moderne Komponenten arbeiten zwar immer effizienter, trotzdem gilt: Je mehr Leistung, desto mehr Abwärme. Gerade für High-End-Setups sollten Sie Gehäuse mit geschlossener Glas- oder Plastikfront deswegen eher meiden. Eine offene Mesh-Front sorgt für frische Luft, hält die Temperaturen niedrig und ermöglicht es den Gehäuselüftern, auch unter Last angenehm leise zu arbeiten.
• HDD stirbt langsam aus: Für Betriebssystem, Programme und Spiele haben HDDs ausgedient. Mechanische Festplatten lohnen sich heute vor allem noch als günstiger Datenspeicher für Backups und große Medienarchive – alles andere macht die SSD.
• Netzteil-Standards beachten: Neue Grafikkarten benötigen moderne Anschlüsse und eine stabile Absicherung gegen Spannungsspitzen. Achten Sie beim Netzteilkauf auf die neue ATX-3.1-Zertifizierung.
• RAM-Sweetspot treffen: Greifen Sie maximal zu DDR5-6000-Speicher. Alles darüber hinaus macht Ihr neues Setup deutlich teurer, liefert in der Praxis aber kaum einen spürbaren Mehrwert.
• Mainboard-Features geschickt wählen: Bezahlen Sie nicht für Anschlüsse, die Sie nie nutzen. Wer einen PC ohnehin per LAN-Kabel mit dem Router verbindet, braucht z.B. kein Modell mit integriertem Wi-Fi 7.
• Kühlung richtig dimensionieren: Für Mittelklasse-Prozessoren (wie den Ryzen 5 9600X) reicht ein solider Tower-Luftkühler für 40 Euro oft aus. Teure Komplettwasserkühlungen (AiOs) sind erst im High-End-Segment sinnvoll – oder wenn Sie der Gehäuse-Optik besonderes Augenmerk schenken wollen.

Fazit: Clever kaufen trotz Krise

Wer 2026 einen PC baut, sieht sich mit neuen Spielregeln konfrontiert. Der KI-Boom hat den Markt spürbar verzerrt und Arbeitsspeicher zum kostspieligen Schmerzpunkt gemacht. Ein Grund zum Abwarten ist das aber nicht. Dafür steht zu viel spannende Technik in den Regalen – Besserung ist aktuell auch gar nicht in Sicht.

Die Devise lautet deshalb: Priorisieren statt Verzweifeln. Wer beim RAM den Sweetspot trifft (DDR5-6000), auf Vorratskäufe verzichtet oder im Office-Bereich geschickt auf DDR4 ausweicht, holt das Maximum aus seinem Budget heraus. Wenn Sie Ihr Geld strategisch verteilen und die Preisfallen der Hersteller umschiffen, können Sie Ihren Traum-PC auch in Krisenzeiten realisieren.

This blog post describes an idea I’ve been kicking around called battery packs. Battery packs are a curated set of crates arranged around a common theme. For example, there’s a CLI battery pack that has everything you need to build a great CLI, an opinionated pack for creating a backend web service, and one for embedded development (based on the Embedded Working Group’s Awesome Rust repository). We’ve also got some smaller ones, such as the error-handling battery pack that shows how to handle errors in Rust. But this is just the beginning – a key part of the battery pack design is that anybody can create one.

Battery packs are meant to address one of the most common things I hear from new Rust adopters. Everyone loves the wealth of high-quality crates available on crates.io. And everyone hates having to spend a bunch of time researching and comparing alternatives. Battery packs can serve as a good set of default choices. And they don’t lock you in. At heart, they’re basically just a list of recommended crates, so you can always swap something out if you find an alternative.

We’ve got a prototype of the battery pack tool working today, so you can try it out if you’re curious. Just run cargo install cargo-bp and then try a few commands! For example,

> cargo bp list

will show you the set of available battery packs, based on a crates.io search (as I’ll explain below, a battery pack is itself packaged and distributed as a crate, but not one that you take a direct dependency on). And cargo bp add will add batteries from a battery pack into your crate, so e.g.

> cargo bp add cli

would let you select and add common CLI libraries. If you want to see a more involved demo, try out cargo bp add embedded, which is derived from the Awesome Embedded Rust repository.

Let’s talk about you and me

One of the key ideas from battery packs is that anybody can publish one. They are just a crate named X-battery-pack; the dependencies of that crate are your recommendations. Features are designations of common sets of crates frequently used together. The examples are your templates. And so forth.

Letting anybody create a battery pack is in contrast to the previous ideas for an “extended standard library for Rust”¹, and it is intended to address some of Rust’s unique challenges. For one thing, it lets people publish battery packs that are tailored to specific requirements. For example, the CLI and backend service battery packs are targeting a “typical computer”. But I could imagine the Rust embedded working group publishing a battery pack with libraries focused on no-std and binary size optimization.

Being open-ended also addresses the “who decides?” question. To my mind, the best people to recommend what libraries you ought to use are other people building systems like yours. This is why I mentioned the Embedded Working Group publishing an Embedded battery pack, for example, as I think they are clearly a set of people who know their space well. But even within the embedded space there are yet smaller groups, and I imagine that sometimes it’ll make sense to get narrower. For example, perhaps a battery pack targeted embassy and its associated ecosystem? Unclear.

Creating a battery pack

If you wanted to create a battery pack, how do you do it? One answer is that you just create a new crate. But a better approach is to use the “battery-pack battery pack”², which bundles a template:

cargo bp new battery-pack

This will prompt you for the name of the battery pack you want to create and a few other things and make your crate. Then you can just use cargo add dependencies to represent the libraries you want to recommend and publish.

“Batteries” are more than dependencies

The “batteries” that you can add to your project aren’t always dependencies. They can also be “recipes” or templates. For example, the CI battery pack³ can configure your project with the kind of “super neat-o” github actions you’ve always wanted but never wanted to bother configuring. To use it, select one or more of the templates to install:

cargo bp add ci

I expect this kind of “actions to improve your crate” to become a rich source of things. Right now we’re using a relatively lightweight template system built on minijinja, but I think we’re going to want to expand on this.

Giving it some structure

Battery Packs also support more than just a flat listing of dependencies/features/templates. You can group dependencies and features into categories and then, for each category, distinguish between “pick at most one” or “pick any number”. For a fun example, try cargo bp add embedded, which is derived from the Awesome Embedded Rust repository. If you run it, you’ll see something like this, which groups the choices thematically and, in some areas like “concurrency framework”, makes it clear that you want to pick one:

──────────────────────────────────────────────────────────────────
 ▼ Concurrency Framework (pick at most one)
 > ○ ✦ embassy [embassy-executor, embassy-sync, embassy-time]
   ○ ✦ rtic [cortex-m, rtic]    RTIC — interrupt-driven real-time

 ▼ Display & Graphics (pick any number)
   [ ] ✦ display-ssd1306 [embedded-graphics, ssd1306]    SSD1306
   [ ] ✦ display-st7789 [embedded-graphics, st7789]    ST7789 col

 ▼ Popular Drivers (pick any number)
   [ ] ✦ display-ssd1306 [embedded-graphics, ssd1306]    SSD1306
   [ ] ✦ display-st7789 [embedded-graphics, st7789]    ST7789 col
   [ ] ✦ sensor-bme280 [bme280]    BME280 temperature/humidity/pr
   [ ] ✦ sensor-lis3dh [lis3dh]    LIS3DH 3-axis accelerometer (I
   [ ] ✦ usb-device [usb-device, usbd-serial]    USB device stack

 ▼ Hardware Abstraction Layer (pick at most one)
   ○ ✦ atsamd [atsamd-hal, cortex-m-rt, critical-section-impl, co
   ○ ✦ esp32 [embedded-hal, esp-hal]    ESP32 (Xtensa, WiFi + BT,
   ○ ✦ esp32c3 [embedded-hal, esp-hal]    ESP32-C3 (RISC-V, WiFi
   ○ ✦ esp32s3 [embedded-hal, esp-hal]    ESP32-S3 (Xtensa, WiFi
   ○ ✦ nrf52832 [cortex-m-rt, critical-section-impl, cortex-m, em
   ○ ✦ nrf52840 [cortex-m-rt, critical-section-impl, cortex-m, em
   ○ ✦ nrf9160 [cortex-m-rt, critical-section-impl, cortex-m, emb
   ○ ✦ rp2040 [cortex-m-rt, critical-section-impl, cortex-m, embe
   ○ ✦ stm32f0 [cortex-m-rt, critical-section-impl, cortex-m, emb
 embedded-battery-pack v0.1.0  ↑↓/jk Navigate | Space Toggle | ←/→

Let’s talk about all the good things…

So why am I so keen on battery packs? It’s largely because I’ve heard so many would-be or recent Rust adopters talk about picking crates as a challenge. But I feel they would help with some other problems as well.

What I really want to see is working groups in the Rust Commercial Network banding together to publish battery packs and recommendations. These would cover the dependencies that they’re actually using.

Supporting maintainers

One of the reasons I want to have RCN-recognized battery packs is that they are a natural focal point to then prompt RCN members to fund the maintenance of those crates. I am imagining that for each sponsored battery pack vended within the RCN, there is an associated “ecosystem fund”. Companies or individuals could sponsor this fund to get access to early patches, security disclosures, etc or other perks. The money would be used to support the maintainers of those crates, to implement missing features, and so forth.

Fostering interoperability

Another value-add from battery packs is the ability to drive interop efforts. I think that as soon as we start talking about standardizing, we’re also going to recognize that there are some places where standardization is hard. For example, early conversations within the network service working group (unsurprisingly) immediately identified that while most people are using tokio, some major companies are using their own runtimes internally. It’s not like the need for “async runtime interop” is news. But right now, every crate winds up effectively implementing their own set of little traits to make it work. Sponsored battery packs offer the possibility of a neutral home for that sort of thing.

…and the bad things that could be

There are some risks to people using battery packs. The most obvious is that the fact that anybody can publish a battery pack may mean that you just get a ton of battery packs, which doesn’t really help anybody! I’m not so worried about this because I think that there will be a few obvious places that most people go first, and then I think once people are oriented, they’ll get excited to explore what crates.io has to offer and start discovering more niche battery packs.

Avoiding stagnation

Battery packs are designed to evolve. I’ve seen it happen a number of times that there is a dominant crate for something, often taking a “traditional approach”, but then somebody else comes along and presents an interesting alternative that gradually takes off. I love that and I don’t want to put it at risk.

One example of evolution around CLI argument parsing. For a time, docopt was a popular way to parse command-line options. Then clap came along and presented a more structured alternative; that was nice, but then structopt came along and connected clap to an auto-derive, so you could just write your data structure and be done. And that was awesome. (That is now the standard in clap.) I want to be sure that, even if there is a CLI battery pack, there’s room for the next clap to come along.

There are a few things about battery pack that I think will help us deal with this. First, they are a “thin abstraction”. You don’t “depend on” a battery pack, you depend on the crates within it. So if a new version comes out that uses clap instead of docopt, that doesn’t impact you at all. Your code keeps working same as it ever did. And of course it helps that anybody can publish a battery pack. You can now have variations on battery packs that are focused around a new approach to help it get started.

Done right, I think that standardized battery packs can also help the ecosystem evolve and pivot. As it is now, knowledge of new crates has to spread by word-of-mouth. But if everybody is aligned around a new approach, adopting that new approach within a battery packs sends a clear signal that your group is aligned that something is the new hotness.

…Let’s talk about crates⁴

“Always bet on the ecosystem”

I see always bet on the ecosystem as a key Rust design axiom. It’s the reason we chose a small standard library and a package manager in the first place. It’s also why battery packs are designed to be published by anyone.

But just like plants sometimes need a trellis to grow taller, any successful ecosystem reaches a point where it needs another layer of structure to help it keep growing. Without that, you have this “layer of tacic knowledge” (in the words of a Rust Vision Doc interviewee) that becomes an obstacle for folks. And I think we’ve reached that point with crates.io.

I am hopeful that battery packs can provide that next layer of structure. But at the end of the day, if there’s a better approach, that’s fine too, so long as we find a way to help people find (and fund!) the crates they need. So let’s talk about it!

Seit einiger Zeit verkaufen die Hersteller Notebooks als KI-PC oder Copilot+ PC. Der Zusatz steht für einen Umbau der inneren Technik. Neben dem Hauptprozessor (CPU) und der Grafikeinheit (GPU) sitzt jetzt ein dritter Baustein auf dem Chip, die neuronale Recheneinheit (Neural Processing Unit, NPU). Die NPU berechnet KI-Funktionen energieeffizient direkt auf dem Gerät. Wer ein KI-Notebook kaufen möchte, sollte auf die entscheidende Leistungskennzahl achten.

Für das Siegel Copilot+ verlangt Microsoft eine NPU mit mindestens 40 TOPS, dazu 16 GByte Arbeitsspeicher und 256 GByte SSD. Aktuelle Notebook-Chips erreichen das mühelos, so kommt Intels Core Ultra Series 3 auf 50 TOPS allein für die NPU.

AMD (Ryzen AI 300 und 400), Qualcomm (Snapdragon X2) und Apple (M-Serie mit Neural Engine) liefern NPUs in ähnlicher Größenordnung. Erst die Rollenverteilung zwischen den drei Rechenwerken sorgt für flüssige KI-Funktionen im täglichen Gebrauch.

Die CPU steuert und verteilt

Die CPU steuert alle Vorgänge im Notebook. Sie startet Programme, verwaltet den Arbeitsspeicher und hält das Betriebssystem aktiv. Ihre wenigen, dafür kräftigen Kerne arbeiten Befehle nacheinander ab und eignen sich für verzweigte Aufgaben mit vielen Entscheidungen.

Bei KI-Funktionen übernimmt die CPU die Rolle des Verteilers. Sie erkennt, welche Art von Aufgabe ansteht, und schickt sie an das passende Rechenwerk. Eine Echtzeitaufgabe geht zur NPU, eine schwere Rechenlast zur GPU, eine reine Systemaufgabe bleibt bei der CPU selbst.

Sobald das Ergebnis vorliegt, fügt die CPU es an der richtigen Stelle ein, zum Beispiel den unscharfen Hintergrund in dein Videobild.

AMD

Die GPU rechnet massiv parallel

Die GPU (Diese Grafikkarten sind ihr Geld wert) rechnet mit Hunderten bis Tausenden kleiner Kerne, die gleiche Rechenschritte gleichzeitig ausführen. Die Bauweise kommt aus der Grafikdarstellung und taugt genauso für KI. Beim Spielen, bei der Videobearbeitung und beim 3D-Rendering liefert die GPU die Rechenleistung, ebenso beim Training großer KI-Modelle und bei schweren parallelen Rechenlasten.

Im Notebook steckt die GPU in zwei Formen. Eine integrierte Grafikeinheit sitzt zusammen mit CPU und NPU auf einem Chip, zum Beispiel Intel Arc oder AMD Radeon. Eine dedizierte Grafikkarte wie eine NVIDIA GeForce RTX bringt eigenen Videospeicher (VRAM) mit und schafft mehr Leistung, zieht dafür mehr Strom und erzeugt mehr Wärme.

XFX

Die NPU spart Strom bei KI

Die NPU ist auf eine einzige Sorte Mathematik ausgelegt, die hinter neuronalen Netzen steckt. Es geht um Matrixrechnungen, also viele Multiplikationen und Additionen auf einmal. Genau dafür nutzt die NPU spezielle Recheneinheiten (MAC) und schnellen Speicher direkt auf dem Chip, damit die Daten kurze Wege haben.

Der große Vorteil ist der niedrige Stromverbrauch. Eine NPU zieht für KI-Aufgaben nur wenige Watt, eine Grafikkarte im Rechenzentrum kommt unter voller Trainingslast auf mehrere Hundert Watt.

Die NPU rechnet zudem häufig mit vereinfachter Genauigkeit (INT8 statt der feineren Formate einer GPU). Das spart Energie und beschleunigt die Antwort, reicht für KI-Inferenz aber völlig aus.

KI-Inferenz meint das Ausführen eines fertig trainierten Modells, also das Anwenden. Das Anlernen des Modells bleibt Sache der GPU. Für Grafik, Spiele oder allgemeine Programme taugt die NPU nicht. Ihre Stärke liegt allein bei KI, die dauerhaft und im Hintergrund aktiv ist.

Sam Singleton

Was TOPS wirklich aussagen

TOPS steht für Tera Operations Per Second, also Billionen Rechenoperationen pro Sekunde. Eine NPU mit 50 TOPS schafft 50 Billionen Rechenoperationen in einer Sekunde. Je höher der Wert, desto mehr KI-Rechenschritte passen in dieselbe Zeit.

Ein Vergleich der TOPS allein ist wenig aussagekräftig. Die NPU rechnet mit vereinfachter Genauigkeit und meldet andere Werte als eine GPU, deren TOPS Grafik und KI zusammenfassen. Desktop-Grafikkarten kommen so auf über 1.000 TOPS, ihre NPU-Kollegen im Notebook auf 40 bis 80. Beide Zahlen messen nicht dasselbe.

Für den Kauf zählt eine Angabe. Wirbt ein Hersteller mit einer hohen Gesamtzahl aus CPU, GPU und NPU, sagt das wenig über das Copilot+ Siegel. Microsoft verlangt die 40 TOPS allein von der NPU. Ein prüfender Blick auf den NPU-Wert im Datenblatt schützt vor Enttäuschung.

Warum lokale KI Ihnen nützt

KI direkt auf dem Notebook (Was kann KI lokal auf dem PC? 7 Anwendungsmöglichkeiten) bringt mehrere handfeste Vorteile gegenüber der Cloud:

• Datenschutz: Fotos, Dokumente und Sprachaufnahmen bleiben auf dem Gerät und gelangen nicht auf fremde Server.
• Tempo: Die Antwort kommt ohne Umweg über das Internet, oft in Echtzeit.
• Offline-Betrieb: Funktionen wie Übersetzung oder Rauschunterdrückung arbeiten auch ohne Verbindung.
• Akku: Die sparsame NPU hält KI-Funktionen aktiv, ohne den Akku schnell zu leeren.

Eine Grenze gehört dazu. Cloud-Dienste wie ChatGPT oder Google Gemini rechnen auf externen Servern. Eine NPU beschleunigt sie nicht, denn die Arbeit passiert gar nicht auf deinem Gerät. Der NPU-Vorteil greift bei lokalen Funktionen, zum Beispiel den KI-Effekten in Videocalls oder einem Sprachmodell, das direkt auf dem Notebook antwortet.

Microsoft

NPU-Funktionen unter Windows

Windows verteilt passende Aufgaben von sich aus an die NPU. In Videocalls sorgen die Windows Studio Effects für Hintergrundunschärfe, korrigierten Blickkontakt und eine ruhigere Tonspur. Live Captions übersetzen gesprochene Sprache in Untertitel, die Funktion Cocreator erzeugt Bilder aus einer Textbeschreibung, und Recall macht frühere Bildschirminhalte durchsuchbar.

Auch außerhalb von Windows nutzen Programme die NPU. Foto- und Videobearbeitung entfernt Objekte, tauscht Hintergründe oder rechnet Bilder hoch. Kleine Sprachmodelle antworten direkt auf dem Notebook, ohne Daten nach außen zu geben. Ob die NPU gerade arbeitet, zeigt der Windows-Task-Manager im Bereich “Leistung”.

NPU, TPU und der Blick über das Notebook

NPUs stecken nicht nur in Notebooks. Smartphones enthalten sie seit Jahren, Apple brachte mit dem iPhone X eine frühe Variante, Huawei kurz darauf eine eigene. Im Rechenzentrum gibt es eine verwandte Sonderform, die TPU (Tensor Processing Unit) von Google. Sie ist auf das KI-Framework TensorFlow zugeschnitten und beschleunigt KI-Dienste in der Cloud.

Kaufhinweise für Ihr KI-Notebook

Die drei Rechenwerke ergänzen sich. Die CPU steuert und verteilt, die GPU liefert rohe Parallelleistung für Grafik und Modelltraining, die NPU erledigt dauerhafte KI-Aufgaben energiesparend. Für ein neues KI-Notebook lohnt der Blick auf den NPU-Wert.

40 TOPS öffnen die Copilot+ Funktionen von Windows, mehr Reserve mit 50 bis 80 TOPS aktueller Chips hält länger für kommende KI-Features vor. Dazu gehören 16 GByte Arbeitsspeicher als sinnvolle Untergrenze. Damit bist du für die KI-Funktionen der nächsten Jahre gut aufgestellt.

Google shipped an update to its open AI model Gemma 4 that speeds up performance on Nvidia Hopper GPUs, fixes tool calling bugs, and addresses problems with truncated responses.

The article Gemma 4 gets a stealth update that fixes tool calling bugs and truncated responses under the same name appeared first on The Decoder.

Palit hat die GeForce RTX 3060 Infinity 2 OC vorgestellt. Diese Grafikkarte auf Basis der Ampere-Architektur ist mit 12 GB GDDR6-Videospeicher ausgestattet und für das Spielen in 1080p-Auflösung gedacht. Es scheint das erste neue Modell nach dem erneuten Produktionsstart der RTX 3060 12 GB zu sein.

Rachad Alao, vice president of product engineering at the rising Canadian enterprise AI startup Cohere, joined VentureBeat CEO and editor-in-chief Matt Marshall for a fireside chat about building agentic systems without surrendering sensitive data, infrastructure control, or the ability to change vendors.

Alao, who previously led responsible AI and trust and safety engineering teams at Google and Meta, argued that AI sovereignty means more than downloading an open model or running an application behind a corporate firewall.

Asked how Cohere defines sovereignty, Alao pointed to organizations operating mission-critical systems, including banks, hospitals and governments.

“It is important to have very tight control on where the data resides, have tight control on the AI,” he said, adding that AI operations should take place in jurisdictions an organization understands or directly controls.

That extends from GPUs and private-cloud infrastructure through governance systems that route requests among models, as well as the connectors, search tools and agent frameworks acting on enterprise data.

“You want to have control on the entire stack,” Alao said.

Agent workloads could outrun falling token prices

Marshall challenged one of the central economic arguments for smaller, locally deployed models: Inference prices continue to fall rapidly, potentially weakening the case for optimizing every token.

Alao countered that total consumption is climbing even faster as enterprises move from relatively simple chatbots to agents that reason through problems, call tools, search internal systems and take multiple steps before returning an answer.

“Your token utilization is going exponentially up, because you’re dealing with more and more complex agentic use cases,” he said. Those workflows require “a lot of processing, thinking, tools interaction” to complete their objectives, he added.

Alao also drew a contrast between providers that bill customers according to token consumption and Cohere’s approach.

“If your whole way of charging customers is for token utilization, you want to maximize token utilization,” he said. “We do not sell our models and our platform that way.”

Instead, Alao said Cohere tries to help enterprises solve their hardest problems privately and securely while reducing unnecessary model usage. His prescription was straightforward: “Use the right model for the task at hand.”

Rather than sending every request to the largest available frontier model, enterprises should route work according to the intelligence required and the sensitivity or regulatory burden attached to the task.

Alao cited an unnamed Canadian bank that uses Cohere’s on-premises models for highly regulated workloads, while sending less sensitive tasks requiring greater intelligence through Cohere’s North platform to larger frontier models.

“So model routing can become super useful,” he said.

Smaller models for most enterprise work

Asked by an audience member how Cohere’s open-source North Mini Code, released last month, could compete against proprietary coding models, Alao acknowledged that larger frontier models may perform somewhat better on the hardest tasks.

But that advantage may not justify using them indiscriminately.

“For 80% of the use cases that they needed, this was a lot more effective, a lot cheaper,” Alao said of developers adopting the model.

Cohere’s North Mini Code runs on a single Nvidia H100 GPU and targets agentic software engineering, including terminal work, code review and tool use.

The company has also released Command A+, a 218-billion-parameter mixture-of-experts model with only 25 billion parameters active during each generation step.

Its compressed four-bit version reduces the hardware required for private deployment, while its Apache 2.0 license gives enterprises broad freedom to operate and modify it.

Search becomes part of the agent

Asked about Cohere’s longstanding work on embeddings and enterprise search, Alao said the field is moving beyond retrieving text and inserting it into a model’s context window.

“Today, the state of the art is around multimodal search,” he said. “It’s beyond just the text modality.”

Search across documents, images and other forms of information is becoming “an integral component of your agentic workflow,” Alao added, with the model deciding when and how to use retrieval like any other tool.

Asked what would persuade enterprises to move beyond bundled AI services from existing cloud providers, Alao returned to data control and portability.

“If you’re interested in sovereignty, you want to have more control on your data,” he said. Cohere’s governance layer, he added, lets customers route traffic to appropriate models, “breaking that vendor lock-in concern that a lot of our customers have.”

Ein neuer Laptop ist eine Investition für die nächsten Jahre. Doch bevor man sich in Datenblättern zu Prozessoren, RAM und Grafikkarten verliert, steht die wichtigste und buchstäblich größte Entscheidung an: das Gehäuseformat. Schließlich bestimmt die Bildschirmdiagonale nicht nur, wie viel Arbeitsfläche Ihnen zur Verfügung steht – sie diktiert auch das Gewicht, die Akkugröße und die Kühlleistung Ihres neuen Systems.

Während vor wenigen Jahren noch der 15,6-Zöller als unangefochtener Standard galt, hat sich der Markt inzwischen gewandelt. Die Ränder um die Displays sind geschrumpft, moderne 16:10-Bildformate erobern die Schreibtische und stellen Käufer vor eine technologische Grundsatzfrage.

Die Eier legende Wollmilchsau gibt es nämlich auch hier nicht: Wer stundenlang Videos schneidet oder Excel-Tabellen wälzt, flucht über einen zu kleinen Bildschirm. Wer sein Gerät hingegen täglich in der Bahn zum Pendeln nutzt, ärgert sich schnell über jedes Gramm zu viel im Rucksack.

Damit Sie beim Kauf nicht zum falschen Formfaktor greifen, dröseln wir die Stärken und Schwächen der drei wichtigsten Laptop-Größen auf und geben eine Kaufberatung für die unterschiedlichen Nutzerprofile.

Die drei Display-Größen im Alltags-Check

Um das Maximum aus Ihrem Budget herauszuholen, sollten Sie die Charakteristiken der Formfaktoren kennen. Jede Größe hat ein optimales Einsatzgebiet.

1. 14-Zoll-Laptops: Mobile Begleiter für Pendler

Der 14-Zöller (ca. 35,5 cm Diagonale) ist das gängige Format für alle, die häufig unterwegs sind. Moderne Fertigungstechniken erlauben ein Gerätegewicht von oft kaum mehr als einem Kilogramm, zudem sind die Geräte so dünn, dass sie problemlos in jede Aktentasche oder den Uni-Rucksack passen.

Durch das kompakte Gehäuse ist der Akkuverbrauch des Displays geringer, was oft zu ausgezeichneten Laufzeiten führt. Das Manko: Die kompakte Bauweise lässt wenig Platz für wuchtige Kühlsysteme oder dedizierte Grafikkarten. Zudem erfordert längeres Multitasking mit mehreren geöffneten Fenstern auf dem kleineren Bildschirm oft gute Augen oder cleveres Fenster-Management.

Für wen eignen sich 14-Zoll-Laptops?

Das Format ist besonders geeignet für Pendler, Studenten, Geschäftsreisende und alle, die ihren Laptop täglich transportieren. Wer primär textbasiert arbeitet, surft, streamt oder an Videocalls teilnimmt, wird die Leichtigkeit dieser Geräteklasse lieben.

Produktempfehlung: ASUS Zenbook 14 OLED

Asus

Preis: 1.149 Euro

Technik-Specs:

• Bilddiagonale & Format: 14 Zoll (35,6 cm), Seitenverhältnis 16:10, NanoEdge-Design (schmale Ränder)
• Auflösung & Panel-Typ: 2,8 K (2.880 × 1.800 Pixel), Lumina-OLED-Panel
• Farbraum & Helligkeit: 100 % DCI-P3-Abdeckung, maximale Spitzenhelligkeit 550 Nits
• Bildwiederholrate & Reaktionszeit: 120 Hz, 0,2 ms (Herstellerangabe)
• Gewicht & Maße: 1,2 kg, 14,9 mm Bauhöhe
• Prozessor & Grafik: AMD Ryzen AI 7 350 (inklusive dedizierter NPU für KI-Berechnungen), integrierte AMD Radeon Grafikeinheit
• Speicher: 16 GB LPDDR5X RAM, 1 TB PCIe Gen4 x4 SSD
• Akkukapazität: 75 Wh (laut Hersteller ausgelegt auf hohe Langlebigkeit mit 70 % Restkapazität nach 1200 Ladezyklen)
• Audio & Extras: Soundsystem von Harman Kardon mit Dolby Atmos und KI-Geräuschunterdrückung, beleuchtete Tastatur (QWERTZ-Layout)
• Betriebssystem: Windows 11 Home (Copilot+ PC zertifiziert)

Das Asus Zenbook 14 OLED demonstriert anschaulich, warum 14-Zöller aktuell so beliebt sind. Trotz des geringen Gewichts von nur 1,2 Kilogramm bietet das Notebook mit seinem AMD Ryzen AI 7 350 Prozessor und 16 GB Arbeitsspeicher genügend Leistungsreserven für Office-Anwendungen, Multitasking und leichte Bildbearbeitung. Das hochauflösende 2,8K-OLED-Display mit 120 Hz sorgt dabei für eine scharfe Darstellung, kräftige Farben und flüssige Bildabläufe.

Ein praktisches Detail für den mobilen Alltag ist dabei auch das kompakte Gehäuse mit nur 14,9 Millimetern Bauhöhe. Gleichzeitig verbaut Asus einen großzügigen 75-Wh-Akku, der laut Hersteller Laufzeiten von bis zu 18 Stunden ermöglichen soll. Die Ausstattung wird speziell für Videokonferenzen und Multimedia-Anwendungen durch Dolby-Atmos-Lautsprecher von Harman Kardon sowie eine integrierte KI-Geräuschunterdrückung abgerundet.

2. 15-Zoll-Laptops: Preisbewusste Allrounder

Das 15-Zoll-Segment gilt bis heute als der klassische Mittelweg zwischen Mobilität und Arbeitsfläche. Je nach Hersteller kommen im 15-Zoll-Bereich sowohl klassische 16:9- als auch moderne 16:10-Displays zum Einsatz.

Das 16:9-Format eignet sich besonders gut für den Medienkonsum, etwa für Filme und Serien, ohne störende schwarze Balken. Das 16:10-Format bietet dagegen mehr vertikale Bildschirmfläche – ein Vorteil beim Arbeiten mit Dokumenten, Tabellen oder längeren Webseiten.

Weil die Gehäuse oft auf bewährten, kostengünstigen Chassis-Designs der Hersteller basieren, bekommt man in dieser Klasse in der Regel das meiste Datenblatt für sein Geld. Zudem bieten 15-Zöller fast immer einen vollwertigen, physischen Nummernblock auf der rechten Seite der Tastatur.

Für wen eignen sich 15-Zoll-Laptops?

Der klassische 15-Zöller richtet sich an preisbewusste Käufer, Homeoffice-Nutzer, die keinen externen Monitor besitzen, und Nutzer, die ihr Notebook meistens in der Wohnung einsetzen oder das Gerät nur gelegentlich mit auf Reisen nehmen.

Produktempfehlung: Lenovo IdeaPad Slim 3 (15″)

Lenovo

Preis: ca. 682 Euro

Technik-Specs:

• Bilddiagonale & Format: 15,6 Zoll (39,6 cm), Seitenverhältnis 16:10
• Auflösung & Panel-Typ: WUXGA (1920 × 1200 Pixel), LC-Display
• Gewicht & Maße: ca. 1,6 kg, 17,9 mm Bauhöhe
• Prozessor & Grafik: Intel Core i5-13420H, Intel UHD Grafik
• Speicher: 16 GB DDR5-RAM, 512 GB SSD
• Akkukapazität: 42 Wh
• Tastatur: QWERTZ-Layout mit integriertem Nummernblock
• Software & Extras: Smart Connect, 3 Monate Lenovo Premium Care, 24 Monate Herstellergarantie
• Anschlüsse & Konnektivität: 2 USB-Anschlüsse, HDMI, WLAN, Bluetooth
• Betriebssystem: Windows 11 Home

Das Lenovo IdeaPad Slim 3 (Modell: 15IRH10) richtet sich an Nutzer, die ein solides Notebook für Alltag, Studium und Homeoffice suchen. Mit seinem 15,6 Zoll großen WUXGA-Display im modernen 16:10-Format bietet es etwas mehr vertikale Arbeitsfläche als klassische 16:9-Modelle – ein Vorteil beim Arbeiten mit Dokumenten, Tabellen oder längeren Webseiten. Trotz der großzügigen Bildschirmfläche bleibt das Gerät mit rund 1,6 Kilogramm angenehm mobil.

Für die Rechenleistung sorgt ein Intel Core i5-13420H Prozessor, der zusammen mit 16 GB DDR5-Arbeitsspeicher genügend Reserven für Office-Anwendungen, Multitasking und alltägliche Multimedia-Aufgaben bietet. Anspruchsvolle Spiele oder grafikintensive Anwendungen sind hingegen nicht die Stärke dieses Modells, da ausschließlich die integrierte Intel-UHD-Grafik zum Einsatz kommt.

Praktisch im Alltag ist die Smart-Connect-Funktion von Lenovo, mit der sich kompatible Smartphones, Tablets und PCs einfacher miteinander verbinden und Daten austauschen lassen. Damit positioniert sich das IdeaPad Slim 3 klar als klassischer Allrounder für produktives Arbeiten zu Hause, im Büro oder im Studium.

3. 16-Zoll-Laptops: Mobile Kraftpakete

Der 16-Zöller (ca. 40,6 cm Diagonale) ist der moderne Nachfolger der alten, klobigen 15,6- und 17-Zoll-Workstations. Dank besonders schmaler Displayränder passen 16-Zoll-Bildschirme heute in Gehäuse, die früher für 15 Zoll reserviert waren. Fast alle Geräte in dieser Klasse setzen auf das höhere 16:10-Format, was beim Arbeiten spürbar mehr vertikale Bildschirmfläche (z. B. für Code-Zeilen oder Webseiten) bietet.

Der entscheidende Vorteil dieser Größe: Das große Gehäuse bietet reichlich Platz für leistungsstarke Kühlsysteme und große Akkus (bis zum gesetzlichen Flugzeug-Limit von 99 Wattstunden). Hier finden leistungsstarke Prozessoren und dedizierte Grafikkarten deutlich bessere Kühlbedingungen als in kompakteren Gehäusen.

Für wen eignet sich die 16-Zoll-Größe?

Für Power-User, Content Creator (Foto/Video), ambitionierte Gamer und Nutzer, die den Laptop als vollwertigen Desktop-Ersatz (Desktop Replacement) nutzen möchten.

HP Omen MAX Gaming Laptop (16″)

HP

Preis: 2.199 Euro

Technik-Specs:

• Bilddiagonale & Format: 16 Zoll (40,6 cm), Seitenverhältnis 16:10
• Auflösung & Panel-Typ: WQXGA (2560 × 1600 Pixel), IPS-Display
• Bildwiederholrate: 240 Hz
• Gewicht & Maße: ca. 2,71 kg, 2,5 cm Bauhöhe
• Prozessor & Grafik: AMD Ryzen AI 7 350 (bis zu 5,0 GHz)
• Grafik: integrierte AMD Radeon 860M Grafik und NVIDIA GeForce RTX 5070 Ti (12 GB VRAM)
• Speicher: 32 GB RAM, 1 TB SSD
• Akkukapazität: 83 Wh
• Tastatur: QWERTZ-Layout mit Hintergrundbeleuchtung und Nummernblock
• Anschlüsse & Konnektivität: USB, HDMI, Ethernet, WLAN 7, Bluetooth 5.4
• Betriebssystem: Windows 11 Home

Der HP Omen MAX Gaming Laptop positioniert sich als leistungsstarkes 16-Zoll-Notebook für anspruchsvolles Gaming und Content Creation. Das WQXGA-Display (2560 × 1600 Pixel) mit 240 Hz Bildwiederholrate verspricht besonders flüssige Bewegungsdarstellung mit hoher Schärfe, während die IPS-Technologie für stabile Farbdarstellung sorgt.

Im Inneren arbeitet ein AMD Ryzen AI 7 350 Prozessor in Kombination mit einer NVIDIA GeForce RTX 5070 Ti mit 12 GB VRAM. Die Kombination liefert ausreichend Leistung für aktuelle AAA-Spiele, kreative Anwendungen und Multitasking auf hohem Niveau. Ergänzt wird die Ausstattung durch 32 GB Arbeitsspeicher sowie eine 1-TB-SSD für schnelle Ladezeiten und ordentlich Speicherplatz.

Mit einem 83-Wh-Akku und einem Gewicht von rund 2,7 Kilogramm ist das Gerät klar auf Leistung statt maximale Mobilität ausgelegt. Gleichzeitig bietet es eine umfangreiche Anschlussausstattung inklusive Ethernet, HDMI, USB und moderner WLAN-7-Konnektivität. Damit richtet sich dieser Laptop an Nutzer, die ein leistungsstarkes Gaming-Notebook mit Desktop-Anspruch suchen – und den Kaufpreis nicht scheuen.

Welche Notebook-Größe passt zu mir?

Die perfekte Notebook-Größe ist immer ein Kompromiss: Mehr Bildschirm bedeutet automatisch mehr Gewicht und weniger Mobilität. Die folgende Matrix hilft Ihnen dabei, Ihre eigenen Prioritäten zu gewichten und den optimalen Kompromiss für Ihren Alltag zu finden.

Software-Tipps für Ihren Laptop-Alltag

Egal, ob Sie sich für das kompakte 14-Zoll-Modell oder den 16-Zoll-Boliden entscheiden – mit diesen drei kostenlosen Software-Tools holen Sie noch mehr aus Ihrem mobilen Arbeitsplatz heraus:

• Microsoft PowerToys (FancyZones): Gerade auf den kleineren 14-Zoll-Displays ist das Standard-Fensterlayout von Windows oft fummelig. Mit dem Modul FancyZones unterteilen Sie Ihren Bildschirm in feste, frei definierbare Raster, in die Sie Fenster mit gedrückter Shift-Taste blitzschnell einrasten lassen. Ein absolutes Must-Have für Multitasking auf kleinen Displays.
• SpaceDesk: Sie sind im Hotel und der 14-Zöller reicht nicht für die Excel-Tabelle aus? SpaceDesk ist eine geniale kostenlose Software, mit der Sie Ihr iPad oder Android-Tablet kabellos über WLAN als vollwertigen, zweiten Windows-Monitor nutzen können. Perfekt für das mobile Büro.
• Everything: Laptops werden oft beruflich wie privat vollgepackt mit Dateien. Statt der langsamen Windows-Standard-Suche baut Everything einen superschnellen Index Ihrer Festplatte auf. Dateien, Fotos oder Dokumente werden in Echtzeit gefunden – buchstäblich schon während Sie den Dateinamen tippen.

Fazit: Welcher Laptop-Typ sind Sie?

Das perfekte Notebook richtet sich nicht nach dem Geldbeutel, sondern nach dem Einsatzzweck. Wer primär pendelt, in verschiedenen Meetingräumen sitzt oder das Gerät täglich in die Vorlesung schleppt, wird mit einem 14-Zoll-Laptop am glücklichsten.

Die gesparten Kilos auf dem Rücken rechtfertigen den kleineren Bildschirm allemal. Wer einen soliden Rechner für das Homeoffice sucht, nur selten verreist und beim Kauf auf das Budget achten muss, macht mit dem klassischen 15-Zöller nichts falsch.

Wenn für Sie das Notebook jedoch den klobigen Desktop-PC unter dem Schreibtisch komplett ersetzen soll, Sie professionell Videos schneiden oder aktuelle AAA-Spiele flüssig spielen wollen, führt kein Weg am 16-Zoll-Kraftpaket vorbei. Die massive Arbeitsfläche und das hervorragende Kühlpotenzial gleichen das stattliche Transportgewicht in diesem Fall problemlos auf.

The post Best Cheap Web Hosting Services – Guide – AddictiveTips 2026 appeared first on AddictiveTips.

Manche PC-Upgrades bringen spürbar mehr Leistung, andere verbrennen nur Ihr Geld. Entscheidend ist, gezielt dort nachzurüsten, wo echte Flaschenhälse die Performance begrenzen. Welche Upgrades das sind – und wo Sie aktuell besonders gut zweimal nachdenken sollten – zeigen wir Ihnen hier.

NVMe-SSD: Für fast jeden PC ein sofortiger Gewinn

Eine schnelle NVMe-SSD ist für beinahe jedes System ein deutlicher Gewinn. Sie bietet gegenüber klassischen HDDs nicht nur wesentlich kürzere Zugriffszeiten, sondern erreicht auch hohe sequenzielle sowie zufällige Transferraten. Das verkürzt Ladezeiten spürbar, lässt Anwendungen praktisch verzögerungsfrei starten und sorgt für ein insgesamt reaktionsfreudigeres System.

Foundry

PCIe-4.0-Modelle sind mit einem Terabyte bereits ab rund 130 Euro erhältlich. Nach oben geht die Spanne bis etwa 200 Euro für Laufwerke mit bis zu 7.000 MB/s und DRAM-Cache. Bewährte Optionen in der oberen Klasse sind etwa die Crucial P310 1TB als solides Allround-Laufwerk oder die Samsung 990 PRO 1TB. Achten Sie beim Kauf auf die Schlagwörter “Gaming” oder “Videoschnitt” in der Produktbeschreibung. So können Sie sicher sein, dass das Laufwerk für dauerhaft hohe Lasten ausgelegt ist.

Einen Blick wert sind aber in jedem Fall auch PCIe-5.0-Modelle: Die fünfte Generation liefert Leseraten von bis zu 14.500 MB/s und liegt preislich inzwischen kaum noch über vergleichbaren PCIe-4.0-Laufwerken. Greift man ohnehin neu zu, sind die Acer Predator GM9 1TB oder die Lexar ARES PRO 1TB eine zukunftssicherere Wahl. Im Gaming-Alltag fällt der Unterschied zur vierten Generation kaum ins Gewicht, da aktuelle Spiele die zusätzliche Bandbreite bislang nicht ausreizen. Bei regelmäßigen Transfers gewaltiger Dateien oder der Arbeit mit 4K- und 8K-Videomaterial hingegen werden Sie den Leistungssprung durchaus bemerken.

Arbeitsspeicher: Jetzt genau hinschauen, bevor Sie kaufen

Arbeitsspeicher-Upgrades entfalten ihre Wirkung vor allem dann, wenn der Rechner regelmäßig an seine Auslastungsgrenze stößt. Ob RAM tatsächlich der Flaschenhals ist, verrät ein Blick in den Task-Manager: Öffnen Sie ihn mit Strg-Alt-Entf, wechseln Sie zum Reiter “Leistung” und beobachten Sie die Arbeitsspeicher-Auslastung unter Last. Klettert sie dauerhaft über 80 Prozent, ist ein Upgrade sinnvoll. Schnelleres RAM mit niedrigerer Latenz kann darüber hinaus die Leistung in speicherintensiven Anwendungen steigern.

Was Sie 2026 aber unbedingt wissen sollten: Der RAM-Markt hat sich seit Herbst 2025 dramatisch verändert. DDR5-6000-Kits mit 32 Gigabyte, die im Sommer 2025 noch für unter 100 Euro zu haben waren, kosten aktuell teils 400 bis 450 Euro. Ursache ist die stark gestiegene Nachfrage durch KI-Rechenzentren, die einen Großteil der globalen Speicherchip-Produktion beanspruchen.

Laut dem Marktforschungsinstitut TrendForce ist mit nennenswerten Preissenkungen frühestens ab Mitte 2027 zu rechnen. AMD selbst äußerte sich auf der Computex 2026 noch pessimistischer und nannte 2028 als realistischeres Datum. Wer auf AM4 mit DDR4 sitzt und damit zufrieden ist, sollte den Plattformwechsel deshalb gut abwägen. Ein Umstieg auf DDR5 zieht in der Regel auch ein neues Mainboard und eine neue CPU nach sich.

Grafikkarte: Das wirkungsvollste Gaming-Upgrade – mit einer wichtigen Faustregel

Für Gamer ist eine leistungsstarke GPU meistens das Upgrade mit dem größten Effekt: höhere Bildraten, stabilere Frametime-Verläufe, bessere Grafikqualität und die Unterstützung moderner Rendering-Techniken wie Raytracing sowie der KI-gestützten Upscaling-Verfahren DLSS 4 und FSR 4. Letztere sind 2026 keine optionalen Zusatzfeatures mehr, sondern der praktische Weg, in anspruchsvollen Titeln spielbare Frameraten zu erzielen.

Beim Kauf gilt eine Faustregel, die Sie unbedingt beachten sollten: Achten Sie auf ausreichend Grafikspeicher. Wie viel VRAM Sie für Ihren Gaming-PC wirklich benötigen, hängt stark von der Auflösung ab. Einen ausführlichen Überblick dazu finden Sie in unserem VRAM-Ratgeber. Als Orientierung gilt: 8 Gigabyte VRAM geraten bei aktuellen AAA-Titeln zunehmend an ihre Grenzen, 12 Gigabyte sind das sinnvolle Minimum, 16 Gigabyte der entspannte Sweetspot für die nächsten Jahre. Kauftipps für Ihre neue Grafikkarte finden Sie hier: Diese Grafikkarten sind ihr Geld wert.

Vor einer Neuanschaffung sollten Sie außerdem prüfen, ob Ihre CPU stark genug ist, um die neue GPU nicht auszubremsen. Mehr dazu im Folgenden.

Prozessor: Wann sich das teuerste Upgrade wirklich lohnt

Mehr Kerne, eine höhere IPC (Instructions per Cycle; Befehle, die ein Prozessor pro Taktzyklus abarbeitet) und moderne Befehlssätze bringen Vorteile in rechenlastigen Anwendungen, Rendering-Workflows und CPU-lastigen Spielen.

Ob die CPU tatsächlich bremst und ein Upgrade benötigt, zeigt der Task-Manager: Liegt die CPU-Auslastung unter Last dauerhaft nahe 100 Prozent, während die GPU noch Reserven hat, ist das ein deutliches Indiz für einen CPU-Engpass. Welche CPU-GPU-Kombinationen dabei gut harmonieren, erklärt unser Artikel: Die besten Grafikkarten-CPU-Kombinationen für Spieler.

Planen Sie dabei den Gesamtaufwand realistisch ein: Ein CPU-Wechsel zieht häufig auch ein neues Mainboard und passenden Arbeitsspeicher nach sich. Haben Sie keinen nachweisbaren Engpass, stecken Sie das Geld besser in GPU oder SSD. Dort ist der Effekt in den meisten Szenarien deutlich unmittelbarer. Kauftipps für Ihre neue Gaming-CPU finden Sie hier: Der ideale Gaming-Prozessor ab 80 Euro.

Foundry

Kühlung und Netzteil: Oft unterschätzt, aber wirkungsvoll

Die Kühlung gehört zu den Upgrades, die viele unterschätzen. Ein leiser Tower-Kühler oder eine AiO-Wasserkühlung senken nicht nur Temperaturen, sondern ermöglichen es auch, Boost-Taktraten länger zu halten. Das kann messbar mehr Leistung bedeuten.

Zusätzliche Gehäuselüfter optimieren den Airflow, halten die VRMs (Spannungswandler) kühler und verlängern hierdurch die Lebensdauer der Komponenten. Ein effizientes Netzteil mit hoher Spannungsstabilität ist besonders bei High-End-GPUs der aktuellen Generation relevant. Nvidias RTX-50-Karten setzen zudem auf den neuen 12V-2×6-Anschluss – das Netzteil sollte daher ATX 3.1 zertifiziert sein, um Lastspitzen sauber abzufangen und den Energieverbrauch zu senken. Kauftipps für Ihr neues Netzteil finden Sie hier: Die besten PC-Netzteile – unsere Empfehlungen von 650 bis 1650 Watt.

The post NVIDIA RTX 5070 Ti SUPER Could Bring 24GB VRAM and Higher Power Use appeared first on OnMSFT.

Read more of this story at Slashdot.

Manche PC-Upgrades bringen spürbar mehr Leistung, andere verbrennen nur Ihr Geld. Entscheidend ist, gezielt dort nachzurüsten, wo echte Flaschenhälse die Performance begrenzen. Welche Upgrades das sind – und wo Sie aktuell besonders gut zweimal nachdenken sollten – zeigen wir Ihnen hier.

NVMe-SSD: Für fast jeden PC ein sofortiger Gewinn

Eine schnelle NVMe-SSD ist für beinahe jedes System ein deutlicher Gewinn. Sie bietet gegenüber klassischen HDDs nicht nur wesentlich kürzere Zugriffszeiten, sondern erreicht auch hohe sequenzielle sowie zufällige Transferraten. Das verkürzt Ladezeiten spürbar, lässt Anwendungen praktisch verzögerungsfrei starten und sorgt für ein insgesamt reaktionsfreudigeres System.

Foundry

PCIe-4.0-Modelle sind mit einem Terabyte bereits ab rund 130 Euro erhältlich. Nach oben geht die Spanne bis etwa 200 Euro für Laufwerke mit bis zu 7.000 MB/s und DRAM-Cache. Bewährte Optionen in der oberen Klasse sind etwa die Crucial P310 1TB als solides Allround-Laufwerk oder die Samsung 990 PRO 1TB. Achten Sie beim Kauf auf die Schlagwörter “Gaming” oder “Videoschnitt” in der Produktbeschreibung. So können Sie sicher sein, dass das Laufwerk für dauerhaft hohe Lasten ausgelegt ist.

Einen Blick wert sind aber in jedem Fall auch PCIe-5.0-Modelle: Die fünfte Generation liefert Leseraten von bis zu 14.500 MB/s und liegt preislich inzwischen kaum noch über vergleichbaren PCIe-4.0-Laufwerken. Greift man ohnehin neu zu, sind die Acer Predator GM9 1TB oder die Lexar ARES PRO 1TB eine zukunftssicherere Wahl. Im Gaming-Alltag fällt der Unterschied zur vierten Generation kaum ins Gewicht, da aktuelle Spiele die zusätzliche Bandbreite bislang nicht ausreizen. Bei regelmäßigen Transfers gewaltiger Dateien oder der Arbeit mit 4K- und 8K-Videomaterial hingegen werden Sie den Leistungssprung durchaus bemerken.

Arbeitsspeicher: Jetzt genau hinschauen, bevor Sie kaufen

Arbeitsspeicher-Upgrades entfalten ihre Wirkung vor allem dann, wenn der Rechner regelmäßig an seine Auslastungsgrenze stößt. Ob RAM tatsächlich der Flaschenhals ist, verrät ein Blick in den Task-Manager: Öffnen Sie ihn mit Strg-Alt-Entf, wechseln Sie zum Reiter “Leistung” und beobachten Sie die Arbeitsspeicher-Auslastung unter Last. Klettert sie dauerhaft über 80 Prozent, ist ein Upgrade sinnvoll. Schnelleres RAM mit niedrigerer Latenz kann darüber hinaus die Leistung in speicherintensiven Anwendungen steigern.

Was Sie 2026 aber unbedingt wissen sollten: Der RAM-Markt hat sich seit Herbst 2025 dramatisch verändert. DDR5-6000-Kits mit 32 Gigabyte, die im Sommer 2025 noch für unter 100 Euro zu haben waren, kosten aktuell teils 400 bis 450 Euro. Ursache ist die stark gestiegene Nachfrage durch KI-Rechenzentren, die einen Großteil der globalen Speicherchip-Produktion beanspruchen.

Laut dem Marktforschungsinstitut TrendForce ist mit nennenswerten Preissenkungen frühestens ab Mitte 2027 zu rechnen. AMD selbst äußerte sich auf der Computex 2026 noch pessimistischer und nannte 2028 als realistischeres Datum. Wer auf AM4 mit DDR4 sitzt und damit zufrieden ist, sollte den Plattformwechsel deshalb gut abwägen. Ein Umstieg auf DDR5 zieht in der Regel auch ein neues Mainboard und eine neue CPU nach sich.

Grafikkarte: Das wirkungsvollste Gaming-Upgrade – mit einer wichtigen Faustregel

Für Gamer ist eine leistungsstarke GPU meistens das Upgrade mit dem größten Effekt: höhere Bildraten, stabilere Frametime-Verläufe, bessere Grafikqualität und die Unterstützung moderner Rendering-Techniken wie Raytracing sowie der KI-gestützten Upscaling-Verfahren DLSS 4 und FSR 4. Letztere sind 2026 keine optionalen Zusatzfeatures mehr, sondern der praktische Weg, in anspruchsvollen Titeln spielbare Frameraten zu erzielen.

Beim Kauf gilt eine Faustregel, die Sie unbedingt beachten sollten: Achten Sie auf ausreichend Grafikspeicher. Wie viel VRAM Sie für Ihren Gaming-PC wirklich benötigen, hängt stark von der Auflösung ab. Einen ausführlichen Überblick dazu finden Sie in unserem VRAM-Ratgeber. Als Orientierung gilt: 8 Gigabyte VRAM geraten bei aktuellen AAA-Titeln zunehmend an ihre Grenzen, 12 Gigabyte sind das sinnvolle Minimum, 16 Gigabyte der entspannte Sweetspot für die nächsten Jahre. Kauftipps für Ihre neue Grafikkarte finden Sie hier: Diese Grafikkarten sind ihr Geld wert.

Vor einer Neuanschaffung sollten Sie außerdem prüfen, ob Ihre CPU stark genug ist, um die neue GPU nicht auszubremsen. Mehr dazu im Folgenden.

Prozessor: Wann sich das teuerste Upgrade wirklich lohnt

Mehr Kerne, eine höhere IPC (Instructions per Cycle; Befehle, die ein Prozessor pro Taktzyklus abarbeitet) und moderne Befehlssätze bringen Vorteile in rechenlastigen Anwendungen, Rendering-Workflows und CPU-lastigen Spielen.

Ob die CPU tatsächlich bremst und ein Upgrade benötigt, zeigt der Task-Manager: Liegt die CPU-Auslastung unter Last dauerhaft nahe 100 Prozent, während die GPU noch Reserven hat, ist das ein deutliches Indiz für einen CPU-Engpass. Welche CPU-GPU-Kombinationen dabei gut harmonieren, erklärt unser Artikel: Die besten Grafikkarten-CPU-Kombinationen für Spieler.

Planen Sie dabei den Gesamtaufwand realistisch ein: Ein CPU-Wechsel zieht häufig auch ein neues Mainboard und passenden Arbeitsspeicher nach sich. Haben Sie keinen nachweisbaren Engpass, stecken Sie das Geld besser in GPU oder SSD. Dort ist der Effekt in den meisten Szenarien deutlich unmittelbarer. Kauftipps für Ihre neue Gaming-CPU finden Sie hier: Der ideale Gaming-Prozessor ab 80 Euro.

Foundry

Kühlung und Netzteil: Oft unterschätzt, aber wirkungsvoll

Die Kühlung gehört zu den Upgrades, die viele unterschätzen. Ein leiser Tower-Kühler oder eine AiO-Wasserkühlung senken nicht nur Temperaturen, sondern ermöglichen es auch, Boost-Taktraten länger zu halten. Das kann messbar mehr Leistung bedeuten.

Zusätzliche Gehäuselüfter optimieren den Airflow, halten die VRMs (Spannungswandler) kühler und verlängern hierdurch die Lebensdauer der Komponenten. Ein effizientes Netzteil mit hoher Spannungsstabilität ist besonders bei High-End-GPUs der aktuellen Generation relevant. Nvidias RTX-50-Karten setzen zudem auf den neuen 12V-2×6-Anschluss – das Netzteil sollte daher ATX 3.1 zertifiziert sein, um Lastspitzen sauber abzufangen und den Energieverbrauch zu senken. Kauftipps für Ihr neues Netzteil finden Sie hier: Die besten PC-Netzteile – unsere Empfehlungen von 650 bis 1650 Watt.

The post Google AI Models Explained: Gemini, Veo, Nano Banana & More appeared first on TechRepublic.

Release Date: July 7, 2026

Same-day patch on top of v0.18.1, picking up the WhatsApp Baileys dependency fix needed for tagged-release Docker builds.

What's in this patch

• fix(whatsapp): unpin Baileys from git commit, use published 7.0.0-rc13 (#60643) — the WhatsApp bridge dependency now installs from the published npm release instead of a pinned git commit, making installs and Docker image builds reliable.

Full curated release notes for the entire post-v0.18.0 window ship with v0.19.0.

Updating

hermes update        # existing installs
pip install -U hermes-agent

Full Changelog: v2026.7.7...v2026.7.7.2

The post Training Gemma-3 for Structured Mathematical Reasoning with Tunix GRPO, LoRA Adapters, and GSM8K Rewards appeared first on MarkTechPost.

I Found an Unauthenticated Attachment Disclosure Bug in a WordPress Support Plugin — and a Duplicate Taught Me What “Fixed” Really Means

Author: Shikhali Jamalzade
GitHub: alisalive · LinkedIn: camalzads

Disclosure Notice: This research was conducted entirely in an isolated, locally-hosted Docker test environment running a fresh install of WordPress and the publicly available “latest-stable” release of the plugin in question, downloaded directly from the official WordPress.org plugin repository. No live, production, or third-party website was accessed, scanned, or tested at any point. All file contents shown are synthetic test data created solely for this research. The affected plugin’s name and the exact route are intentionally redacted here, because the underlying issue is currently being tracked through coordinated disclosure and may not yet be fully patched at the time of writing. This write-up is published strictly for educational purposes.

Background

Most of my CVE research starts from one theory: a plugin whose developers made one authorization mistake will usually have made others, and the categories that leak most often are the ones tied to user-owned objects — tickets, attachments, profiles, orders. Broken Access Control is, by a wide margin, the single most productive class in the WordPress plugin ecosystem, and unauthenticated variants sit at the top of that list.

This time the target was a support-desk / ticketing plugin — the kind of software where customers upload invoices, ID scans, contracts, and screenshots straight into a ticket. If the endpoint that serves those attachments doesn’t check who is asking, the impact isn’t abstract: it’s other people’s private documents.

What follows is a fully independent, fully reproducible finding — and the moment, after submission, when I learned it overlapped with a report already sitting in a vulnerability database’s pipeline. I’m publishing the technical breakdown anyway, because the methodology and the honest reconciliation with prior art are the actual point of doing this in public.

Scope & Method

• Target: A WordPress support/ticketing plugin (redacted), latest-stable from WordPress.org
• Environment: Local, isolated Docker stack — WordPress + MySQL 5.7
• Assessment Type: White-box source audit + black-box PoC validation
• Authorization: Self-authorized, isolated local research environment — no live targets
• Tools: grep, WP-CLI, curl, docker, MySQL CLI

Phase 1: Target Confirmation

Before touching anything, I confirmed exactly what I was auditing: the plugin name, its version, that it was active, and the WordPress version underneath it. This is the first screenshot in every submission I make, because a reviewer needs to know the finding was validated against a real, current install — not a hypothetical.

=== TARGET CONFIRMATION ===
Plugin:    <redacted> (latest-stable)
Version:   <redacted — current release at time of testing>
Active:    YES
WordPress: 7.0
Site URL:  http://<local-docker>:8080

The critical detail here: I was testing the current version. Not an old release with a known history — the newest code the plugin ships today.

Phase 2: Mapping the Attack Surface

The plugin exposes its functionality through a REST namespace. I exported the source via SVN and mapped every route, paying special attention to the permission callbacks — the functions WordPress calls to decide whether a request is allowed before the handler runs.

grep -n "RegisterRestRoute\|permission" <source>/api/v1/<controller>.php

One route stood out immediately — the handler that serves ticket and reply file attachments:

$this->RegisterRestRoute(
    'GET',
    'file-dl/(?P<type>[a-zA-Z0-9-]+)/(?P<id>[0-9_]+)/(?P<file>[^/]+)',
    [$this, "file_dl"]
);

Three attacker-controlled segments — a type selector, a numeric identifier, and a filename — feeding a file-download handler. Exactly the shape of an IDOR, if the permission gate is weak. So I read the gate.

Phase 3: Root Cause

The route’s permission logic resolved, for this particular download route, to a single unconditional line:

} elseif ($route == "file-dl") {
    return true;
}

That’s the whole bug. The permission callback returns true for the attachment-download route unconditionally — no authentication check, no nonce, no verification that the requester owns the ticket the file belongs to. Once that callback returns true, WordPress hands the request straight to the download handler, which reads the identifier and filename from the URL and returns the file.

Because the callback never looks at the current user, there is no notion of “your ticket” versus “someone else’s ticket.” Every attachment is reachable by everyone — including an anonymous visitor with no account at all.

Phase 4: Building an Isolated Test Environment

To prove impact safely, I stood up a throwaway install rather than touching any live site: WordPress + MySQL 5.7 in Docker, the plugin installed from the dashboard, and a realistic victim scenario seeded by hand.

I created two synthetic victim artifacts, standing in for what a real customer would attach:

• A ticket attachment (type = T) containing a fake "confidential customer record."
• A reply attachment (type = R) containing a fake "private invoice."

=== SETUP: victim ticket + reply attachments ===
[ticket attachment created — synthetic "customer record"]
[reply attachment created — synthetic "invoice"]
Files created: 2

I also inserted the matching reply row into the plugin’s database table, because the reply-download path validates that a reply record exists before serving its file. This made the second attack vector reachable exactly as it would be on a real site.

Phase 5: Proof of Concept

Vector 1 — Unauthenticated Ticket Attachment (type = T)

From a session with no cookies, no auth header, no login, I requested the ticket attachment and filtered the output to show that the request carried no credentials and the server returned the file anyway:

> GET /wp-json/<plugin>/v1/ticket/file-dl/T/1/<file> HTTP/1.1
> Host: <local-docker>
< HTTP/1.1 200 OK
[SYNTHETIC CONFIDENTIAL RECORD RETURNED]

No Cookie header. No Authorization header. HTTP 200, and the full attachment content in the response body.

Vector 2 — Unauthenticated Reply Attachment (type = R)

The reply path uses a compound {ticketId}_{replyId} identifier. Same anonymous session, same result:

> GET /wp-json/<plugin>/v1/ticket/file-dl/R/1_1/<file> HTTP/1.1
> Host: <local-docker>
< HTTP/1.1 200 OK
[SYNTHETIC PRIVATE INVOICE RETURNED]

Two independent download paths, both fully unauthenticated.

Integrity Proof

A 200 response proves the endpoint answered — but I wanted to prove the anonymous request returned the actual victim file, byte for byte, not a placeholder or an error page. So I compared the MD5 of the file on disk with the MD5 of what the unauthenticated request pulled down:

--- [A] File on server (victim's attachment) ---
254e7a2a21c6d0d55fbc11fc08e30c18   <server-side file>

--- [B] Content retrieved via unauthenticated request ---
254e7a2a21c6d0d55fbc11fc08e30c18   <downloaded file>

Identical hashes. Byte-for-byte exfiltration, from an anonymous session, confirmed.

Why This Scales

The identifiers are sequential integers. An attacker doesn’t need to guess — they increment. Combined with the fact that support tickets routinely carry personal data, invoices, and contracts, and that the plugin’s upload whitelist covers pdf, doc/docx, xls/xlsx, txt, and common image formats, a single unauthenticated loop over the ID space harvests attachments across every customer on the site.

Estimated severity: CVSS 3.1 7.5 (High) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Network-reachable, no privileges, no interaction, high confidentiality impact.

The Reality Check

Before public disclosure I did what I always do now: I checked the vulnerability databases and I contacted the vendor.

The vendor email went out first — a responsible-disclosure notice with a summary of the issue and a request for a secure contact, deliberately without the full PoC in the first message. Then I submitted the finding to a CNA with the complete technical detail and requested a CVE.

The response was: duplicate.

Not a duplicate of the plugin’s older, public authorization issues — those were a different, integrity-only problem on a different function. This was a duplicate of a separate report already in the CNA’s pipeline, covering exactly this unauthenticated attachment-download route and exactly this “permission callback returns true” root cause, already tracked with the confidentiality impact of returning full attachment contents to anonymous callers.

Someone had gotten there first, by a matter of weeks, into a queue I couldn’t see.

What I Was Told — and What It’s Worth

Here’s the part that turned a rejection into something genuinely useful. The existing record was filed against an earlier version, and marked fixed in a later one. My finding reproduced on the current release — the one that was supposed to be patched.

The reviewer’s response was precise, and I’m quoting the substance of it because it reframed the whole finding for me: my confirmation that the issue still reproduces on the current version, together with the byte-for-byte MD5 proof, would be used to extend the affected-version range on the existing entry beyond the version it was originally filed against. Because it’s the same vulnerability and the same code path, it’s handled under the existing record rather than as a separate CVE.

So: no CVE with my name on it. But my independent reproduction demonstrated that a fix believed to close the issue did not, and that correction lands in the public record where it actually protects people. That’s not nothing. That’s the point of the work.

I want to be precise about what I’m claiming and what I’m not. I did not discover a novel bug here — I independently rediscovered a known one and proved it was still live where it was believed dead. The value isn’t novelty; it’s verification. Those are different contributions, and conflating them would be dishonest.

Attack Chain Summary

[Attacker — no credentials, no prior session]
        │
        ▼
[1] Map REST routes; find attachment-download handler
        │
        ▼
[2] Read permission callback → returns true unconditionally for file-dl
        │
        ▼
[3] Seed victim ticket + reply attachments in isolated Docker install
        │
        ▼
[4] GET file-dl/T/<id>/<file>  → HTTP 200, ticket attachment (no auth)
        │
        ▼
[5] GET file-dl/R/<id>/<file>  → HTTP 200, reply attachment (no auth)
        │
        ▼
[6] MD5(server file) == MD5(downloaded file) → byte-for-byte exfiltration
        │
        ▼
[7] Sequential IDs → enumerate → harvest attachments across all tickets

What This Taught Me

A “fixed in X” label is a claim, not a guarantee. The most valuable thing I did in this entire audit was test the current version instead of assuming the changelog was true. The issue was marked fixed; it wasn’t. Independent reproduction against the latest release is how that gets caught.

Duplicate-by-pipeline is invisible until it isn’t. I checked every public database before submitting, and it was clean — because the report that duplicated mine wasn’t public yet. You cannot fully de-risk this. What you can do is target less-crowded plugins: the more popular the software, the more researchers are already circling it. Two of my findings that week collided with pipeline reports; both were popular plugins. The niche ones didn’t collide.

Precision about your own contribution is a security skill. “I found a new bug,” “I independently rediscovered a known bug,” and “I proved a known bug wasn’t actually fixed” are three different sentences with three different truth values. Picking the correct one — especially when the flattering one is right there — is part of doing this honestly.

The process transfers regardless of the outcome. Standing up an isolated environment, tracing an unauthenticated entry point to confirmed impact, building two independent PoCs, proving exfiltration with a hash rather than a screenshot alone — that skill set is identical whether the audit ends in a CVE or a “thanks, we’ll extend the range.”

If you found this useful, feel free to connect on LinkedIn or check out my tools on GitHub.

All testing was conducted in an isolated, locally-hosted environment using a publicly available plugin release. No live or third-party systems were accessed at any point during this research. The plugin name and exact route are redacted pending completion of coordinated disclosure.

I Found an Unauthenticated Attachment Disclosure Bug in a WordPress Support Plugin — and a… was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Valve hat die Beta-Version von SteamOS 3.8.20 veröffentlicht, die neben einem deutlich verbesserten VRAM-Management ein Update für den Mesa-Grafiktreiber mitbringt. Zusätzlich enthält das neue Beta-Update auch Fehlerbehebungen aus SteamOS 3.8.12.

Dieser Beitrag KI-Controlling, lokale Modelle und neue Benchmarks: Was sich gerade ändert erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

The post Interfaze Ships diffusion-gemma-asr-small, an Open-Source Diffusion ASR Model Transcribing Six Languages via DiffusionGemma’s Parallel Denoising Decoder appeared first on MarkTechPost.

In der 176. Episode des ComputerBase-Podcasts CB-Funk besprechen Jan und Fabian den Gaming-Test der Arc Pro B70 mit 32 GB VRAM, bald wahrscheinlich teurer werdende Radeon-Grafikkarten, eine zu teure alte GeForce-Grafikkarte und die Vorbereitungen zum Community-Benchmark zu Assassin's Creed Black Flag Resynced.

How DotScramble protects its Pro tier using Ed25519 cryptography — without phoning home on every launch

A technical deep-dive into license system design for desktop applications — threat modelling, Ed25519 token verification, weighted hardware fingerprinting, and background revocation detection.

The Problem With Most Desktop License Systems

Most desktop software license systems fall into one of two failure modes.

The naive implementation: a hardcoded or obfuscated license key string that the app compares against. Crack once, share forever. A single keygen posted to any forum defeats it permanently.

The over-engineered implementation: online-only validation that calls home on every launch. Legitimate users can’t use the software on a plane, at a conference, or when the license server has a bad day. The result is user experience indistinguishable from DRM — with all the goodwill cost that implies.

DotScramble needed something in between: cryptographically sound, functional offline for days at a time, with server-enforced revocation when internet is available. This post covers how that system works.

The Threat Model

Before any implementation decisions, a clear adversary model:

Attack vectorRealistic?DefenceCopy .py source to another machineTrivialMachine fingerprinting + Cython binaryShare one API key across N machinesLikelyServer-side activation limit (max 2)Patch is_max_activated = True in sourceOne lineCython .so compilationForge a license token offlineRequires Ed25519 private keyAsymmetric signing — public key only in clientUse indefinitely without networkEasy7-day token TTL + background recheckRoll back system clock to extend tokenCleverMonotonic timestamp stored in SQLiteRevoked key continues workingSilentBackground 24h server recheck

The objective was not unbreakable DRM — that doesn’t exist for software running on user-controlled hardware. The objective was to make casual circumvention more expensive than purchasing a license, while making legitimate use completely frictionless.

Why Ed25519

The classical alternative is HMAC-SHA256 with a shared secret. The fundamental problem: if the client holds a shared secret, it can forge. You can obfuscate the secret, compile it into a binary, XOR it with a magic constant — but it’s still in there, and extraction is a solved problem.

Ed25519 eliminates the forgery surface entirely:

Private key  →  lives only on the license server  →  signs tokens
Public key   →  hardcoded in the client binary    →  verifies tokens, cannot forge

The mathematics of elliptic curve cryptography guarantee that knowledge of the public key reveals nothing useful about the private key. An attacker who fully reverses the client binary, extracts the public key, and understands the entire verification flow still cannot produce a valid signature. The only path to a forged token is compromising the server.

The public key in license_manager.py is 32 bytes:

_ED25519_PUBLIC_KEY_B64 = "DQ0zJAi1S0c+NUhOP3050au9k5/fYwLU45ayTZIFVuI="

This is the entire cryptographic boundary between the client and unlimited offline activation.

Token Structure

Every activated machine receives a signed license token — a compact, self-contained credential the app can verify locally without any network call.

Format: two Base64URL strings joined by .

<base64url(JSON payload)>.<base64url(Ed25519 signature)>

Payload structure:

{
  "mid": "a3f1b2c9d4e5f6a7b8c9d0e1f2a3b4c5",
  "name": "FreeRave",
  "plan": "max",
  "exp": 1782000000
}

• mid — the machine fingerprint (32 hex chars, SHA-256 of hardware identifiers)
• name — displayed to the user on activation
• plan — tier identifier ("max" = Pro)
• exp — Unix timestamp expiry; server controls token lifetime

The server signs the raw JSON bytes with its Ed25519 private key. The client verifies using the hardcoded public key, then checks expiry and machine binding. All three must pass.

The Verification Function

def _verify_token(self, token: str) -> Tuple[bool, dict]:
    try:
        from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

parts = token.split(".")
        if len(parts) != 2:
            return False, {}
        payload_b64, sig_b64 = parts
        # Dynamic Base64 padding - JWT/URL-safe Base64 strips trailing '='
        # The expression (-len(s) % 4) gives: 0 if already padded, else 1-3
        def _b64dec(s: str) -> bytes:
            return base64.urlsafe_b64decode(s + '=' * (-len(s) % 4))
        payload_bytes = _b64dec(payload_b64)
        sig_bytes     = _b64dec(sig_b64)
        pub_raw    = base64.b64decode(_ED25519_PUBLIC_KEY_B64)
        public_key = Ed25519PublicKey.from_public_bytes(pub_raw)
        public_key.verify(sig_bytes, payload_bytes)  # raises InvalidSignature on tamper
        payload = json.loads(payload_bytes.decode())
        # Gate 1: expiry
        if payload.get("exp", 0) < time.time():
            return False, {}
        # Gate 2: machine binding
        if payload.get("mid", "") != self.generate_machine_id():
            return False, {}
        return True, payload
    except Exception:
        return False, {}

Three gates in sequence. Fail any one, the token is rejected and local activation is cleared. The except Exception: return False, {} catch-all is intentional — any unexpected error (missing field, malformed base64, truncated token) is treated as a verification failure, not as a crash.

On the padding trick: URL-safe Base64 used in JWTs often strips trailing = padding. (-len(s) % 4) is a modular arithmetic shorthand that adds exactly the right number: if len(s) % 4 == 0, adds 0; otherwise adds 4 - (len(s) % 4). This avoids an if/else chain and handles all cases correctly.

Machine Fingerprinting

The machine ID is a 32-character hex string that must be stable across reboots, unique enough to distinguish machines, and cross-platform. The approach is a weighted combination of hardware identifiers, hashed to a fixed-length output:

@staticmethod
def generate_machine_id() -> str:
    factors: dict[str, str] = {}

# Platform-specific hardware ID - primary anchor
    try:
        if platform.system() == "Linux":
            # /etc/machine-id: written once at OS install by systemd
            # Survives: reboots, kernel updates, VPN, hostname changes
            # Does not survive: full OS reinstall
            with open("/etc/machine-id") as f:
                factors["mid"] = f.read().strip()
        elif platform.system() == "Windows":
            import winreg
            key = winreg.OpenKey(
                winreg.HKEY_LOCAL_MACHINE,
                r"SOFTWARE\Microsoft\Cryptography"
            )
            # MachineGuid: equivalent to /etc/machine-id on Windows
            factors["mid"] = winreg.QueryValueEx(key, "MachineGuid")[0]
        elif platform.system() == "Darwin":
            import subprocess
            out = subprocess.check_output(
                ["ioreg", "-rd1", "-c", "IOPlatformExpertDevice"],
                stderr=subprocess.DEVNULL
            )
            for line in out.decode().splitlines():
                if "IOPlatformUUID" in line:
                    factors["mid"] = line.split('"')[-2]
                    break
    except:
        pass
    # Secondary factors - supplement if primary unavailable (e.g., container)
    try:
        factors["cpu"] = str(os.cpu_count() or 0)
    except:
        pass
    factors["os"] = platform.system()
    # MAC address - only if real hardware, not randomized
    try:
        mac_int = _uuid.getnode()
        # Bit 40 (the "locally administered" bit) is 1 for randomized MACs
        # Randomized MACs change on every boot - useless as a stable anchor
        if not (mac_int >> 40) & 1:
            factors["mac"] = hex(mac_int)[2:].upper().zfill(12)
    except:
        pass
    # Sort for determinism regardless of which factors are available
    factor_str = "|".join(f"{k}:{v}" for k, v in sorted(factors.items()))
    return hashlib.sha256(factor_str.encode()).hexdigest()[:32]

Why sorted(factors.items())? Dict insertion order in Python 3.7+ is deterministic, but only if the same keys are always inserted in the same order. If, for example, the MAC address is unavailable on one run (kernel randomization), the dict has fewer keys and the order changes. Sorting by key ensures the concatenated string — and therefore the hash — is identical regardless of which optional factors are present.

The MAC randomization filter: Modern Linux privacy kernels and NetworkManager configurations use MAC address randomization. Bit 40 of the MAC integer is the “locally administered” bit — set to 1 for locally generated (randomized) addresses. Including a randomized MAC in the fingerprint would cause activation to break after every reboot. The bitmask check (mac_int >> 40) & 1 filters these out.

Container environments: In Docker or LXC, /etc/machine-id may not exist. The try/except blocks ensure graceful degradation — if the primary identifier is missing, the fingerprint falls back to CPU count + OS string + MAC (if available). This is a weaker fingerprint but still functional.

The Activation Flow

User clicks "Activate Pro"
        │
        ▼
LocalAuthManager.start()
  → Binds to 127.0.0.1:0 (port 0 = OS assigns ephemeral port atomically)
  → Generates 32-byte CSRF state token via secrets.token_urlsafe(32)
        │
        ▼
webbrowser.open(
  "https://dotsuite.vercel.app/en/dashboard/dotscramble/auth?port=PORT&state=STATE"
)
        │
        ▼
User authenticates in browser, clicks "Activate"
        │
        ▼
Dashboard: POST http://127.0.0.1:PORT/callback
  Body: { "key": "<api_key>", "state": "<state_token>" }
        │
        ▼
AuthHandler.do_POST()
  → Content-Length check: reject if > 4096 or ≤ 0  (OOM DoS prevention)
  → secrets.compare_digest(received_state, expected_state)  (CSRF check)
  → on_key_received(api_key) called
        │
        ▼
LicenseManager.verify_and_activate(api_key)
  → POST https://dotsuite-core-production.up.railway.app/v1/license/activate
     Authorization: Bearer <api_key>
     Body: { "machine_id": "a3f1b2..." }
        │
        ▼
Server validates key, checks activation count (≤ 2 machines), signs token
Returns: { "license_token": "<payload>.<sig>", "name": "FreeRave" }
        │
        ▼
Client: _verify_token(token)
  → Signature valid (Ed25519)
  → Not expired (exp > time.time())
  → Machine matches (mid == generate_machine_id())
        │
        ▼
Token + API key saved to SQLite
Background recheck thread started (24h cycle)

The Local HTTP Server as a Security Boundary

The browser-to-desktop callback is not a direct function call — it goes through a local HTTP server. This is not over-engineering. The HTTP boundary enforces:

1. CSRF protection: The state token is generated fresh on each activation attempt and compared using secrets.compare_digest() (constant-time, timing-attack resistant). Any page other than the DotSuite dashboard that tries to POST to the local server will fail state verification.
2. Payload size cap: The server rejects any POST body over 4096 bytes with HTTP 413. An API key is at most a few hundred bytes — there’s no legitimate reason for a larger payload.
3. Port 0 binding: Binding to port 0 lets the OS assign an available ephemeral port atomically. The alternative — picking a fixed port and checking if it’s free — is a TOCTOU race condition. Port 0 eliminates the race.

# Constant-time comparison — prevents timing oracle on state token
def verify_state(self, state):
    if not state or not self.state_token:
        return False
    return secrets.compare_digest(state, self.state_token)

secrets.compare_digest() matters here because the comparison happens over localhost HTTP. A timing oracle on a 32-character token over loopback is a marginal attack in practice, but it costs nothing to use the correct primitive.

Offline Grace and Startup Verification

After activation, the token is cached in SQLite. Every subsequent startup re-verifies locally — no network call required:

def __init__(self, db_manager):
    # ...
    if self._license_token:
        last_verified = float(
            self.db_manager.get_setting("last_license_check_time", 0.0)
        )
        current_time = time.time()

# Clock rollback detection
        # If current_time < last_verified, the clock was moved backward
        # This could be used to prevent token expiry - reject it
        if current_time < last_verified:
            self.logger.error("System clock rollback detected on startup!")
            self._clear_local()
        else:
            valid, _ = self._verify_token(self._license_token)
            if valid:
                self._is_max = True
                self.db_manager.save_setting(
                    "last_license_check_time", current_time, "license"
                )
                self._schedule_background_recheck()
            else:
                self._clear_local()

Clock rollback attack: If a user manually sets their system clock backward, time.time() returns a value earlier than the stored last_license_check_time. The check current_time < last_verified detects this and immediately deactivates. The stored timestamp acts as a ratchet — it can only move forward.

The 7-day grace period is implicit in the token’s exp field. The server sets expiry 7 days from activation (or last successful recheck). An offline machine can use the software freely for 7 days before the token expires and the local check fails.

Background Revocation Detection

Local verification is fast and works offline, but it cannot detect revoked keys. A key that was refunded, chargebacked, or administratively revoked would continue to pass local Ed25519 verification until its token expires.

The background recheck thread addresses this:

def _schedule_background_recheck(self):
    self.stop_recheck_event.clear()
    t = threading.Thread(
        target=self._recheck_loop,
        daemon=True,           # dies with the main process
        name="license-recheck"
    )
    t.start()

def _recheck_loop(self):
    while not self.stop_recheck_event.is_set():
        # Event.wait(timeout) instead of time.sleep():
        # wakes immediately on stop_recheck_event.set(), enabling clean shutdown
        is_stopped = self.stop_recheck_event.wait(_RECHECK_HOURS * 3600)
        if is_stopped or self.stop_recheck_event.is_set():
            break
        self._silent_recheck()

The recheck itself is silent — no UI notification, no interruption:

def _silent_recheck(self):
    with self.lock:
        if not self._is_max:
            return
        current_key = self._api_key
    try:
        machine_id    = self.generate_machine_id()
        payload_bytes = json.dumps({"machine_id": machine_id}).encode()
        req = urllib.request.Request(
            _RECHECK_URL, data=payload_bytes,
            headers={
                "Authorization": f"Bearer {current_key}",
                "Content-Type": "application/json"
            }
        )
        with urllib.request.urlopen(req, timeout=10) as resp:
            data      = json.loads(resp.read().decode())
            new_token = data.get("license_token", "")

valid, _ = self._verify_token(new_token)
        if valid:
            with self.lock:
                self._license_token = new_token
            self.db_manager.save_setting("license_token", new_token, "license")
            self.db_manager.save_setting(
                "last_license_check_time", time.time(), "license"
            )
        else:
            self._clear_local()   # Server returned invalid token - deactivate
    except urllib.error.HTTPError as e:
        if e.code in (401, 403, 404):
            self._clear_local()   # Explicit server rejection - deactivate immediately
        # 5xx, connection timeout: server down or network unavailable
        # Do NOT deactivate - user gets full 7-day grace period
    except Exception:
        pass   # Any other error: fail open, try again next cycle

The error handling is the most important part of this function. Three distinct outcomes:

HTTP 401/403/404 — the server explicitly rejected the request. The API key is invalid, revoked, or deleted. Deactivate immediately, clear all local credentials.

HTTP 5xx / connection error / timeout — the server is temporarily unavailable. Do nothing. The local token is still valid (Ed25519 + expiry check passed on startup). The user retains full access for the remainder of the token’s TTL. This is the correct behaviour: a server outage should never disrupt legitimate users.

Valid fresh token returned — refresh the cache. The new token extends the TTL another 7 days, so an online user’s activation effectively never expires.

The Feature Gate

Every Pro-only code path in the UI calls one property:

@property
def is_max_activated(self) -> bool:
    # In-memory boolean — no I/O, no crypto
    with self.lock:
        return self._is_max

This is intentionally the simplest possible check. The reasoning is performance: is_max_activated is evaluated on every frame of the real-time preview slider. Token verification using Ed25519 takes 0.5–2ms per call. At 60fps, continuous verification would consume up to 120ms/second on crypto alone — enough to cause visible frame drops.

The expensive verification happens once on startup and once per 24-hour background cycle. The in-memory boolean is the hot path, protected by a standard mutex for thread safety (the background recheck thread writes to _is_max from a different thread).

Feature gating at detection mode selection:

def on_detection_change(self):
    mode = self.detection_mode.get()
    pro_only_modes = ['target_text', 'text', 'body', 'license_plate']

if mode in pro_only_modes and not self.license_manager.is_max_activated:
        QMessageBox.information(
            self, "Pro Feature",
            f"'{mode.replace('_', ' ').title()}' detection requires DotScramble Pro."
        )
        self.detection_mode.set("face")  # Reset to free tier default

Feature gating at save time:

is_max       = self.license_manager.is_max_activated
should_scrub = is_max and self.scrub_exif.get()
should_spoof = is_max and self.spoof_metadata.get() and not should_scrub

Metadata operations (EXIF spoofing, scrubbing) are Pro-only features. The gate is evaluated at save time, not at button click — preventing race conditions where the UI state and license state could diverge.

Source Protection via Cython

Python source is trivially patchable. Given _is_max:

# Original
return self._is_max

# Patched in 3 seconds
return True

Mitigation: compile license_manager.py to a native shared library using Cython. The build script:

from setuptools import setup, Extension
from Cython.Build import cythonize

extensions = [
    Extension(
        "src.managers.license_manager",
        sources=["src/managers/license_manager.py"],
        extra_compile_args=["-O2"],
    )
]
setup(
    name="dotscramble_license",
    ext_modules=cythonize(
        extensions,
        compiler_directives={
            "embedsignature":      False,  # Strip readable function signatures
            "emit_code_comments":  False,  # No source hints in binary
            "language_level":      "3",
            "boundscheck":         False,
            "wraparound":          True,
        },
    ),
)

Build:

python setup_license.py build_ext --inplace
# → src/managers/license_manager.cpython-313-x86_64-linux-gnu.so

The original .py is removed from the distribution. Python's import system finds the .so automatically — no import path changes required.

The compiled binary is a real ELF shared library. Patching it requires disassembling x86_64 machine code, locating the boolean return instruction in the JIT-compiled method, and modifying it in a hex editor or with a binary patcher. This is not impossible, but the skill floor is substantially higher than editing a Python file. Combined with the Ed25519 enforcement — which cannot be bypassed by patching the client — the effort/reward ratio for cracking exceeds the cost of a legitimate license for most users.

Platform note: Cython produces platform-specific binaries. cpython-313-x86_64-linux-gnu.so runs only on Linux x86_64 with CPython 3.13. Cross-platform distribution requires separate build steps on Linux, Windows, and macOS — standard practice for any CI pipeline with multi-platform targets.

Known Limitations and Attack Surfaces

The public key is in the binary. This is by design — the public key is meant to be public. It cannot be used to forge tokens. An attacker who extracts it gains nothing.

Container and VM bypass. In environments where /etc/machine-id can be freely set (Docker, LXC, VMs with snapshot/rollback), the machine fingerprint can be cloned. Mitigation: the server-side 2-machine activation limit constrains this — each cloned ID counts as a new activation.

Binary patching still possible. Cython raises the bar but doesn’t eliminate it. A sufficiently motivated attacker with a disassembler can still find and patch the boolean return in the .so. The actual security comes from Ed25519 — even a patched client that claims is_max = True can't forge a valid token, so server-enforced features (recheck, machine limit) remain intact.

Clock rollback detection has a window. The check compares time.time() against a stored SQLite timestamp. An attacker who modifies the SQLite database before running the app could plant a fake last_license_check_time far in the future, then roll the clock back while keeping time.time() > stored_time. Mitigation: the SQLite database is in the user's home directory and not encrypted — for high-value deployments, a tamper-evident store (e.g. macOS Keychain, Linux Secret Service) would be more appropriate.

No mutual TLS. The /v1/license/activate and /v1/license/recheck calls use standard HTTPS. The server's certificate is verified by the system CA store. A machine with a compromised CA store (corporate MITM proxy, malware-installed root) could intercept and modify these responses. This is a general HTTPS limitation, not specific to this design.

Design Decisions — What Was Intentionally Excluded

Online-only enforcement. Requiring a network check on every launch would break offline use. Planes, hotel Wi-Fi captive portals, corporate proxies, server downtime — all of these would result in failed launches for paying customers. The 7-day grace period with background recheck is the correct trade-off.

Aggressive telemetry. The only data sent to the server is the machine ID and API key. No usage statistics, no feature telemetry, no file names, no behavioral data. DotScramble is a privacy tool. Telemetry would be self-contradicting.

Obfuscating the public key. Pointless security theatre. The public key is designed to be known. Wrapping it in XOR or base64-of-base64 adds no security and significant code smell.

Binding to MAC address only. MAC addresses are trivially spoofed on Linux (ip link set dev eth0 address XX:XX:XX:XX:XX:XX) and may be randomized by default. Using /etc/machine-id as the primary anchor is more stable and harder to spoof without root access.

Summary

DotScramble’s license system implements a minimal but sound cryptographic design:

• Ed25519 asymmetric signing ensures tokens cannot be forged without the server’s private key, regardless of how thoroughly the client binary is reversed.
• Weighted machine fingerprinting using OS-level hardware identifiers provides stable, cross-platform machine binding that survives network changes and VPN usage.
• SQLite-cached token with startup re-verification enables offline use without any network dependency on launch.
• 7-day TTL with 24-hour background recheck gives legitimate offline users a comfortable grace window while ensuring revoked keys are detected within a day of the machine coming online.
• Cython compilation raises the practical bar against source patching, complementing but not replacing the cryptographic enforcement.

The design is appropriate for a solo-developed privacy tool. It is not appropriate for enterprise software protecting high-value IP — that use case warrants hardware dongles, TPM attestation, or a full code-signing/attestation pipeline.

GitHub: github.com/kareem2099/DotScramble
OpenDesktop: opendesktop.org/p/2362477
License: Apache 2.0

Asymmetric Signing, Machine Fingerprinting, and Offline Grace Periods: Building a License System… was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

ComputerBase hat die Arc Pro B70 mit 32 GB VRAM im Test. Auch wenn es sich primär um eine Profi-Grafikkarte handelt, konzentriert sich die Redaktion auf Gaming-Benchmarks. Der Test zeigt damit, wie schnell eine Arc B770 im Vergleich zu GeForce RTX 5060 Ti und Radeon RX 9060 XT mindestens gewesen wäre.

Radeon-Grafikkarten könnten im Laufe des Jahres abermals teurer werden, wie jetzt wiederholt Gerüchte aus Asien darlegen. Demnach plane AMD ab Juli mit höheren Preisen für die Bundles aus GPU-Chips und VRAM-Bausteinen, aus denen Boardpartner die fertigen Grafikkarten herstellen. Auswirkungen auf den Endhandel sind noch offen.

The post Stop Choosing Between Local and Cloud LLMs: A Field Guide to Hybrid Patterns appeared first on Towards Data Science.

Read the full article on GamingOnLinux.

Over the weekend, the firm released DSpark, a new, MIT-Licensed system designed to make large language models answer faster without changing what the underlying model is trying to say.

The easiest way to think about it is this: most AI chatbots write like someone crossing a river one stepping stone at a time. They choose one small chunk of text, then the next, then the next.

DSpark gives the system a scout that runs a few steps ahead, guesses the likely path, and lets the larger model quickly check which steps are safe. When the guesses are good, the model moves faster. When the guesses are weak, DSpark tries not to waste time checking them.

DeepSeek published the work with a technical paper, model checkpoints and DeepSpec, a codebase for training and evaluating speculative decoding systems. The release is available through DeepSeek’s public GitHub and Hugging Face pages, both under the permissive, friendly, commonplace MIT license, making the new technique broadly usable by developers, researchers and commercial enterprise operations that want to study or adapt the approach.

The system is aimed at one of the most expensive problems in AI deployment: serving large models quickly enough for real users, while using hardware efficiently enough to make the economics work. That matters for consumer chatbots, coding assistants, agentic workflows and enterprise AI systems where users expect long answers to stream quickly rather than crawl out word by word.

DeepSeek is applying DSpark to its own latest frontier open model, DeepSeek-V4.

Specifically, DeepSeek used its new DSpark framework on DeepSeek-V4-Flash, its already speed-optimized 284-billion-parameter mixture-of-experts model with 13 billion active parameters, and DeepSeek-V4-Pro, its more thoughtful and powerful 1.6-trillion-parameter model with 49 billion active parameters (Both support context windows up to one million tokens).

But the broader significance is that DSpark is not conceptually limited to DeepSeek-V4. DeepSeek’s own tests and released checkpoints cover other open model families, including Alibaba's open weights Qwen and Google's open weights Gemma.

That means enterprise teams running open-weight models could, in principle, train or fine-tune DSpark-style draft modules for their own target models. It is not a switch that any API customer can flip from the outside, but it is a method that can travel to other models when the operator controls the weights and serving stack.

Staggering speed increases for generating tokens during inference

In DeepSeek’s live production tests, DSpark improved aggregate throughput by 51% for DeepSeek-V4-Flash at an 80-token-per-second-per-user service target, and by 52% for DeepSeek-V4-Pro at a 35-token-per-second-per-user target. At matched system capacity, DeepSeek reports per-user generation speedups of 60% to 85% for V4-Flash and 57% to 78% for V4-Pro over its prior MTP-1 production baseline.

The different speed claims measure different things. The 60% to 85% figure for V4-Flash, and the 57% to 78% figure for V4-Pro, describe how much faster individual users receive generated tokens when DeepSeek compares DSpark with MTP-1 at matched practical system capacity.

Those are the cleaner “generation speed” numbers. DeepSeek also reports much larger 661% and 406% increases, but these measure aggregate throughput under very strict speed targets: 120 tokens per second per user for V4-Flash and 50 tokens per second per user for V4-Pro.

At those targets, DeepSeek says its older MTP-1 baseline approaches an operational cliff, meaning it can keep only a small number of concurrent requests running while preserving that level of responsiveness.

DSpark avoids more of that collapse, so the percentage difference in total system output becomes much larger. Put simply: the 85% number is closer to “how much faster the ride feels for a user” under comparable conditions, while the 661% and 406% figures are closer to “how much more traffic the road can still carry” when the old system is already bottlenecking.

Why speculative decoding matters

LLMs usually generate text one token at a time. A token can be a word, part of a word, punctuation mark or other small piece of text. Every new token depends on the text already produced, so the model has to keep pausing, checking the full context and choosing the next piece.

That is accurate, but slow. It is like having a senior editor approve every word before a writer can move to the next one. The editor may be excellent, but the process creates a bottleneck.

Speculative decoding, developed in the early Transfomer era, tries to fix that bottleneck. Instead of asking the large model to produce every token one by one, the system uses a smaller or lighter draft component to suggest several likely next tokens. The large model then checks that batch of guesses in parallel. If the draft guessed correctly, the system moves ahead several tokens at once. If the draft made a bad guess, the system rejects the bad token and anything after it, adds a corrected token, and tries again.

The point is speed without changing the larger model’s intended output. In the standard speculative decoding setup, the draft model is not replacing the target model. It is acting more like an assistant who prepares a rough next sentence for the senior editor to approve or reject.

The idea did not appear out of nowhere with today’s large language models. A key precursor came in 2018, when Mitchell Stern, Noam Shazeer and Jakob Uszkoreit proposed blockwise parallel decoding for deep autoregressive models. Their method predicted multiple future steps in parallel, then kept the longest prefix validated by the main model. That paper established much of the draft-and-check intuition behind later speculative decoding work.

The research line became more explicit in 2022. Heming Xia, Tao Ge and co-authors introduced SpecDec, a draft-and-verify approach for sequence-to-sequence generation. Later that year, Yaniv Leviathan, Matan Kalman and Yossi Matias posted “Fast Inference from Transformers via Speculative Decoding,” which helped define the modern version of the technique for transformer-based language models. DeepMind researchers followed in 2023 with a closely related method called speculative sampling.

Those 2022 and 2023 papers are the clearest ancestors of how speculative decoding is discussed in current LLM inference work: a faster draft process proposes tokens, and the larger target model verifies them in a way designed to preserve the target model’s output distribution.

Since then, the field has moved quickly through several variants, including separate draft models, multi-token prediction heads, tree-based verification, feature-level methods such as EAGLE, self-speculation, Medusa-style extra heads and parallel/blockwise drafters such as DFlash.

The key metric is not how many tokens a draft model can guess. It is how many of those guesses the larger model actually accepts. Long speculative blocks help only if enough of the proposed tokens survive verification. Otherwise, the system spends compute checking guesses that it throws away.

That is the context for DSpark. Speculative decoding is already an established inference technique before DeepSeek’s release, with support in major serving stacks and multiple competing research approaches. But it is still not a solved problem. Speedups depend heavily on the draft model, the workload, the serving setup and the current traffic level. DSpark’s contribution is to improve both sides of the trade-off: it tries to draft more coherent token blocks and then verify only the parts of those blocks that are likely to pay off under real serving conditions.

What DSpark changes

DSpark tackles two related problems: bad guesses and wasted checking.

First, the system uses what DeepSeek calls semi-autoregressive generation. In plain English, that means DSpark tries to combine speed with a bit more awareness of sequence.

A fully parallel drafter can guess several tokens at once, which is fast, but its later guesses can become less coherent because each position is predicted too independently. A purely step-by-step drafter can keep better track of how one token leads to the next, but it loses much of the speed advantage.

DSpark tries to keep the best of both. It uses a parallel backbone for most of the drafting work, then adds a lightweight sequential head that lets the draft take nearby token relationships into account. In the paper’s example, a parallel drafter might confuse likely phrase endings such as “of course” and “no problem,” producing awkward combinations because it is guessing positions too separately. DSpark’s sequential component helps the system make the later tokens fit the earlier ones.

Second, DSpark adds confidence-scheduled verification. Rather than always asking the target model to check the same number of draft tokens, DSpark estimates which prefix of the draft is likely to survive. A hardware-aware scheduler then adjusts how much of each draft should be verified based on both model confidence and current serving load.

A simple analogy: when a restaurant is quiet, the head chef can inspect more of the prep cook’s work. When the kitchen is slammed, the chef spends attention only on the dishes most likely to be ready. DSpark applies a similar idea to AI serving. Under lighter traffic, the system can afford to check longer draft prefixes. Under heavier traffic, it trims low-confidence trailing guesses before they consume batch capacity that could be used for other users.

DeepSeek frames this as an answer to a common production trade-off. Static multi-token drafting can look attractive in isolation, but can hurt throughput under high concurrency because the system keeps checking tokens that are likely to be rejected. DSpark’s scheduler makes the verification budget flexible instead of fixed.

Offline results: better draft acceptance across Qwen and Gemma

DeepSeek tested DSpark offline on Qwen3-4B, Qwen3-8B, Qwen3-14B and Gemma4-12B target models across math, coding and chat benchmarks.

In those tests, the team compared DSpark with DFlash, a parallel drafter, and Eagle3, an autoregressive drafter. The paper reports accepted length per decoding round, a measure of how many tokens survive verification on average.

Across the three Qwen3 model sizes, DSpark improved macro-average accepted length over Eagle3 by 30.9%, 26.7% and 30.0%, respectively. Compared with DFlash, it improved accepted length by 16.3%, 18.4% and 18.3%. The paper also says the gains generalized to Gemma4-12B.

That supports a point raised by developer Daniel Han, who highlighted on X that DeepSeek showed DSpark working beyond DeepSeek’s own V4 models, including Gemma and Qwen. I would include Han as community reaction, not as the sole evidence for the claim. The stronger support comes from DeepSeek’s own benchmarks and released checkpoints.

The offline results also show why workload matters. Structured tasks such as math and code tend to have higher accepted lengths than open-ended chat. That makes intuitive sense: a code completion or math step often has fewer reasonable next moves than a free-form conversation.

For enterprises, this means DSpark-style methods may be especially attractive for coding assistants, data analysis agents, structured workflow automation and other settings where outputs follow more predictable patterns.

How enterprises could use DSpark without DeepSeek-V4

One of the most important questions is whether DSpark is a DeepSeek-only optimization or a broader method that can be applied to other models. The answer is: broader method, but not automatic plug-in.

For open-weight models, the path is relatively clear. An enterprise running Qwen, Gemma, Llama, Mistral, Granite, Command-style open weights or another model it hosts itself could train or fine-tune a DSpark-style draft module against that target model.

The team would then measure acceptance on its own workloads and integrate the verification scheduler into its inference stack.

That is different from simply downloading DeepSeek’s DSpark module and attaching it to any model. Speculative decoding depends on alignment between the draft module and the target model. The draft has to learn what the target model is likely to accept. A drafter trained for DeepSeek-V4 will not automatically be the right drafter for a different model, especially one fine-tuned on a company’s internal data or configured for different reasoning behavior.

DeepSpec’s workflow reflects this. The process involves preparing data, regenerating target-model answers, building a target cache, training the draft model and evaluating speculative-decoding acceptance. For domain-specific use, the draft model may need additional fine-tuning, especially if the target model runs in a thinking or reasoning mode.

For proprietary models, the answer depends on what the enterprise controls. If a company owns or fully hosts the model weights and serving stack, it could theoretically train and deploy a DSpark-style drafter. If the model is available only through a hosted API from a vendor, the customer cannot directly add DSpark from the outside. The API provider could implement a similar optimization internally, but the customer generally cannot access the token verification loop, logits, batching behavior or serving scheduler needed to make DSpark work.

That distinction matters for enterprise buyers. DSpark strengthens the case for open or self-hosted AI infrastructure because it gives advanced teams another lever to improve speed and cost. But it also shows why model serving is becoming a specialized discipline. The value is not just in picking a model, but in how intelligently that model is run.

What developers get from DeepSpec

For developers, DeepSpec gives a concrete implementation path for training and evaluating speculative decoding draft models. It includes data preparation, training and benchmark evaluation steps, along with released checkpoints for several open model families. That makes the release useful not only for running DeepSeek-V4 with DSpark, but also for researchers and infrastructure teams studying how to add faster decoding to other open models.

There are real deployment caveats. DeepSpec’s own README says the default Qwen3-4B data preparation setup can require roughly 38 TB of target cache storage, and the default scripts assume a single node with eight GPUs. That makes the release more immediately relevant to AI labs, cloud teams and sophisticated enterprise AI infrastructure groups than to ordinary application developers.

Still, releasing the training pipeline matters. Many inference optimizations appear only as papers, vague benchmarks or closed production claims. DeepSpec gives developers something closer to a set of blueprints: not a finished enterprise product, but a way to reproduce, adapt and evaluate the method.

Early community testing

The release has already drawn fast developer attention. Developer Rafael Caricio published a GitHub pull request documenting single-stream DeepSeek-V4-Flash DSpark work, reporting warmed benchmark anchors of 26.33 tokens per second without speculative decoding, 39.88 tokens per second with MTP-1, and roughly 60 tokens per second with DSpark — about 1.5x over MTP-1 and 2.3x over no-spec decoding.

A later commit in the same thread recorded a five-run mean of 60.31 tokens per second, with a 1.51x gain over MTP-1 and 2.29x over non-speculative decoding.

The same work also points to an important practical limit: in realistic multi-turn coding sessions, performance can degrade as draft acceptance falls with growing context. In other words, DSpark can make decoding faster, but acceptance quality still determines how much speed the system actually realizes.

That is a useful reality check. DSpark is not magic. It still depends on how predictable the next tokens are and how well the drafter stays aligned with the target model. But the early implementation work suggests DeepSeek’s claims are not purely academic. Developers are already testing the method in practical serving environments and reporting gains close to the paper’s single-stream expectations.

The bottom line

DSpark shows how much performance remains available in the inference layer, even when the underlying model architecture stays the same. As AI companies compete on model quality, context length and pricing, decoding efficiency is becoming another major battleground.

Faster generation means lower latency for users, higher throughput for providers and better economics for teams serving open models at scale.

DeepSeek’s release is notable because it combines a production-tested method, open code, public checkpoints and a detailed paper. The main innovation is not just drafting more tokens. It is making the system more selective about which speculative work is worth verifying.

For enterprise teams, the broader lesson is that the next wave of AI performance gains will not come only from larger models. It will also come from smarter ways to run the models companies already have — especially when those companies control enough of the stack to tune the model, train a compatible draft module and optimize the serving engine around real workloads.

What happens when frontier-level AI no longer requires an internet connection? Gemma 4 is empowering developers and communities across the globe by bringing advanced intelligence directly to local devices. By maximizing "intelligence per byte," Gemma 4 breaks down connectivity barriers, allowing powerful, multi-modal, and agentic AI to run efficiently anywhere, on anything. In this video, explore how creators and organizations are using Gemma 4 to solve real-world problems today: Empowering Local Healthcare: Organizations like Crane AI Labs in Uganda are building impactful, offline systems to help reduce maternal mortality rates in low-connectivity areas. Preserving Culture and Language: Discover how developers are easily fine-tuning Gemma 4 for indigenous languages like Quechua, providing new digital resources for underrepresented communities. Democratizing Technology: Hear from Google DeepMind engineers and global partners like Typhoon AI on why open-source AI is critical for global freedom and technological access. Learn how the open Gemma 4 ecosystem can help you build systems for your own community.

https://deepmind.google/models/gemma/gemma-4/

Try Google AI Studio → https://goo.gle/4whe1vR
The Build with Gemini XPRIZE is live, and there is a $2 million prize pool up for grabs Google and XPRIZE are challenging you to build a business with AI that solves a real problem, so go build something cool! → https://goo.gle/4oV0aIV

What happens when a group of Google engineers can't agree on what to have for dinner? Instead of just picking a restaurant, the team decided to "vibe code" their own custom decision-making apps using Google AI Studio. Stick around until the end to see the final app showdown.

Chapters:
0:00 - Introduction
0:45 - Aron’s app
1:28 - Ash’s app
2:11 - Denise’s app
2:36 - Luke’s app
3:59 - Laxmi’s app
4:47 - Mark’s app
5:57 - Apps in action time
5:41 - The peace crucible
6:40 - The Chow Loud Squad
8:16 - Pineapple Pizza Pointer
9:09 - The Decision Maker
10:24 - Chat and Choose
11:15 - VibeCheck Eats
12:09 - Give AI Studio a try
12:23 - Google and XPRIZE competition

#Firebase #vibecode

Subscribe to Firebase → https://goo.gle/Firebase

Speakers: Aron Eidelman ,Ash Nohe,Denise Kwan, Laxmi Harikumar, Luke Schlangen,Mark Thompson
Products Mentioned: Firebase, Antigravity, AI Studio, Android, Angular

The post RTX 5090 16-Pin Connector Melts Badly, Killing GPU and VRAM appeared first on OnMSFT.

The post Liquid AI Ships LFM2.5-230M with llama.cpp, MLX, vLLM, SGLang, and ONNX Support for On-Device Inference appeared first on MarkTechPost.

Ian Ballantyne, Developer Relations Engineer at Google DeepMind, shows how Gemma runs on hardware like Raspberry Pi, Jetson, and Nano, letting a model see, hear, and act the way a robot would. The demo is Reachy Mini, the open source robot from Hugging Face and Pollen Robotics, a small robot that sees with cameras, reacts with emotion and head movement, and holds a conversation through its microphone and speaker.

What's covered: A live conversation with Reachy Mini about why local on-device models matter for privacy and speed, the robot's ability to move its head, show emotion, and take pictures to understand its surroundings, controlling smart devices and APIs like lights, thermostats, calendars, and live data, and an early look at the robot reasoning about a chessboard and explaining how a knight moves.
Explore the Reachy Mini project from Hugging Face and Pollen Robotics, and try running Gemma on your own hardware.

What would you build with Gemma on a robot or IoT device? Drop it in the comments.

Resources:
Reachy Mini → https://goo.gle/4xJNpVJ
Local Reachy Mini → https://goo.gle/4f1dOXC
Gemma Docs → https://goo.gle/4xMnVXS
Gemma Cookbook → https://goo.gle/4epYEuZ


Subscribe to Google for Developers → https://goo.gle/developers

Speaker: Ian Ballantyne
Products Mentioned: Google AI, Gemini

The post From Local LLM to Tool-Using Agent appeared first on Towards Data Science.

This is a 230-million-parameter foundation model explicitly designed for on-device agentic workflows, and as Liquid states in its release blog post, that small size makes it possible to run nearly "anywhere." According to Liquid, it also outperforms models more than 4X its size on selected benchmarks, specifically doing better at data extraction than the 800 million parameter count Alibaba Qwen3.5-0.8B (Instruct) and 1-billion parameter Google Gemma 3 1B.

The model targets developers and engineers building lightweight data extraction pipelines and autonomous edge systems.

Operating under a dual-use commercial license, the model remains free for individuals and companies generating less than $10 million in annual revenue, while requiring a paid enterprise agreement for larger corporations.

This release distinguishes itself from other small AI models by utilizing the LFM2 architecture to achieve high inference speeds without the massive memory overhead typical of parameter-heavy transformers.

While major AI companies Anthropic, OpenAI, Google, Microsoft, Meta and others push parameter counts into the hundreds of billions or trillions to achieve frontier performance, a parallel race focuses entirely on the edge and local deployments.

Liquid AI's launch of LFM2.5-230M signals a pivotal shift toward architectural efficiency over brute-force scaling. By squeezing 19 trillion tokens of pre-training into a 230-million-parameter footprint, the company demonstrates that edge devices do not need massive computational power or persistent cloud connections to execute complex, multi-step agentic workflows.

How LFM2.5-230M works

The LFM2.5-230M model diverges from standard transformer architectures, relying instead on the LFM2 framework. This architecture functions as a hybrid system, interleaving gated short-range convolutions with grouped-query attention to process information efficiently.

For those tracking the evolution of efficient architectures, Liquid’s approach shares a similar conceptual goal: managing long contexts and sequential data effectively on edge hardware without the quadratic memory costs of pure attention mechanisms. The model supports an expansive 32K context window, allowing it to ingest substantial documents or continuous streams of robotic telemetry.

When analyzing the performance charts provided in the release, the architectural efficiency becomes visually apparent. The model maintains a memory footprint of under 400MB while achieving prefill and decode speeds that outpace comparable models like Gemma 3 1B IT and Granite 4.0-H-350M.

On a Samsung Galaxy S25 Ultra equipped with a Qualcomm Snapdragon Gen4 CPU, the model reaches a decode speed of 213 tokens per second. Even on a highly constrained Raspberry Pi 5, the model maintains a decode rate of 42 tokens per second. Furthermore, internal benchmarking shows the GPU inference stack delivers lower end-to-end latency than competing small models across all concurrency levels.

Why it matters for enterprises

To understand why a 230-million-parameter model is necessary, one must look at how enterprises currently manage data.

Organizations have traditionally relied on rigid, rule-based Extract, Transform, Load (ETL) scripts to move and process data. However, these legacy systems are notoriously brittle; a simple change in a document's layout or a schema update can break the entire pipeline.

To solve this, the industry is shifting toward "AI ETL," where machine learning infers mappings, detects schema drift, and adapts to changes automatically. In a modern lightweight data extraction pipeline, an AI model connects to unstructured sources—like PDFs, emails, or web forms—and structures the data into formats like JSON without requiring hardcoded rules.

For enterprises, using a massive flagship model like Claude Opus 4.6 (which costs $5.00 per million input tokens) to parse routine invoices, format addresses, or route telemetry data is economically unviable.

This is where models like LFM2.5-230M become critical. Designed explicitly as a lightweight extraction engine, it allows companies to automate repetitive formatting and data parsing at a fraction of the compute cost and latency, running directly on local hardware rather than relying on expensive, continuous cloud API calls.

Small Model Benchmarks: LFM vs. The 3B Class

The AI industry in mid-2026 is seeing a renaissance in "small" models, but the definition of "small" varies wildly.

Recently, the open-weight community was stunned by Weibo's VibeThinker-3B, a 3-billion-parameter model built on a Qwen2-style backbone that achieved a massive 94.3 on the AIME 2026 math benchmark, rivaling 600-billion-parameter behemoths through aggressive data curation and reinforcement learning.

Similarly, Google's Gemma 4 family — which recently crossed 200 million downloads — pushes frontier AI to the edge, including the E2B (2 billion parameters) designed specifically for mobile and IoT deployments.

By contrast, Liquid AI's LFM2.5-230M operates in a completely different weight class. At just 230 million parameters, it is roughly one-tenth the size of Google's smallest Gemma 4 model and VibeThinker-3B.

Because of its microscopic footprint, LFM2.5-230M is not designed to compete on reasoning-heavy workloads like advanced math, coding, or creative writing—a constraint Liquid AI explicitly acknowledges.

However, in its intended domains of data extraction and tool calling, the model punches well above its weight class.

Benchmarks released by Liquid AI show LFM2.5-230M scoring 43.26 on the BFCLv3 tool-use benchmark, dominating IBM's Granite 4.0-350M (39.58) and completely outpacing larger 1-billion-parameter models like Google's Gemma 3 1B IT (16.61).

On CaseReportBench for data extraction, it scores 22.51, decimating the Qwen3.5-0.8B (Instruct).

LFM2.5-230M proves that while 3-billion-parameter models like VibeThinker are solving advanced calculus, a 230-million-parameter model is the superior, highly optimized choice for executing structured tool calls and keeping agentic pipelines running efficiently on constrained hardware.

Advanced research uses

Because it excels at tool calling, LFM2.5-230M functions primarily as a skill-selection layer. Liquid AI demonstrated this capability by deploying the model on a Unitree G1 humanoid robot.

Running entirely on-device via the robot's onboard NVIDIA Jetson Orin compute module, the model successfully processes complex environmental commands.

As noted in the company's technical blog, the model takes a free-form instruction like, *"Hold still for 2 seconds, then walk forward at 1 meter per second for 3 meters, hold a forward one-leg kneel for 5 seconds, and walk backward at 0.5 meters per second for 3 meters,"* and automatically translates it into a structured multi-step plan calling on pre-trained low-level skills provided by NVIDIA's SONIC framework.

The base and post-trained models are available immediately on Hugging Face, with native day-one support across the inference ecosystem for llama.cpp (GGUF), MLX, vLLM, SGLang, and ONNX.

Dual-use, custom LFM Open License

Liquid AI ships LFM2.5-230M under the LFM Open License v1.0. Despite the word "open" in the title, this is not an Open Source Initiative (OSI) compliant license; it operates as a restricted, dual-use commercial framework.

For independent developers, researchers, and early-stage startups, the license functions identically to open-source software.

Users receive a perpetual, worldwide, royalty-free license to reproduce, modify, and distribute the model, provided they retain original copyright notices and prominently state any modifications.

However, the license includes a strict "Commercial Use Limitation". Any legal entity generating $10 million or more in annual revenue loses the right to use the model commercially under this agreement.

Large enterprises crossing this financial threshold must negotiate a separate, paid commercial agreement with Liquid AI to deploy the model in production.

This strategy protects the company from having its intellectual property absorbed by major technology conglomerates for free, while still seeding the model at the grassroots developer level.

The post DeepReinforce Releases Ornith-1.0: An Open-Source Coding Model Family That Learns Its Own RL Scaffolds appeared first on MarkTechPost.

Welcome back to Developer News! Host Anaya Mehta breaks down the latest major Google developer announcements from Google I/O, including near real-time translation Gemini 3.5 Live Translate, local agentic workflows with Gemma 4 12b, and Gemini in Xcode, where we bring Gemini directly to Apple platform developers. See how these tools can uplevel your developer workflows!

Chapters:
0:00 - Introduction
0:25 - Gemini 3.5 Live Translate
0:54 - Live Translate demonstration
2:09 - Gemma 4 12B on AI Edge
3:23 - Gemini in Xcode
4:01 - Conclusion

Resources:
Introducing Gemini 3.5 Live Translate Video → https://goo.gle/4oFhX6W
Gemini 3.5 Live Translate blog → https://goo.gle/4ogWS2D
Gemma 4 12b Announcement Blog → https://goo.gle/3QElqWJ
Gemini in Xcode Blog → https://goo.gle/44nPLMt

Watch more Google Developer News → https://goo.gle/4e8Rysd
Subscribe to Google for Developers → https://goo.gle/developers

#GoogleDeveloperNews

Speaker: Anaya Mehta
Products Mentioned: Google AI, Gemini, Gemma

The post 3 Agents. 3 LLMs. 1 Aging GPU: Engineering Parallel Inference on Bare Metal appeared first on Towards Data Science.

Am 23. Juli erscheint das Remake des ersten Halo für Xbox, PlayStation und den PC. Für letzteren gibt es jetzt die Systemanforderungen. Minimal sollte es eine GeForce RTX 2060 Super sein, in jedem Fall braucht es zudem 100 GB SSD-Speicher. Am liebsten hätte der Shooter außerdem 32 GB RAM und 16 GB VRAM.

The post A Three-Phase Factual Recall Circuit in Gemma-2B and Gemma-12B-IT appeared first on Towards Data Science.

--------------------

01 Introduction

This is the second follow up to my 8 part series on nuclear power. In this episode I will attempt to answer a question posed by brian in ohio in a comment on HPR4583. In that comment he said:

02

--------------------

Loving this series. Maybe Whiskey Jack could give some cost comparisons between large and small reactors. He could also give us a realistic look at nuclear plant safety/accidents compared to conventional power production. Looking forward to the episode on FORTH generation reactors ;-)

--------------------

03

End of quote.

The first question I answered in my previous follow up, which was HPR4628. In this episode I will attempt to answer the second question, which was about the safety of nuclear power compared to other sources of electrical power generation.

One of the HPR janitors encouraged me to make this episode, so I think we can thank him for getting another HPR episode made.

04 Defining the Scope

First, let's define the scope of the question.

This will cover electrical power generation only.

Within that scope I will consider only the following sources of energy.

05

Coal

Oil

Natural Gas

Hydroelectric

Nuclear

Wind

Solar

I won't cover geothermal, wave, or tidal power as these are only used in very small amounts and so there simply isn't enough literature on them to base a discussion on .

06 Foreshadow Conclusion

I should mention right away that I cannot provide absolute answers to this question in the form of a nice, neat ranking table based on numbers from peer reviewed scientific sources.

The reasons for this will become apparent, but to put it briefly, the data on which to base such a ranking simply doesn't exist.

I will however provide context within which people can think about the issue.

Wherever possible, I will provide links to the references that I used in the show notes so you can read further on this yourself.

--------------------

07 Energy Catastrophism versus Energy Uniformitarianism

First though I need to go off on a slight geological detour in order to explain an important analogy that I will use.

08

In the 19th century there was a great debate among geologists over what is known as catastrophism versus uniformitarianism.

In seeking to explain the origins of the earth and of the landscape that we see around us, there were two points of view.

09

One was "catastrophism".

This is the belief that the mountains, valleys, and plains that we see around us were formed as a result of great catastrophes which occurred relatively recently in earth's history.

This explanation was necessary in order to fit geological features into an earth that was believed to be only a few thousands of years old.

This view was heavily influenced by religious belief.

In this view Noah's flood was the great catastrophe and the fossils of dinosaurs were the remains of animals who had not been saved on the ark and so had died in the flood.

10

The other point of view was uniformitarianism.

This was the hypothesis that the landscape we see around us can be explained by the very slow accumulation of very small changes over very long periods of time.

For this to be true however, the earth had to be far older than the few thousand years that a literal reading of the bible would suggest.

The earth in fact had to be many, many, millions of years old.

11

Eventually, the uniformitarian view won out and people understood that while some catastrophes can take place, the shape of the landscape is overwhelmingly due to small changes over very long periods of time.

12 How is this Relevant to this Episode You Ask?

How this is relevant is that I will use this analogy to explain how we need to think about energy and safety.

Very small numbers of deaths and injuries multiplied over many occurrences can add up to big numbers, comparable in scale or possibly even larger than a single catastrophe or even several of them.

13

I don't know if anyone else has used this analogy before, I have just thought of this when writing the script for this podcast.

None the less, I think it is a very useful way of helping to understand the issues.

14

As an example of this, think about the well known case of the safety of flying versus the safety of travelling in your car.

Air crashes are catastrophes that make the headlines.

Automobile crashes are seldom more than local news at best.

You have probably heard many times the claim that if you making a trip somewhere, you are safer to fly than to drive yourself in your car.

15 Example - Hydro versus Solar

I will now present an example of this.

Hydro electric power has some notable large scale catastrophes associated with it.

Roof top solar power does not have any notable catastrophes that I am aware of.

However, which is safer?

16 Hydro Catastrophes

Here are three examples of hydro electric catastrophes in just one country, Italy.

The Vajont Dam which collapsed in1963

An estimated 1,917 to 2,500 people died.

The Sella Zerbino dam which collapsed in 1935.

More than 100 people died.

The Gleno Dam which collapsed in 1923.

An estimated 350 people died.

https://damfailures.org/

https://pmc.ncbi.nlm.nih.gov/articles/PMC4997708/

17

I haven't tried to compile a global list of the worst hydro electric dam collapses, as this sort of information is actually very difficult to find, even on web sites dedicated to dam failures.

An additional problem is that information on whether a dam was used for electric power generation or not is often not available.

18

Dam failures where contradictory or insufficient information is available on whether there was an associated hydro power plant include the 1975 Banqian Dam failure, where death estimates range up to a quarter of a million.

19 Solar Panel Slow Accumulation

Contrast this with roof top solar panels.

Many small accidents can add up to big numbers as well.

20

Health and safety literature discussing solar panel safety mention things such as

Falls from roofs.

Electric shock.

Arc flash (burns from electrical arcing).

Normal electrical safety procedures which are based around locking out sources of energy do not work with solar panels which makes safety more difficult.

Heat stress due to working exposed in the hot sun.

Warning from US government on falls by solar panel installers.

https://stacks.cdc.gov/view/cdc/228946

https://www.osha.gov/green-jobs/solar

21 Why We Cannot Compare the Two

Hydro catastrophes are not well documented, but we can at least find records of some of the most notable ones.

However, even those have very large variations in estimates of deaths.

22

Roof top solar deaths however are largely undocumented.

The industry is largely unregulated.

There is no central authority which accumulates many individual deaths or injuries.

At best there are worker and public safety bodies who simply accumulate those statistics into general construction or household injuries.

23

Thus we have no reliable means of comparing the two energy sources on a comparable basis.

We face the same problem with all other major electrical energy sources.

So far as I am aware, there are no peer reviewed scientific studies which compare the relative safety of all of the major electrical energy sources we are considering here based on actual numbers.

--------------------

24 Safety Risks

I will now try to list some the major hazards for each of energy sources we are considering.

There is however limited data available.

In many cases we just have reference to worker safety organizations as to what the hazards are.

I will not attempt here to put numbers to these here.

Categories

25 Coal, Oil, Natural Gas

The hazards are

Air pollution

Mining and oil field accidents

Pipeline explosions

Transportation accidents. These- move a lot of material so these are significant.

26 Hydroelectric

These include

Dam collapse

Drowning

27 Nuclear

These include

Radiation exposure

28 Wind

These include

Falls

Confined space deaths (there is not much detail on this)

Electric shock

Ice throws (that is, throwing pieces of ice off the blades)

This technology has a significant problem with people working alone which greatly increases risks associated with other dangers.

29 Solar

These include

Falls

Electric shock

Arc flash

Heat stress

30

I have not tried to cover all possible risks associated with each category, just the ones which each industry considers to be the risks they concern themselves with.

There does not exist any means by which risks of similar types are compared across different industries.

31 Reliability of Supply is Also Safety

In a completely electrified net zero society, reliability of supply is a safety matter.

People will die in very large numbers in cold climates if they do not have heat.

If we have no fossil fuels, we need to also consider how reliably does a grid based on any of the options work.

I have not seen anyone attempt to address this question and will not attempt to address it here.

However, it must be addressed in any comprehensive attempt to rank safety.

--------------------

32 Studies or Articles on Estimates of Relative Safety

Despite the difficulties of comparing the safety of different sources of energy, some people have attempted this anyway.

Different estimates done at different times had different focuses, so unfortunately we do not have a nice set of studies that we can neatly use to cross check one another.

I will however list the names and the authors and summarize the results.

--------------------

33 The Health Hazards of Not Going Nuclear

By Dr. Petr Beckman

Published in 1976

The author of this book tried to address the relative safety of different sources of energy in the mid 1970s.

However, it is old at this point, so I won't bother digging through its pages to find his figures.

34

He mainly focused on comparing electric power generated with coal to nuclear.

His conclusion was that if the goal was to prevent deaths or ill health in the process of generating electricity, then the logical conclusion was to replace coal fired power plants with nuclear.

35

The book was relatively well known at the time, as least as far as books on energy are concerned, so I thought it was still worth mentioning.

I happen to have a copy of this book which I bought back in that time period

It was the 8th printing of the book, so it would appear to have had relatively good sales.

36

The author did address the issue of what I have termed "catastrophism" in his comparison of different energy sources, although I don't know if he used this phrase.

I don't know if he was the first to use this sort of analysis, but he certainly was very influential in terms of popularizing it.

--------------------

37 Risk of Energy Production

by Herbert Inhaber

Publication AECB 1119

March 1978

This study is a scientific paper from the same time period as the book "The Health Hazards of Not Going Nuclear".

38

He based his risk estimates largely on estimates of the amount of material which was used in the construction and operation of various power sources.

While we could argue over whether or not this is a valid methodology, I think any such argument would be pointless as I think the age of the study alone renders it not relevant today anyway.

Advancements in materials have changed the basis results significantly by now.

However, as it exists I thought I would mention it to show that the idea of comparing energy sources to each other is not a new one.

The author compared a wider variety of potential sources than Beckman did.

39

Here's his conclusions.

He assumes equal amounts of energy produced by each method.

The numbers are normalized such that the total sums to 100%.

You can think of it in terms of what proportion of total deaths or injuries would result from each source if each were equally used.

40

Coal 27.5%

Oil 25.6%

Methanol 16.7%

Wind 10.8%

Solar photovoltaic 9.2%

Thermal 8.1%

Solar space heating 1.5%

Ocean thermal 0.4%

Nuclear 0.13%

Natural Gas 0.08%

41

His natural gas estimate is drastically different from that of other authors.

I am not going to worry about explaining it however, as the study is as I said old enough to be not very relevant anyway.

I am mainly including this here out of historical interest.

42

As a footnote, the methanol he refers to would be synthesized from wood. This was a popular idea in that era as a means of providing liquid fuels for transportation. Practical battery electric cars in those days were strictly science fiction.

43

The ocean thermal category is a real blast from the past and I had forgotten all about that concept.

It was a very popular idea at that time and was supposed to be *the* big and upcoming thing in renewable energy.

It involved various means of attempting to extract energy from differences in water temperature at different depths in the ocean.

It gradually faded away however, as despite great efforts being put into it, designs never proved to be practical.

--------------------

44 Electricity generation and health

Anil Markandya, Paul Wilkinson

Published in the Lancet, Vol 370, 15 September 2007

45

This is more recent than the previous one, although it is nearly 20 years old at this point.

Unfortunately it doesn't cover wind or solar, just fossil fuels and nuclear.

However it is still useful, and the Lancet is a very reputable peer reviewed journal.

46

I will present just the results rather than discussing the whole paper.

The authors break it down into deaths among the public, occupational deaths, and air pollution related deaths, serious illness, and minor illness.

47

They break the energy sources down into lignite, coal, gas, oil, biomass, and nuclear.

Lignite is a type of very low grade coal used mainly for electric power generation.

In this paper biomass refers to energy crops and forest residues.

48

I will summarize the results by category rather than trying to describe a table that has 6 rows and 5 columns.

All numbers are normalized in terms of deaths or cases per TWh.

49

Occupational deaths from accidents

lignite 0.1

coal 0.1

gas 0.001

oil no data

biomass - no data

Nuclear is 0.019.

50

Deaths among the public from accidents

lignite 0.02

coal 0.02

gas 0.02

oil 0.03

biomass no data

Nuclear 0.003

51

Air pollution deaths

lignite 32.6

coal 24.5

gas 2.8

oil 18.4

biomass 4.63

Nuclear 0.052

52

Air pollution serious illnesses

lignite 298

coal 225

gas 30

oil 161

biomass 43

Nuclear 0.22

53

Air pollution minor illnesses

lignite 17,676

coal 13,288

gas 703

oil 9,551

biomass 2,276

Nuclear no data

54

Natural gas edges out nuclear power slightly in terms of occupational safety, but in every other category nuclear is drastically lower in terms of ill effects than any of the alternatives.

--------------------

55 2020 Fatalities for US Roofers Increased 15% as Solar Roof Installations Increase

Published in The Next Big Future

July 6, 2021 by Brian Wang

56

This seems to be written by someone who has a popular science blog.

I'm not familiar with it personally, but he addresses the subject so I'll list it.

The title implies that it's all about rooftop solar, but he provides comparative numbers for the other energy sources of interest, so that is useful for our purposes.

However, he doesn't describe his methodology, so we need to treat them with some caution.

Here are his results

These are deaths per thousand terawatt hours.

57

Coal - 100,000

Oil - 36,000

Natural gas - 4,000

Hydro - 1,400

Rooftop solar - 440

Wind - 150

Nuclear - 90

58

If we plot these numbers on a bar chart, coal and oil are so large that all of the others are squished to the bottom of the chart and are difficult to see at all.

Let's therefore look at these in terms of orders of magnitude.

Keep in mind that this is a logarithmic scale.

This means that the difference between 4 and 5 is much greater in linear terms than the difference between 1 and 2.

59

Coal - 5

Oil - 4

Natural gas - 3

Hydro - 3

Rooftop solar - 2

Wind - 2

Nuclear - 1

60

Each of these numbers represents an order of magnitude, that is a power of ten.

We can see that with rooftop solar, wind, and nuclear, the numbers are so close and the uncertainties are so great and their relative values so small compared to say coal that they can be seen as equivalent so far as safety is concerned.

--------------------

61 What are the safest and cleanest sources of energy?

by Hannah Ritchie

Published in Our World in Data

First published in 2017, updated in 2022 and 2024

62

The author of this study addressed both deaths and greenhouse gas emissions.

Deaths from accidents and air pollution are normalized to per TWh of electricity, while greenhouse gas emissions are normalized to GWh of electricity over the life cycle of the plant.

63

Here are the death figures.

Coal 24.6

Oil 18.4

Biomass 4.6

Natural Gas 2.8

Hydro power 1.3

Wind 0.04

Nuclear 0.03

Solar 0.02

64

For greenhouse gas emissions the figures are

Coal 970 tons

Oil 720 tons

Natural gas 440 tons

Biomass 78 to 230 tons

Solar 53 tons

Hydro power 24 tons

Wind 11 tons

Nuclear 6 tons

65

If we take the death figures and rank them by order of magnitude as we did with the previous article, we get the following.

66

Coal - 4

Oil - 4

Biomass - 3

Natural Gas - 3

Hydro power - 3

Wind - 1

Nuclear - 1

Solar - 1

67

Keep in mind that the previous article covered only rooftop solar and not large industrial installations, and so is not directly comparable.

Also the units are different, with the previous article being in terms of thousand TWh, and this one being in TWh.

If we exclude solar (as the numbers are not comparable), Brian Wang's numbers are between 1.5 to 4 times higher than Ritchie's, except for hydro which are almost identical. I think this latter is due to both sets of numbers are dominated by one exceptionally big hydro accident.

68

Overall however, the relative rankings are quite comparable.

Ritchie's numbers for deaths from coal, oil, and natural gas appear to be directly from the study by Markandya and Wilkinson mentioned above.

For the benefit of those who are wondering, Ritchie specifically states that her numbers for nuclear include the Chernobyl and Fukushima accidents.

--------------------

https://www.iaea.org/publications/magazines/bulletin/21-1/solar-power-more-dangerous-nuclear

Direct link to file

https://www.iaea.org/sites/default/files/publications/magazines/bulletin/bull21-1/21104091117.pdf

https://ourworldindata.org/safest-sources-of-energy

https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(07)61253-7/abstract

https://www.nextbigfuture.com/2021/07/2020-fatalities-for-us-roofers-increased-15-as-solar-roof-installations-increase.html

--------------------

69 Conclusion from Studies

Remember that in engineering terms, when comparing groups of numbers which contain both both very small numbers and one or more very large numbers, the differences between the small numbers are often not significant.

The differences between the small numbers may be the product of our ability to measure these things rather than any real differences.

70

For example, in the article by Ritchie wind power would appear to be twice as dangerous as nuclear.

However, the difference between them is 0.02 compared to 24.6 for coal.

In other words, the difference between apparently "dangerous" wind and apparently "safe" nuclear is equivalent to 0.08% of the total for coal.

It's therefore meaningless and a red herring to even worry about.

71

With the above taken into consideration, generally the different sources of energy fall into two broad categories in terms of number of deaths, injuries, and illnesses.

The fossil fuels and biomass fall into one group and wind, solar, and nuclear into another group.

72

Hydro power would seem to fall into the higher risk category or at least somewhere between the two, but this I suspect is mainly due to one exceptionally large dam collapse in China, the Banqian Dam failure in 1975.

This is mentioned as being specifically included in the article written by Ritchie.

This was a multi-purpose dam, and information on this dam is difficult to find.

It is not clear to me whether it had a hydro electric generator associated with either it or another dam that was part of the same system.

73

Some people therefor may argue for its exclusion from the numbers.

Of course some people may argue for its inclusion anyway, as it was a dam regardless of whether it actually had an electric generator attached.

If we exclude it, then I think the numbers for hydro power would fall into the same range as for nuclear, wind, and solar.

74

Most people would consider hydro power to be safe and clean enough regardless of this and I will rank it as such in any conclusions that I come to.

As you can see, even if we have numbers, it can be a matter of opinion as to how to interpret them.

--------------------

--------------------

75 Taking a Systems Approach

Now let's take a look at the broader energy picture today and into the future.

Many countries in many parts of the world have committed to the concept of "Net Zero", which means eliminating carbon emissions on a net basis.

Net zero essentially means the complete electrification of society.

We must therefore have electrical energy on demand and at low cost.

We must as a result of this look at complete electrical systems rather than individual sources in isolation.

76

At one time many electrical systems were entirely coal or entirely hydroelectric.

This is no longer the case.

There are now major amounts of wind and solar involved in many countries.

However these are inherently intermittent.

This means that other sources of energy are inherently also required to have a functional system.

77

If any particular solution inherently requires fossil fuels to meet part of the demand, then the safety, pollution, and climate issues relating to those fossil fuels have to be factored in to that complete system when trying to come up with a relative ranking.

Talking about Individual sources in isolation are therefore meaningless in these countries.

78

There are battery systems, but these are mainly used to stabilize and regulate the grid plus to a lesser degree to smooth out short term daily peaks in demand.

They do not have the ability to store large amounts of electricity on a large scale for an entire grid for days, weeks, and months to make up for intermittency.

79

So a serious attempt to rank sources of energy would need to look at a variety of representative countries and for each one come up with a plan that involves 'x' megawatts from source 'a', 'y' megawatts from source 'b', etc., and total up the values for each.

80

I am not aware of anyone who has studied this larger issue.

However, the problem has to be addressed from this perspective in order for any answer to be useful.

Not taking this into account is like ordering a diet soft drink to go with with a high calorie meal and assuring yourself that your plans to diet are fine.

81

This is not to imply there is anything inherently wrong with wind or solar.

It does mean that if your goal is to achieve both net zero and a clean environment, you have to look at your entire energy system as a complete system rather than focusing on what you feel are the most reassuring parts of it while ignoring the rest.

This does however add to the argument that it is in fact inherently very difficult to come up with a system of ranking energy sources for safety.

--------------------

82 Nuclear, Climate, and Clean Air - Contrasting Examples

To give a tangible example we will now look at two different places that followed two divergent paths at roughly around the same time frame.

These are the province of Ontario in Canada, and Germany.

83

Ontario had a mix of coal, hydro electric, and nuclear generating plants.

Germany had a mix of coal, nuclear and natural gas plants.

Ontario shut down their coal fired plants and kept their nuclear plants.

Germany however shut down their nuclear plants and kept their coal fired plants.

84 The Phase Out of Coal in Ontario

In 2003 Ontario decided to close all of its coal fired generating plants, which consisted of 19 units (that is boilers and turbines) totalling 8,800 MW.

This phase out was completed by 2014.

85

Here are the figures for amount of power generated by each energy source in 2003 and 2014.

Nuclear went from 42% to 60%

Hydro went from 23% to 24%

Gas went from 11% to 9%

Coal went from 25% to 0%

Non-hydro renewable went from 0% to 7%.

86

As you can see, the bulk of that replacement came from increased use of nuclear power.

Furthermore, this did not result in simply replacing coal with natural gas.

While gas is cleaner than coal, it still has emissions and if you recall from the studies that we looked at earlier, had an estimated death rate roughly 2 orders of magnitude greater than nuclear, solar, or wind.

87

To put this in more practical terms, at one time Toronto regularly had clouds of smog obscuring it, to a large extent due to these coal fired power plants

With the phase out of coal, smog days went to zero in 2015 compared to 53 a decade earlier.

The 2023 figures for Ontario show carbon emissions of 53 grams per kWh of electricity generated.

We can use this as a rough benchmark comparison for total emissions.

88 The Phase out of Nuclear in Germany

Until March of 2011, Germany generated one quarter of its electrical power from nuclear.

Starting in 2011 however, they began shutting down their nuclear power plants.

These were then phased out over the next decade.

However, the coal plants were to be kept to 2038.

In 2026 Germany began talking about increasing use of coal in order to save gas.

In the same year the German chancellor Friedrich Merz stated that the phase out of nuclear was a

quote “serious strategic mistake”.

EU Commission President Ursula von der Leyen said it was "a strategic mistake for Europe to turn its back on a reliable, affordable source of low-emissions power".

89

I won't go into the details of the phase out, but let's look at some emissions numbers for Germany.

If we look at the official numbers from the European Environmental Agency for 2024, for Germany their emissions were 298 grams per kWh of electricity generated.

Recall that we are using emissions as a very rough guide to amount of air pollution, and that this has a direct effect on the safety of the overall electrical energy system.

90

So, who actually made their people safer, Ontario who phased out their coal plants and kept their nuclear plants, or Germany who phased out their nuclear plants and kept their coal plants?

91

If you want a comparison directly within Europe, then Germany has one of the highest rates of emissions per kWh of electricity generated, whereas France, who use mainly nuclear power, have one of the lowest at 43 grams per kWh of electricity generated.

Again, who is making their people safer, Germany or France?

92

I don't want to make it sound like I am picking on Germany.

I am also not going to tell them how they ought to run their country.

However they provide a good real world example of how we need to look at things in overall context when we are thinking about the choices that we make.

https://www.ontario.ca/page/end-coal

https://www.cbc.ca/news/canada/windsor/smog-study-shows-significant-decreases-in-pollutants-in-ontario-1.4151183

https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1

https://world-nuclear.org/information-library/country-profiles/countries-g-n/germany

https://www.politico.eu/article/friedrich-merz-is-right-to-reject-germanys-nuclear-phase-out-says-iea-chief-fatih-birol/

https://www.politico.eu/article/germany-considers-ramping-up-coal-power-to-avert-energy-crisis/

https://www.iea.org/countries/estonia/electricity

https://www.iea.org/countries/malta/electricity

--------------------

93 Conclusions

As we can see, there don't appear to be an abundance of peer reviewed scientific studies that we can simply point to in order to answer the question of safety of all possible major different energy sources once and for all.

Collecting the data to even attempt to answer the question is inherently very difficult as we cannot readily conduct experiments to answer the question, and sources of data are not collected or consolidated in a manner which can answer this question adequately.

94

The essence of the problem is that most energy industries are not as tightly regulated and monitored to the same degree that say nuclear power or commercial airliners are, so this data is simply not being systematically recorded.

However, a number of people have attempted to make estimates.

95

Their conclusions would seem to be that nuclear, wind, and solar are roughly equivalent in terms of safety.

All fossil fuels are much less safe than nuclear, wind, and solar, by as much as several orders of magnitude.

96

We can however say with a reasonable degree of certainty that if a country shut down their nuclear power plants and kept their fossil fuel plants, particularly coal, then they probably made their people less safe than if they had done things the other way around.

97

I hope that I have provided some context in which to think about the issue.

Thanks again to brian in ohio for providing the question upon which this episode is based.

--------------------

Provide feedback on this episode.

The post Build Your Own Local AI Coding Agent with Gemma 4 and OpenCode appeared first on Towards Data Science.

Ian Ballantyne, Developer Relations Engineer at Google DeepMind, demonstrates Gemma 4's multi-agent capabilities by spinning up 10 independent subagents on a single local machine. A high-level prompt goes to an orchestrator, which delegates the work, and within seconds the agents return a complete SVG art gallery, coded locally, simultaneously, and autonomously.

What's covered: Running the Gemma 4 26B model locally, batch processing across 10 concurrent agents, orchestrator-and-subagent task delegation, inference speeds above 170 tokens per second, and what parallel local agents unlock for enterprise workflows and private on-prem deployments.

What would you build with parallel local agents? Drop it in the comments.

Subscribe to Google for Developers → https://goo.gle/developers

Speaker: Ian Ballantyne
Products Mentioned: Google AI, Gemini

Private Tuning of LLMs in Practice: From VaultGemma to Custom Fine-Tuning

Amer Sinha, Google

As enterprises adopt Large Language Models (LLMs), fine-tuning on proprietary data is essential for performance but introduces significant privacy risks. We present JAX Privacy, the actively maintained open-source library recently used to train Google's VaultGemma, proving that Differential Privacy (DP) works at production scale.
Moving beyond theoretical definitions, this talk focuses on the privacy engineering required to deploy secure LLMs. We define a precise threat model—protecting specific fine-tuning datasets from extraction attacks—and demonstrate a complete workflow using the Gemma model family. We provide a data-driven "before vs. after" analysis, contrasting the memorization risks in standard fine-tuning against the guarantees provided by JAX Privacy. Attendees will gain practical insights into managing computational overhead, optimizing privacy-utility trade-offs, and using our latest tooling to audit and deploy privately tuned models in cloud environments.
Authors: Ryan McKenna, Galen Andrew, Borja Balle, Vadym Doroshenko, Arun Ganesh, Weiwei Kong, Alex Kurakin, Brendan McMahan

View the full PEPR '26 program at https://www.usenix.org/conference/pepr26/program

Olivier Lacombe, Director of Product Management for Gemma, sits down with Gus Martins and Alice Zheng to dig into what Gemma 4 unlocks inside the Google AI Edge Gallery app. Alice walks through the app's growth since launch, more than five million model downloads in the first month, and demos two of the most popular use cases: asking Gemma to explain why the sky is blue completely offline, and using audio input to generate a structured shopping list on the spot. Gus covers the agent skills framework and what the community is building with it, from Wikipedia and WebFetch integrations to HTML rendering and mini games. They also preview MCP integration coming to Android first and then iOS, persistent chat history, and what it means that the 2B model this year is matching the performance of last year's 27B dense.

Resources:
Google AI Edge Gallery for Android → https://goo.gle/4vmF2Op
Google AI Edge Gallery for IOS → https://goo.gle/44jkpqk
Explore Gemma → https://goo.gle/44jktX6

The app is free, open source on GitHub, and available on the Play Store and App Store.

Subscribe to Google for Developers → https://goo.gle/developers

Speaker: Olivier Lacombe
Products Mentioned: Google AI, Gemma

Ian Ballantyne, Developer Relations Engineer at Google DeepMind, shows what Gemma can do on a Pixel 10 Pro using the Google AI Edge Gallery app. Image understanding, audio transcription, agent skills that route prompts to the right app on your phone, all running locally with no connectivity required.

What's covered: Using Agent Skills to route a voice prompt to a mood tracker app, taking a photo and outputting structured JSON Schema from it, generating suggestions from an image of plants, recording voice notes for transcription and translation, and identifying objects offline with multimodal image understanding.

Download the Google AI Edge Gallery app on Android or iOS and try Gemma on your own device.

What are you running on-device with Gemma? Drop it in the comments.
Subscribe to Google for Developers → https://goo.gle/developers

Speaker: Ian Ballantyne
Products Mentioned: Google AI, Gemini

Read more of this story at Slashdot.

Read more of this story at Slashdot.

The post Developer laptops are the credential store attackers are picking through in 2026, GitGuardian announces Endpoint Protection appeared first on Cyber Security News.

The post Developer laptops are the credential store attackers are picking through in 2026, GitGuardian announces Endpoint Protection appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Read more →

The post Developer laptops are the credential store attackers are picking through in 2026, GitGuardian announces Endpoint Protection appeared first on IT Security News.

This is the Coral Board, a small, low-power dev board with Google's Coral NPU machine learning accelerator inside, built for developers to experiment with on-device AI. It runs Gemma, and everything happens on the board. For I/O it ships as a kit with a screen, a camera, microphones, and LEDs, so you can see what's possible on the edge.

What's covered: Live translation with speech in and translated speech out running entirely on the board, natural language controlling physical hardware, and vision and sound working together in a lightweight version of the pre-I/O show that generates music from an aquarium of jellyfish, all on a single board.

The Coral Board is available this summer. Every demo in the video is open source and on GitHub to get you started. Follow the links below to learn more.

What will you build on the edge with Gemma? Drop it in the comments.

Subscribe to Google for Developers → https://goo.gle/developers

Speaker: Ian Ballantyne
Products Mentioned: Google AI, Gemini

"The last thing any of us want is a world where every company across every sector is ceding value to a few models that eat everything they see," Nadella wrote in the piece, titled "A frontier without an ecosystem is not stable," which he posted on X. "If all the value is accrued by only a few models, the political economy will simply not tolerate it. There is no societal permission for an AI future that hollows out entire industries."

The essay is unusually philosophical for a sitting CEO of a $3 trillion technology company. But it arrives at a moment when the theoretical risks Nadella describes are becoming tangible — and, critically, when Microsoft itself is grappling with the very dynamics he warns about.

Nadella introduces "token capital" as the new currency of enterprise AI strategy

At the center of Nadella's essay sits a conceptual framework built on two pillars he calls "human capital" and "token capital." Human capital, he writes, "comprises the knowledge, judgment, relationships, ingenuity, and pattern recognition of its people," while token capital refers to "the firm's AI capability it builds and owns."

The two are not in tension, he insists. "Importantly, human capital does not become less valuable as token capital grows. It only becomes more valuable!" he writes. "I believe human agency will be the driver of token capital growth. Humans will set ambitious goals, connect dots across domains, build relationships, and recognize patterns that matter most. Without human direction, you have compute running in circles."

This framing is a deliberate counterweight to the narrative that AI will simply replace human workers or, at the enterprise level, dissolve the intellectual property that differentiates one company from another. Nadella is arguing that the real danger is not AI's capability but its tendency to centralize — and that the solution requires a fundamentally new architecture for how businesses interact with the technology.

He describes the real opportunity as "not in picking the best model but instead in building a learning loop on top of models where human capital and token capital compound." The key test of a company's sovereignty in this new era, he writes, is whether it can "switch out a 'generalist' model without losing the 'company veteran' expertise built into their learning system."

This is the essay's most actionable claim — and its most provocative. Nadella is telling enterprises they need to decouple their institutional intelligence from whatever frontier model they happen to be running, creating portable knowledge systems that survive vendor changes.

Why Nadella is comparing AI concentration to the outsourcing crisis that gutted industrial economies

Nadella draws a pointed historical parallel to make his warning concrete. "Think about what happened in the first phase of globalization where entire industrial economies were hollowed out by outsourcing," he writes. "The GDP numbers looked fine on the surface, but the displacement was real and the consequences are still being felt. Let us not bring that dynamic into the AI era, with a small number of AI systems capturing all the economic returns, while entire industries find their knowledge commoditized right out from underneath them."

The globalization analogy is not accidental. It reframes the AI concentration debate from a narrow technology question into a political-economy argument — one that regulators, policymakers, and voters can grasp. By invoking the social costs of offshoring, Nadella is signaling that the stakes extend well beyond the enterprise technology stack. He is warning that if the AI industry fails to distribute value broadly, the political system will intervene to force the issue.

"In my view, our priority has to be building a frontier ecosystem, not just a frontier model, so value flows broadly across every company, every industry, and every country," he writes. He grounds this in an older platform philosophy: "This is the ethos I've grown up with where platforms enable more value on top than is captured inside, and where every company can continuously innovate and build value of its own." It is a direct echo of the Windows-era argument, updated for the age of inference — and it carries a similarly self-interested subtext, given that Microsoft's cloud business sits squarely in that platform layer.

Microsoft's own runaway AI costs reveal the gap between Nadella's vision and operational reality

What makes Nadella's essay so striking is its timing. He published it on a day when Reuters reported that Microsoft shareholders filed a proposed class-action lawsuit in Seattle federal court, accusing the company of inflating its stock price by failing to disclose slowing growth in its Azure cloud business and the need to spend billions of dollars on AI infrastructure. The suit names Nadella and Chief Financial Officer Amy Hood among the defendants.

As the Yahoo Finance report on the lawsuit noted, Microsoft allegedly "aggressively promoted its AI developments, specifically its 'Copilot' assistant and close financial alliance with ChatGPT creator OpenAI, to artificially boost investor optimism," while understating infrastructure strain and capital risks. Microsoft also reported $37.5 billion of capital spending in its second quarter, up nearly 66% from a year earlier and above the $34.3 billion that analysts projected.

Microsoft's internal cost pressures around AI have surfaced in other concrete ways this year. The company is canceling the majority of its internal Claude Code licenses in its Experiences and Devices division, effective June 30, 2026. Monthly usage rates reached 84 to 95% by April 2026, and per-engineer API costs ranged between $500 and $2,000 monthly, according to Windows Forum. The cancellation came after Microsoft exhausted portions of its annual AI budget due to token-based billing, as Fortune had reported in May.

The Claude Code episode illustrates, at the micro level, the exact dynamic Nadella describes at the macro level. When a company's AI usage is metered by the token — the fundamental unit of compute that powers model inference — the more productive the tool becomes, the more expensive it gets. The term "token capital" in Nadella's essay carries a double meaning: it refers both to a firm's proprietary AI capability and, implicitly, to the actual tokens consumed in running it. Building a learning loop that compounds is aspirational. Paying the bills for that loop is operational reality.

Uber, Meta, and Amazon are all hitting the same AI spending wall — and it validates Nadella's warning

Microsoft is not alone in this bind. Uber burned through its entire 2026 AI coding tools budget in just four months after incentivizing employees to adopt the technology through an internal leaderboard ranking teams by total AI tool usage. Uber has since instituted a monthly $1,500 cap per employee per agentic coding tool, according to TechCrunch. At Meta, an employee created a leaderboard called "Claudeonomics" to track which workers consumed the most AI tokens. Amazon, meanwhile, has pushed employees to "tokenmaxx" — use as many AI tokens as possible.

The emerging pattern is clear: enterprises adopted AI coding tools aggressively, saw genuine productivity gains, and then discovered that the consumption-based economics of frontier models created budget crises that traditional software licensing never would have. Bryan Catanzaro, vice president of applied deep learning at Nvidia, captured the tension bluntly in an interview with Axios: "For my team, the cost of compute is far beyond the costs of the employees," he said.

These cost dynamics land differently in the context of Nadella's essay. He prescribes a three-layer architecture — evaluation, reinforcement learning, and retrieval — designed to sit between a company's workforce and whatever frontier model it subscribes to. Companies, he argues, need to build "private evals" that "capture whether a model is actually improving against outcomes that matter to the business (not just external benchmarks!)," alongside "private reinforcement learning environments" that "let models grow stronger on real traces from inside the organization" and a knowledge base that "makes institutional memory queryable and use of tokens more efficient." He calls the resulting system "a hill climbing machine" that, "unlike most assets, it compounds."

Other Big Tech CEOs are echoing Nadella's fears about AI models devouring enterprise knowledge

Nadella's concerns do not exist in isolation. Other technology leaders have been raising similar warnings throughout 2026, though none have offered as prescriptive a response.

Snowflake CEO Sridhar Ramaswamy warned in a February podcast that the biggest software companies risk being reduced to mere data sources. "The big model makers want to create a world in which all of the data for all of the enterprises is easily available to them," Ramaswamy said, describing everything else as "a dumb data pipe that feeds into that big brain." He added that Snowflake needs to operate with a "fear" that enterprises would abandon software-specific AI agents in favor of all-inclusive agents that hoover up data from everywhere.

Box CEO Aaron Levie struck a similar note in a January LinkedIn post. AI models can now perform high-level knowledge work across nearly every profession, from law to strategy to scientific research, he argued. "The question that we will have to wrestle with is, in a world where everyone has access to the same expert intelligence, how does a company differentiate?" he wrote.

The combined effect of these statements is a shared diagnosis from three very different corners of the enterprise technology market: the current trajectory of AI development threatens to collapse competitive differentiation across entire industries. Nadella's essay stands apart from the others because it moves beyond diagnosis and proposes a specific architectural remedy. But the prescription is impossible to separate from the prescriber's interests.

Microsoft sits in precisely the platform layer that Nadella's framework would make indispensable — the company builds its own frontier models, operates the cloud infrastructure those models run on, and maintains deep partnerships with the leading independent AI labs. A world in which every enterprise builds a proprietary learning loop on top of commodity foundation models is, conveniently, a world in which Microsoft sells the picks and shovels to all of them.

Nadella's Scout controversy and shareholder lawsuit reveal the tension inside Microsoft's own AI strategy

The essay also arrives just ten days after Nadella publicly rebuked one of his own executives for outlining a plan to "make people addicted" to a new AI tool called Scout.. Microsoft corporate vice president Omar Shahine had written an internal memo describing a three-phase plan to transform Scout "from addictive app to agentic platform," with the first phase focused on features that "make people depend on it daily." Nadella responded on an internal message board: "This is absolutely a non-goal! If anything we are doing the exact opposite. We want to make sure AI empowers and adds real value to human endeavor and broad economic growth!"

The Scout incident and Sunday's essay together suggest Nadella is actively constructing a public philosophy of AI that emphasizes broad value creation over extractive engagement — whether or not every corner of Microsoft has internalized that message. One anonymous Microsoft employee told 404 Media, as the Post reported, that the leaked Scout document was "very troubling," adding: "It feels like one of those 'saying the quiet part out loud' moments."

For technical decision-makers evaluating Nadella's essay, the practical implications are significant. He is arguing that choosing an AI model matters less than building the learning infrastructure around it. He is arguing that the ability to swap models without losing institutional intelligence is the critical test of AI sovereignty. And he is warning that companies that fail to build these systems will find their expertise absorbed and commoditized by the models themselves. "You can offload a task, or even a job, but you can never offload your learning," Nadella writes. "The future of the firm is the ability to compound that learning across people and AI."

The question Nadella's essay cannot answer is whether Microsoft will practice what its CEO preaches

Whether Nadella's vision materializes depends on a question his essay carefully sidesteps: whether the platform providers who build and host the frontier ecosystem will resist the temptation to capture the value flowing through it. Nadella insists that "platforms enable more value on top than is captured inside." But Microsoft's own trajectory this year — the ballooning capital expenditures, the Claude Code budget crisis, the shareholder lawsuit alleging concealed costs, the internal memo about making users addicted — suggests the economics of restraint are harder than the philosophy of restraint.

Nadella ends his essay with the claim that broad value distribution "is the stable equilibrium we should build together." He may be right. Ecosystems have historically outperformed walled gardens over long time horizons. But stable equilibria require every major player to forgo short-term extraction in favor of long-term compounding — and right now, the AI industry is burning through budgets in four months and spending 66% more on infrastructure than analysts expected. The CEO of the world's most valuable technology company has written an eloquent argument for why the AI economy needs to work differently. The open question is whether his own company's balance sheet will let him prove it.

Breaking Changes

• Renamed owned tool-calling options from toolCallSyntax/exampleSyntax to dialect/exampleDialect.
• Changed compaction conversation serialization to use the target model's native dialect turn, thinking, tool-call, and tool-result envelopes when a dialect is selected.
• Renamed the owned dialect environment variable from PI_OWNED_TOOLS to PI_DIALECT.

Added

• Added onTurnEnd hook support (setOnTurnEnd/onTurnEnd) to run awaited per-turn bookkeeping with current messages before the next model request and skip callback execution for aborted or error turns

Changed

• Renamed toolCallSyntax option to dialect in AgentOptions and AgentLoopConfig
• Updated conversation serialization to use dialect's native transcript rendering when a dialect is selected
• Changed internal references from ToolCallSyntax type to Dialect type across agent loop and compaction modules

@oh-my-pi/pi-ai

Breaking Changes

• Renamed the public dialect entrypoint from @oh-my-pi/pi-ai/grammar to @oh-my-pi/pi-ai/dialect.
• Renamed grammar dialect identifiers from ToolCallSyntax to Dialect, renamed the Grammar interface to DialectDefinition, and renamed Grammar.syntax to DialectDefinition.dialect.
• Added DialectDefinition.renderThinking and DialectDefinition.renderTranscript so dialect implementations serialize complete native chat transcripts, not just tool call/result blocks.

Added

• Added renderTranscript method to dialect definitions for serializing complete native chat transcripts
• Added renderThinking method to dialect definitions for rendering thinking/reasoning blocks
• Added support for 11 dialect implementations: Anthropic, DeepSeek, Gemini, Gemma, GLM, Harmony, Hermes, Kimi, Pi-native, Qwen3, and XML
• Added createInbandScanner factory function to instantiate dialect-specific scanners
• Added getDialectDefinition function to retrieve dialect implementations by name
• Added renderToolCatalog and renderInbandToolPrompt functions for tool catalog rendering
• Added renderToolInventory function to generate human-readable per-tool documentation with examples
• Added renderToolExamples function to render tool usage examples in the model's native dialect
• Added encodeInbandToolHistory function to encode tool call history in dialect-specific format
• Added wrapInbandToolStream function to process streaming responses with in-band tool call parsing
• Added ThinkingInbandScanner for parsing thinking/reasoning blocks across dialects
• Added OwnedStream class for managing dialect-aware streaming with tool call events
• Added in-band thinking channels to every dialect that was missing one: gemini (a ```thinking fence mirroring ```tool_code), gemma (its native <|channel>thought…<channel|> reasoning channel), kimi (<think>…</think>), and pi (<thinking>…</thinking>). Each scanner now parses reasoning into thinking events instead of leaking chain-of-thought into the visible reply, and every dialect's renderThinking is a real channel that round-trips back through its scanner (no passthrough renderers).

Changed

• Moved public dialect entrypoint from @oh-my-pi/pi-ai/grammar to @oh-my-pi/pi-ai/dialect in package exports
• Updated internal imports in stream-markup-healing.ts to use new dialect module path
• Changed renderToolInventory to demote a tool description's own markdown headers by one level when it contains a top-level # header, so they nest under the wrapping # Tool: <name> heading instead of reading as sibling sections. Descriptions that already start at ## and headers inside fenced code blocks are left untouched.

Fixed

• Fixed Gemini, Gemma, Kimi, and Pi in-band scanners to respect parseThinking: false, leaving private reasoning markers in visible text when parsing is disabled
• Fixed thinking-channel parsing for streaming Gemini, Gemma, Kimi, and Pi outputs so split or partial <thinking> blocks no longer leak into visible replies
• Fixed in-band thinking finalization and Kimi stream-healing interactions so leaked <think> blocks are preserved when structured tool calls are present, not duplicated when explicit reasoning is present, and closed on stream flush.

Removed

• Removed src/grammar/factory.ts (replaced by src/dialect/factory.ts)
• Removed src/grammar/rendering.ts (functionality moved to src/dialect/rendering.ts)
• Removed src/grammar/xml.ts (replaced by src/dialect/xml.ts)

@oh-my-pi/pi-catalog

Breaking Changes

• Renamed the catalog-owned tool syntax API from ToolCallSyntax/FALLBACK_TOOL_SYNTAX/preferredToolSyntax to Dialect/FALLBACK_DIALECT/preferredDialect.

@oh-my-pi/pi-coding-agent

Breaking Changes

• Renamed the SDK tool format type and resolver from ToolCallFormat/resolveToolCallSyntax to DialectFormat/resolveDialect, and the agent option from toolCallSyntax to dialect.
• Changed /dump transcript output to render messages with the selected model's native dialect turn and thinking envelopes instead of markdown role headings.

Added

• Added advisor.syncBacklog setting (off, 1, 3, 5) to pause turn completion until advisor review backlog drops below the threshold, with a maximum 30-second wait
• Added advisor backlog synchronization at turn end when enabled so the main session stays aligned with the advisor's pending review turns
• Added automatic discovery of WATCHDOG.md files from user and project locations so advisor guidance from local watchdog instructions is appended to its system prompt
• Added /advisor on, /advisor off, /advisor status, and /advisor dump [raw] slash-command subcommands to manage the advisor at runtime
• Added advisor.enabled and advisor.subagents settings to enable the advisor and extend it to spawned task/eval subagents
• Added advisor status badge (++ in success color) to the status line when an advisor is active
• Added /dump [raw] flag to toggle between compact and legacy uncompact transcript output formats
• Added /advisor on, /advisor off, and /advisor status slash-command subcommands to enable or disable the advisor at runtime and view advisor status metrics
• Added a passive advisor: assign a second model to the advisor role and enable advisor.enabled to have it silently review each primary turn and inject severity-tagged advice notes via the advise tool. A nit rides the non-interrupting aside queue (batched into one card at the next step boundary), while a concern or blocker interrupts the running agent through the steering channel — aborting in-flight tools, or resuming the agent when it has already yielded — so high-severity advice is acted on immediately. Advice renders in the primary transcript as a distinct Advisor card, and the advisor gets hard-isolated read-only read/search/find access — bound to its own ToolSession so its reads never touch the primary's snapshot/seen-lines caches — to investigate the workspace before weighing in. The status line shows a ++ badge (in the success color, kept distinct from the model name) after the model name while an advisor is active, and /advisor dump copies the advisor's own transcript to the clipboard. Advisors are created only for the top-level session by default; enable advisor.subagents to extend them to spawned task/eval subagents.
• Animated "thinking" pulse (·‥…‥) shown in place of a hidden thinking block while the model is actively reasoning, so streaming progress is visible even with hideThinkingBlock enabled.

Changed

• Changed advisor prompting guidance to emit at most one advise per update and to prefer silence when the agent is on track
• Changed /dump default output to compact markdown format; use /dump raw for the legacy uncompact format
• Changed /dump and /advisor dump to default to compact transcript output and accept an optional raw flag for the legacy uncompact format
• Session dump output now renders message history using the model's native dialect turn envelope instead of markdown role headings
• Changed RPC, RPC-UI, and ACP hosts to default the advisor settings off instead of inheriting a user's interactive-session advisor preference.

Fixed

• Fixed advisor backlog tracking so failed advice prompts do not stall catch-up indefinitely by dropping pending backlog after repeated consecutive failures
• Fixed backlog accounting to decrement only after successful advisor prompts so sync waits correctly reflect advisor progress
• Fixed advisor context batching to still send pending review updates when context maintenance fails instead of dropping the batch
• Fixed explicit advisor enablement to clear protocol-default overrides so enabling the advisor applies immediately
• Fixed advisor message card notes getting truncated to two lines when the card is collapsed.
• Fixed advisor context handling to maintain its token budget by promoting or compacting/restarting advisor context while preserving advisor reasoning-off settings.
• Fixed startup.quiet leaving MCP and LSP startup status events visible during launch (#2639).
• Registered the Advisor group in the model settings tab so advisor settings render correctly in the settings panel.
• Fixed Windows bash path handling so MSYS/Git-Bash drive aliases like /d/project and WSL-style /mnt/d/project normalize to native drive paths consistently across the bash tool cwd validation and brush filesystem builtins (#2634).

What's Changed

• fix: align tool cache paths with XDG dirs by @Parsifa1 in #2637
• fix(coding-agent): respect startup.quiet for startup statuses by @roboomp in #2640

Full Changelog: v15.13.3...v16.0.0

Nvidias Profi-Grafikkarte RTX Pro 6000 Blackwell mit 96 GB VRAM kostet auf dem Marketplace des Herstellers jetzt 55 Prozent mehr als zur Ankündigung vor über einem Jahr: 13.250 US-Dollar. Unterdessen ist aber auch der Preis von Nvidias Consumer-Flaggschiff, der GeForce RTX 5090, wieder weit entfernt von dem Tal im Sommer 2025.

Added

• Added the interruptible tool field: when set, the agent loop may abort the tool mid-execution to deliver a queued steering message (honored only in immediate interrupt mode).
• Added support for gemini and gemma as valid owned tool syntax values in environment configuration

Fixed

• Fixed pruneToolOutputs blanking tiny tool results during overflow pruning: results below 50 tokens (MIN_PRUNE_TOKENS) are no longer replaced with the [Output truncated - N tokens] placeholder, which cost more tokens than the result itself and churned the prompt cache for zero savings.

@oh-my-pi/pi-ai

Added

• Added the gemini in-band tool-call syntax with Python-style tool_code blocks and default_api invocations
• Added the gemma token-delimited in-band tool-call syntax using <|tool_call> and <|tool_response> blocks
• Added gemini and gemma to owned stream tool-result token detection so their tool responses are recognized
• Fixed truncated Gemini and Gemma tool blocks from being emitted as plain text during streaming
• Added the Azure OpenAI provider definition (azure) to the registry; AZURE_OPENAI_API_KEY resolves as its env-var API key via the catalog provider table.

Changed

• Gemini tool-call examples now render without the default_api. namespace prefix, keeping <example> blocks concise. The live wire format still uses default_api. per the Gemini grammar.

Fixed

• Fixed duplicate tool call projections by deduplicating provider-native toolCall events against in-band tool_code calls and keeping only the first real channel
• Dropped nameless native toolCall events so they no longer appear as surfaced tool calls in owned-mode streams
• Fixed Gemini/Gemma in-band tool-call parsing around Python comments, raw/unicode string literals, and Gemma close-token text inside string values.

@oh-my-pi/pi-catalog

Added

• Added Azure OpenAI as a catalog provider (azure, default model gpt-5.5, env var AZURE_OPENAI_API_KEY), bundling the OpenAI-family models Azure serves over the Responses API (GPT-4/4.1/4o, GPT-5 family, o-series, Codex). Like Amazon Bedrock it is catalog-only — models ship in the bundle and become selectable once the env key is set, with the deployment base URL resolved at runtime from AZURE_OPENAI_BASE_URL/AZURE_OPENAI_RESOURCE_NAME.
• Added models.dev-backed bundled catalogs for providers that previously shipped no offline models: Hugging Face, Kilo, Moonshot, NanoGPT, Synthetic, Venice, Ollama Cloud, and the Xiaomi Token Plan regions (ams/cn/sgp). They still discover live when credentialed; the bundle is now a non-empty baseline.

Changed

• Updated stale provider default models to their latest bundled versions: OpenAI-family providers (azure, github-copilot, aimlapi) → GPT-5.5; Gemini providers (google, google-gemini-cli, google-vertex) → gemini-3.1-pro-preview; GLM providers (zai, zhipu-coding-plan) → glm-5.2, cerebras → zai-glm-4.7; Kimi providers (fireworks, opencode-go, moonshot) → kimi-k2.7-code, kimi-code → kimi-for-coding, together → moonshotai/Kimi-K2.7-Code; alibaba-coding-plan → qwen3.7-plus; and Claude-Sonnet defaults (cloudflare-ai-gateway, cursor, gitlab-duo, kilo, opencode-zen, vercel-ai-gateway) → Claude Opus 4.x.
• Restricted models.dev Azure discovery to OpenAI-family IDs (gpt-, o1, o3, o4, codex, chatgpt), excluding Foundry-hosted third parties (Claude/DeepSeek/Llama/Mistral/Phi) that Azure serves through non-Responses APIs.
• Detected the Azure OpenAI Responses compat surface (developer role, strict tool mode, strict tool-result pairing) by provider id as well as base URL, so bundled azure models whose deployment host is only known at runtime still get the right wire behavior.
• Renamed the Qwen3-ASR-Flash model label to Qwen3 ASR Flash

Fixed

• Fixed tool syntax selection for Gemini-family and Gemma model IDs by routing them to dedicated gemini and gemma formats instead of generic XML
• Fixed zhipu-coding-plan and together shipping no bundled models: their descriptors referenced non-existent models.dev keys (zhipu-coding-plan, together); pointed them at the real keys (zhipuai-coding-plan, togetherai) so they bundle their GLM and full catalogs respectively.
• Folded the azure-openai-responses API into the OpenAI Responses thinking-inference branches so Azure reasoning models (o-series, GPT-5, Codex) resolve the discrete effort vocabulary (including xhigh) and effort-control mode instead of falling through to generic defaults.
• Fixed ollama-cloud discovery inheriting an unsafe cross-provider contextWindow/maxTokens when /api/show returns no size metadata; it now falls back to the safe 128K context / 8K output caps.
• Dropped internal Fireworks control-plane resource ids (accounts/fireworks/{models,routers}/…) from the bundle; only the public request ids ship.

@oh-my-pi/pi-coding-agent

Added

• Unexpected stop detection: optional tiny/smol classifier that continues the turn when the assistant says it will act but emits no tool calls.
• Settings features.unexpectedStopDetection and providers.unexpectedStopModel.

Changed

• Changed the job poll to return early when a steering message is queued, draining the steer immediately instead of waiting out the poll window.
• Capped unexpected-stop auto-continuation to three retry attempts before giving up on repeated stops
• Updated the edit tool's hashline prompt, grammar, and docs to recommend the .= inclusive range separator (SWAP 1.=3:); the legacy .. form still parses.
• Normalized all internal worker argv selectors under the __omp_worker_ prefix, skipping the async worker dispatch check during normal CLI startup.

Fixed

• Filtered out whitespace-only and dot-only (. or …) assistant blocks so they are treated as empty and no longer appear as visible content in message rendering, streaming reveal counts, or session export output
• Filtered placeholder-only thinking content from ACP notifications and message visibility checks so dot-only reasoning_content no longer triggers turn completion or read/run updates
• Fixed ModelRegistry tests making outbound network calls by automatically stubbing fetch during test execution.
• Fixed eval JS cells (and browser-tab worker startup) always stalling for the full init timeout — typically the cell's whole 30s budget — before silently falling back to the slower inline worker. The self-dispatching CLI host imports the worker module dynamically from its argv dispatch, so the worker's own parentPort.on("message") attached only after Bun flushed the messages the parent posted before spawn; the synchronously-posted init handshake was dropped and never answered with ready. The host now installs a buffering parentPort inbox synchronously in the entry's sync prefix (before importing the worker module) and the worker binds it on load, replaying the buffered handshake. omp --smoke-test now also spawns the JS eval worker through the host entry and asserts it handshakes on a real worker thread.
• Fixed pre-prompt context-full compaction on OpenAI Responses sessions to use provider-anchored context usage when available, so large encrypted reasoning signatures no longer trigger automatic maintenance while the visible context percentage remains below threshold (#2628).

@oh-my-pi/collab-web

Fixed

• Wrapped composer button labels to display icon-only on mobile devices for a more compact and readable layout
• Made the connect screen, ended session card, and notification toasts fully responsive for smaller device viewports
• Fixed mobile layout issues where the entire chat flow would overflow horizontally and text was rendered too large on iOS Safari (by setting text-size-adjust: 100%)
• Made transcript rows stack vertically on small screens to optimize reading space, and prevented grid track expansion
• Hid non-essential metadata (such as the model name, thinking level, and working directory path) and context gauge tracks on mobile headers to prevent overflow

@oh-my-pi/hashline

Changed

• Changed the recommended hashline range separator from .. to .= (e.g. SWAP 1.=3:, DEL 4.=5) so the inclusive <=-style end is self-evident. HL_RANGE_SEP is now .=; the prompt, grammar, error messages, and emitted headers all use it. The lenient parser still accepts the legacy .. (and -/…/space) forms.

@oh-my-pi/omp-stats

Changed

• Renamed __omp_stats_sync_worker to __omp_worker_stats_sync.

@oh-my-pi/pi-utils

Added

• Added installWorkerInbox(port) / consumeWorkerInbox() to @oh-my-pi/pi-utils/worker-host. A self-dispatching CLI host that imports a Bun worker module dynamically attaches the worker's real message listener after Bun flushes the messages the parent posted before spawn, dropping a synchronously-posted init. The host installs this buffering inbox synchronously in the entry's sync prefix so a listener exists at flush time; the worker module consumes it and binds the real handler, replaying anything buffered.

Full Changelog: v15.13.2...v15.13.3

Pull Request resolved: #178466
Approved by: https://github.com/jansel

Fixed

• Fixed remote compaction input trimming to use unlimited context when model.contextWindow is unset

@oh-my-pi/pi-ai

Added

• Added GITLAB_CLIENT_ID and GITLAB_REDIRECT_URI env-var overrides for the GitLab Duo OAuth login flow so users running with their own GitLab OAuth application can replace the bundled credentials when GitLab rejects the bundled client_id's redirect URI. Setting GITLAB_REDIRECT_URI also disables the random-port fallback (strict OAuth providers reject mismatched URIs anyway). (#2424)
• Added AuthStorage.listStoredCredentials() and AuthStorage.removeCredential() for per-account credential management.

Changed

• Replaced the OpenAI SDK client usage in openai-completions, openai-responses, azure-openai-responses, and openai-codex-responses with the new internal postOpenAIStream OpenAI-wire JSON/SSE transport

Fixed

• Fixed streaming providers to cancel upstream model requests when the client closes the response body, so interrupted SSE sessions stop instead of continuing in the background
• Fixed: provider request builders treat unknown model.maxTokens (null) as "no model cap" instead of coercing to 0 via Math.min; Anthropic falls back to the 64k Claude-Code cap for its required max_tokens.
• Fixed transient stream failures on OpenAI-compatible providers by retrying HTTP 408/429/5xx responses and transient network errors with Retry-After/quota-hint aware backoff
• Fixed SSE stream handling for OpenAI-compatible responses by parsing wire-level JSON frames directly and honoring [DONE] termination
• Fixed stream error handling for OpenAI-compatible providers by preserving structured HTTP status/headers and response body details from failed requests for retry and strict-tool fallback logic
• Fixed OpenAI-compat streams ending with a bare finish_reason: "error" (gateways like OpenRouter reporting upstream failures, e.g. Gemini MALFORMED_FUNCTION_CALL) surfacing as a non-retryable Provider finish_reason: error. The reason is now mapped to Provider returned error finish_reason, which the session retry classifier recognizes as transient, so the turn auto-retries instead of stopping with a pinned error banner.
• Fixed SqliteAuthCredentialStore.open() crashing with SQLITE_BUSY_RECOVERY (errno 261) when several omp --session panes restore concurrently after an unclean shutdown: PRAGMA busy_timeout = 5000 now runs as a standalone statement BEFORE PRAGMA journal_mode=WAL (the first lock-taking statement during WAL recovery), and open() retries the BUSY family — SQLITE_BUSY, SQLITE_BUSY_RECOVERY, SQLITE_BUSY_SNAPSHOT, SQLITE_BUSY_TIMEOUT — with bounded exponential backoff. The exhausted-retry error message includes the DB path. Exported isSqliteBusyError(err) for callers that need the same classifier (#2421).
• Fixed MiniMax-M3 OpenAI-compatible streams rendering reasoning twice when the same chunk carried both <think>…</think> content and structured reasoning_content; structured reasoning now wins and cumulative MiniMax reasoning snapshots are collapsed to deltas. (#2433)
• Fixed Gemini turns silently halting the agent when the model returned finishReason: STOP with only an empty (or whitespace-only) text part and no tool call — the well-known "empty response" failure. All Google surfaces (public Generative Language streamGoogle, Vertex streamGoogleVertex, and Cloud Code Assist google-gemini-cli/google-antigravity) now classify such a turn as empty via the shared hasMeaningfulGoogleContent check and retry it up to MAX_EMPTY_STREAM_RETRIES times before surfacing an error. The Cloud Code Assist path previously had an empty-stream retry that never fired for this case (its hasContent flag counted an empty-string text part as content), and the public/Vertex path had no retry at all; the retry now emits a single start event so no duplicate partial message leaks downstream.

@oh-my-pi/pi-catalog

Added

• Added bundled Fireworks models deepseek-v4-flash, kimi-k2.7-code, minimax-m2.5, minimax-m3, nemotron-3-ultra-nvfp4, qwen3.6-plus, and qwen3.7-plus
• Changed

Changed

• Model contextWindow/maxTokens are now number | null; discovery emits null when a provider reports no limit, replacing the 222222/8888 (UNK_CONTEXT_WINDOW/UNK_MAX_TOKENS) sentinels (now removed). Bundled models.json unknown limits are null.
• Changed the github-copilot model context window to 524288 tokens
• Changed Fireworks model discovery to source the control-plane List Models API (GET /v1/accounts/fireworks/models?filter=supports_serverless=true) instead of the OpenAI-compatible /v1/models inference listing. The inference endpoint returns a sparse, account-specific subset that omits on-demand serverless models (e.g. kimi-k2.7-code), so newly published serverless models stayed invisible in the picker until hand-added to the bundled catalog. The control-plane catalog enumerates every serverless model with capability metadata (supportsServerless/supportsTools/supportsImageInput/contextLength/displayName), paginated and filtered to tool-capable READY entries, then merged with bundled/models.dev references — the Kimi K2 max-output clamp and DeepSeek V4 thinking-toggle strip are preserved, and unbundled models default to reasoning so buildModel derives the Fireworks effort map. New serverless releases now surface automatically with no catalog edits.

Fixed

• Filled missing contextWindow and maxTokens in generated models.json for proxy/reseller variants by inheriting limits from canonical-family and segment-reference models
• Ignored zero-cost x-ai subscription entries as reference sources when backfilling limits so inflated values are not propagated
• Fixed the model cache opening with PRAGMA journal_mode=WAL before PRAGMA busy_timeout, so concurrent omp startups could crash inside getDb() on SQLITE_BUSY during WAL recovery instead of waiting through the transient lock. The busy handler is now installed before the first lock-taking statement (#2421).

@oh-my-pi/pi-coding-agent

Breaking Changes

• Removed the top-level --list-models flag path and migrated model listing to the new omp models command

Added

• Added omp models command to list and manage models with ls, find, canonical, and refresh actions
• Added --json output plus -e/--extension, --no-extensions, and --config controls to omp models listings
• Added skills.enableAgentsUser and skills.enableAgentsProject settings (default on) so the canonical OMP-native ~/.agent[s]/skills and project-walkup .agent[s]/skills are configurable independently from the third-party Claude/Codex/Pi toggles.

Changed

• Model registry merge and omp models / model picker handle unknown context/output limits (null) — unknown limits render as - instead of a fake 222K/8.9K.
• Changed omp models to use cached provider data by default and require omp models refresh for a forced online re-fetch
• Updated model-resolution errors to point to omp models when a provider or model is not found
• Upgraded workspace catalog packages to their latest versions as of 3 days ago, and refactored the ACP agent implementation to be compatible with @agentclientprotocol/sdk version 0.25.0.
• Made the zod version requirement in the workspace catalog more tolerant (^4.0.0 instead of 4.4.3), and aligned type definitions in coding-agent extensibility modules.
• Changed /logout to pick a stored account after the provider, so multi-account OAuth providers can remove one credential without logging out every account.
• Changed the status-line context% to report the provider's real prompt-token count — anchored on the last assistant response, matching the /context panel and the collab host broadcast — instead of an independent cl100k estimate of the whole conversation. The estimate could read several points high and climb past 100% on subscription/Codex models (whose advertised window, e.g. 272K, is already the input budget after reserving max output) while the request was still well within the real limit. Right after compaction the segment now shows ? until the next response re-establishes the true count, and the redundant per-message estimate cache was dropped in favor of memoizing getContextUsage().

Fixed

• Fixed ACP thinking-delta mapping to tolerate live chunks that only carry delta text.
• Fixed image input to Ollama (local ollama, ollama-cloud, and any ollama-chat model) failing with an opaque HTTP 400 when an attached image was encoded as WebP. Ollama decodes images through llama.cpp / stb_image, which is built without WebP support, so the resize pipeline now auto-excludes WebP for those models — the automatic equivalent of OMP_NO_WEBP=1, applied across every image path (@file mentions and prompt/paste/CLI attachments, the read/inspect_image tools, eval display images, fetched images, and browser screenshots). Other providers are unaffected and still honor OMP_NO_WEBP.
• Fixed queued steering/follow-up display to derive from the agent-core queue, so queued chips clear when the core dequeues them and no longer strand after empty-Enter aborts.
• Fixed model auth gateway probing to avoid skipping candidates with unknown maxTokens limits (null)
• Fixed model listings so providers registered via extensions are now included from -e and configured extensions sources
• Fixed /mcp reauth, /mcp test, and /mcp unauth to find and operate on MCP servers reported by /mcp list even when they are only runtime-discovered and not stored in writable config, including namespaced plugin servers like cloudflare:cloudflare-api
• Fixed MCP server name validation so colon-namespaced server IDs are accepted when persisting reauth overrides so namespaced OAuth MCP servers can be stored in user config as server:subserver entries
• Retried assistant turns that stop with reasoning/thinking only and no final text or tool call, so Gemini/Antigravity thought-only STOP responses continue instead of silently ending the session.
• Fixed ~/.agent[s]/skills not appearing as /skill:<name> commands when every named source toggle (skills.enableCodexUser, skills.enableClaudeUser, skills.enableClaudeProject, skills.enablePiUser, skills.enablePiProject) was off: loadSkills gated the agents provider on anyBuiltInSkillSourceEnabled, so a user who turned off the Claude/Codex/Pi sources to clean noise also lost their own canonical OMP-native skills. The agents provider now reads the dedicated enableAgentsUser/enableAgentsProject toggles, decoupled from the third-party fall-through (#2401).
• Fixed Windows PowerShell image paste so Ctrl+V can fall back to the PowerShell clipboard bridge when the native clipboard reader reports no image (#2429).
• Fixed misaligned box borders in Mermaid ASCII rendering for CJK (Korean/Japanese/Chinese) and emoji labels — affects both fenced mermaid code blocks in assistant messages and the render_mermaid tool. beautiful-mermaid@1.1.3 measures label width in UTF-16 code units while terminals render East Asian characters 2 columns wide; a patchedDependencies entry rebuilds its ASCII renderer to measure terminal display columns (grapheme-cluster aware, wcwidth-style policy). The patch mirrors the upstream PR (lukilabs/beautiful-mermaid#128) and should be dropped once it ships in a release.
• Fixed interrupt loader state getting stuck after queued-message aborts by removing the session-layer flush/latch path; empty Enter now aborts the active turn and lets the existing post-unwind queue drain resume normally.
• Fixed /goal <objective> and /goal set <objective> during streaming so goal context is steered immediately but objective submission waits for the active turn to finish instead of spamming AgentBusyError (#2454).
• Fixed concurrent omp --session startups (e.g. cmux pane restore after an unclean shutdown) crashing with SQLITE_BUSY_RECOVERY while the agent SQLite databases were still under WAL recovery. The auth credential store and AgentStorage.open() retry the SQLITE_BUSY family with bounded backoff, and every shared SQLite open path (AgentStorage, history, autoresearch, memories, github cache, auto-QA grievances, catalog model cache, stats) now installs the busy handler before the first lock-taking statement so transient WAL recovery contention waits instead of crashing (#2421).
• Mnemopi per-project / per-project-tagged bank derivation is now stable for one cwd, ignoring the surrounding git layout. Previously the bank id was hashed from git.repo.resolveSync(cwd)?.repoRoot ?? path.resolve(cwd), so adding or removing a .git anywhere above the working directory silently repointed the same conversation to a new bank and stranded its memories (e.g. /home/x/projects/repo flipping between projects-… and repo-…). The derivation in packages/coding-agent/src/mnemopi/config.ts now hashes path.resolve(cwd) directly, and session startup widens the recall set with any sibling bank under <dbDir>/banks/ whose working_memory rows already carry the active cwd in metadata_json.$.cwd, so memories stranded by the old, less-stable derivation become visible again on the next session without manual migration (#2412).
• Fixed model switching (Ctrl+P role cycling and the alt+p / /switch / /models selector) intermittently freezing the UI for several seconds. AgentSession.setModel/setModelTemporary ran an eager await modelRegistry.getApiKey(model) purely as an existence pre-flight and discarded the value — but getApiKey does real work: it synchronously executes command-backed key programs (apiKey: "!cmd", execSync with a 10s timeout, blocking the event loop) and refreshes OAuth tokens over the network when one crosses the expiry window (the "fine for a few switches, then a multi-second stall" symptom). Switching now uses the synchronous, side-effect-free ModelRegistry.hasConfiguredAuth check; the concrete key (command execution + OAuth refresh) is still resolved lazily per request via the existing resolver, so an unconfigured provider still fails fast with No API key while a healthy switch never touches the network or spawns a subprocess. hasConfiguredAuth no longer runs the command program or refreshes tokens either, matching its documented "probe without resolving an API key" contract.
• Fixed session resume (pi -c / --continue / --session) hanging for ~10s at startup — surfaced by the watchdog as Still starting … phase: createAgentSession > restoreSessionModel — when an OAuth token needed refreshing or the auth broker (OMP_AUTH_BROKER_URL) was unreachable. Picking which saved model to restore is a pure selection that only needs to know whether auth is configured, but restoreSessionModel probed each candidate with the async getApiKey, which refreshes OAuth tokens over the network, executes command-backed key programs, and issues auth-broker requests — so a slow or unreachable endpoint stalled resume for the full refresh timeout per candidate. Startup model selection now uses the synchronous, side-effect-free ModelRegistry.hasConfiguredAuth probe (the same fix already applied to interactive model switching); the concrete key is still resolved lazily on the first request via the resolver.

@oh-my-pi/collab-web

Fixed

• Fixed context usage percentage calculations to return null when context window is missing or non-positive, preventing invalid or Infinity/NaN usage display

@oh-my-pi/pi-mnemopi

Fixed

• Fixed consolidateToEpisodic (the function backing sleep / sleepAllSessions) never populating the episodic graph: the gists and graph_edges tables stayed at 0 rows across every bank even after multiple consolidation cycles, so Polyphonic Recall's graph voice (BFS over findGistsByParticipant / findRelatedMemories) always returned nothing. Consolidation now best-effort ingests the new episodic memory into EpisodicGraph so the gist row, gist→memory ctx edge, fact edges, and cross-memory similarity/entity/temporal edges land alongside the episodic row. Independent of the existing MNEMOPI_PROACTIVE_LINKING flag, which still gates the same enrichment on the remember() write path. (#2435)

@oh-my-pi/pi-natives

Fixed

• Fixed native shell execution rejecting quoted heredocs whose closing delimiter is the final line without a trailing newline, matching bash paste-run snippets.

@oh-my-pi/omp-stats

Fixed

• Fixed the stats dashboard's SQLite init never setting PRAGMA busy_timeout, so a concurrent omp startup hitting WAL recovery could crash initDb() with SQLITE_BUSY instead of waiting through it. The busy handler is now installed before PRAGMA journal_mode=WAL (#2421).

@oh-my-pi/pi-tui

Added

• PI_FORCE_HYPERLINKS=1 / PI_NO_HYPERLINKS=1 env overrides for the OSC 8 hyperlink capability, mirroring the PI_FORCE_SYNC_OUTPUT/PI_NO_SYNC_OUTPUT shape (opt-out beats force-on).

Changed

• Auto-enable OSC 8 hyperlinks inside tmux when tmux self-reports >= 3.4 via TERM_PROGRAM_VERSION; tmux 3.4 stores OSC 8 as a cell attribute and forwards it to outer terminals whose terminal-features include hyperlinks. Older tmux, GNU screen, and tmux without a reported version still default off. Resolution is factored into hyperlinksUserOverride() and shouldEnableHyperlinksByDefault() mirroring the sync-output helpers (#2403).

@oh-my-pi/pi-utils

Fixed

• Fixed abortable stream wrappers to cancel the source stream on abort, so timeout watchdogs release upstream HTTP bodies instead of only stopping the local reader.

@oh-my-pi/pi-wire

Changed

• Changed WireModel.contextWindow and ContextUsage.contextWindow to number | null to allow representing unavailable context-window values

What's Changed

• fix(tui): respect OSC 8 hyperlinks under tmux >= 3.4 by @roboomp in #2404
• fix(skills): load ~/.agents/skills even when third-party source toggles are off by @roboomp in #2405
• fix(coding-agent): stabilize mnemopi per-project bank derivation (#2412) by @roboomp in #2414
• fix(auth): retried SQLITE_BUSY family and hoisted busy_timeout by @roboomp in #2423
• fix(ai): added GITLAB_CLIENT_ID and GITLAB_REDIRECT_URI overrides for gitlab-duo OAuth by @roboomp in #2425
• fix(coding-agent): restore Windows image paste fallback by @roboomp in #2430
• fix(ai): deduplicate MiniMax reasoning stream by @roboomp in #2434
• fix(mnemopi): populated gists and graph_edges during consolidation by @roboomp in #2439
• fix: align Mermaid ASCII box borders for CJK/emoji labels by @chan1103 in #2442
• docs: document project settings and disabledProviders by @roboomp in #2448
• fix(cli): defer goal objectives while streaming by @roboomp in #2455

Full Changelog: v15.12.3...v15.12.4