I've been researching local models lately and considering setting up a machine at the company as a backup. The reason is simple: I'm incredibly reliant on AI for coding and product development. If subscriptions or the API suddenly stopped working, a lot of work could be ground to a halt. So now, when I look at AI, I start thinking about it from a deeper level: Where does the computing power behind the model come from? Where can the work run? Are there other deployment options? When developing multi-agent tools like TermHive, and previously when creating content generation tools, I've been dealing with how different tools and services connect. For example, in the content generation workflow, I added routing for multiple services and CLI fallbacks to allow the workflow to take alternative paths. When developing these things, I start to pay attention to whether the entire process can run continuously and how much model power each step requires. The capabilities required to understand a report or handle complex programming problems are vastly different from those needed to "categorize this data," "find relevant documents," and "determine the next step." Therefore, I think recent advancements in small-scale models and device-level AI are worth watching. Google's EmbeddingGemma 2, released on October 6th, has a full model with 740M parameters. It can convert text, images, and audio into vectors for semantic search and retrieval. For text processing alone, a 270M module is sufficient, aiming to enable these tasks to be performed on devices. Liquid AI also released d1-3B and the experimental d1-omni-600M on October 7th. These use a decision model: a single forward pass output selection, specifically designed for tasks like classification and intent determination. Seeing these advancements makes me wonder: how many steps in an agent's workflow can be broken down and handled by a lighter model? If a model can perform a well-defined task, then the equipment, costs, and methods required for its deployment can potentially change. This is also what I found interesting about @Acurast. It connects geographically dispersed mobile phones into a computing network. Developers submit tasks, and a Matcher matches task requirements with available resources, handing over the actual computation to the mobile nodes for execution. However, simply having computing power isn't enough to delegate work to other people's mobile phones; the device's status also needs to be verifiable. Acurast uses hardware authentication mechanisms like Android Key Attestation and iPhone App Attestation to check the status of devices and apps, and continuously excludes nodes whose certifications have been revoked. I believe task scheduling, device verification, and deployment tools are key to whether mobile computing power can be transformed into a service. Its development documentation already includes deployment examples of the GGUF model, demonstrating how to start an LLM service on a mobile node and providing an API compatible with OpenAI's style. From my perspective as someone who develops agent tools, this provides a starting point for exploring how to integrate it into existing processes. If I were choosing the first batch of test tasks, I would first look for tasks that can be executed independently, have a small data transfer volume, and don't have very high real-time requirements. For example, public data classification, batch text processing, and periodically generating simple summaries. First, confirm that the model can handle these tasks well, then measure the time from sending out the task to receiving the result, as well as the overall cost. Because from a developer's perspective, the ultimate questions will inevitably be: Is deployment troublesome? What happens when nodes are offline? After a failure and retries, is the time and cost worthwhile? Only if these questions can be answered will I consider adding more work. The Acurast mainnet launched in January of this year, and the official cumulative connected scale currently exceeds 330,000 mobile phones. ACU participates in deployment costs, computing power rewards, staking, and governance, and is part of the network's operation. What I will focus on next is what actual work these devices can handle, and whether developers will continue to use them after initial use. My assessment is that as more small models can perform specific tasks well, the amount of AI work that devices like smartphones can participate in will increase. For Acurast, organizing these capabilities into easily deployable and stably running services presents a worthwhile opportunity. Previously, the old phones in drawers were probably just backup devices. Now, at least there's another direction worth exploring: can they become a continuously functioning node in an AI workflow? Those working on AI, agents, or following DePIN should check out Acurast and ACU. Always DYOR.