How JBlanked Connects Flipper Zero, Cardputer, and PicoCalc to Local AI with ZimaBoard 2

Thank you to JBlanked for documenting a different way to bring local AI into embedded-device development. In his full video, he turns ZimaBoard 2 into a local Ollama server and connects handheld devices including Cardputer-ADV, PicoCalc, and Flipper Zero to that shared AI environment.

Instead of trying to run a large language model directly on every small device, the experiment separates the workload: ZimaBoard 2 handles the local AI service, while the handhelds act as lightweight development interfaces. JBlanked then uses his open-source Picoware Agent to create applications, inspect device information, and manage hardware through that local AI connection.

Collaboration disclosure: This article is based on the setup demonstrated by JBlanked and the public documentation for Picoware and FlipperHTTP. Software versions, AI model availability, hardware compatibility, and local inference performance may change over time.

The result: one compact home server can provide the AI layer for several resource-constrained maker devices. The handheld hardware still runs its own firmware and interface, while computationally heavier language-model tasks can be handled by Ollama on the local server.

The Local AI Setup at a Glance

The project combines a compact x86 server with several embedded platforms. Rather than forcing the same software stack onto every device, JBlanked uses different connection layers depending on what each device supports.

Why Use ZimaBoard 2 as the AI Server?

The interesting part of this project is not simply that ZimaBoard 2 can run an AI application. It is the way the board changes the architecture of small embedded projects.

Devices such as Cardputer, PicoCalc, and Flipper Zero are designed around portability and specialized embedded hardware. They are useful for interfaces, scripts, firmware experiments, network tools, and portable applications, but their onboard resources are far more limited than those of a conventional AI workstation.

The ZimaBoard 2 Mini Home Server provides a separate x86 host with wired networking, storage connectivity, and PCIe expansion. That makes it possible to keep the handheld devices small while moving the heavier server workload elsewhere.

In JBlanked's workflow, ZimaBoard 2 runs ZimaOS and Ollama provides the local language-model service. Once that service is available on the local network, compatible devices can communicate with it without each handheld needing enough compute and memory to host the model itself.

The video also shows an important detail about the demonstrated server configuration: while Ollama is running, the ZimaOS system dashboard reports an NVIDIA GeForce RTX 3060 with 12GB of VRAM. That means the performance shown in the demo should be understood in the context of a GPU-equipped local server rather than as a CPU-only ZimaBoard 2 test.

Ollama running inside the ZimaOS environment. The system dashboard visible behind it reports an NVIDIA GeForce RTX 3060 and 12GB of VRAM, showing that the demonstrated local AI server has GPU acceleration available.

How the Local AI Connection Works

The basic design can be understood as three layers:

• Server layer: ZimaBoard 2 runs ZimaOS and hosts Ollama.
• Agent or networking layer: Picoware or the Flipper networking stack sends requests between the embedded device and the local server.
• Device layer: Cardputer-ADV, PicoCalc, or Flipper Zero provides the physical interface and executes device-specific actions.

This separation is useful because the language model does not need to run directly on every piece of hardware. The firmware on each device can expose the functions it supports, while the server provides the model capability used to interpret requests or assist with development tasks.

Cardputer-ADV and PicoCalc Use Picoware Agent

JBlanked's Picoware project is an open-source firmware environment supporting Cardputer-ADV, PicoCalc, Flipper Zero, and other ESP32 or Raspberry Pi Pico-based devices.

For this experiment, the important component is Picoware Agent. The Agent provides an LLM-powered interface with different operating contexts instead of acting only as a generic chat window.

Its documented modes include general chat, an App Creator designed to create or edit Picoware applications, and device-management functions that can work with information and commands. Connecting those capabilities to the Ollama instance on the local server gives the handheld an AI-assisted development workflow while keeping the model workload off the small device.

Flipper Zero Sends Requests to the Local AI Server

The Flipper Zero follows a different interaction pattern. In the video, JBlanked demonstrates the device preparing a structured request payload for the local model through a Wi-Fi-capable development board attached to the Flipper.

The payload shown on screen includes a model field for qwen3.5:9b. This illustrates the division of responsibilities clearly: the Flipper prepares and sends the request, while the selected language model runs on the more capable local server.

Flipper Zero preparing a request payload for the local AI service. The screen shows the model field set to qwen3.5:9b, while a Wi-Fi-capable development board is attached above the device.

This distinction matters. The Flipper is not running the full language model locally. Its role is to provide the portable interface and networking path, while Ollama and the selected model execute on the server.

What Can the Local AI Agent Actually Do?

Connecting a handheld device to an LLM becomes more interesting when the model can do more than answer a question. JBlanked demonstrates the AI server as part of an embedded-development workflow.

Create Picoware Apps

Picoware includes an App Creator context for its AI Agent. This allows a developer to describe an application or change in natural language and use the model to help produce or edit the corresponding Picoware application.

In the demonstration, the App Creator is asked to build a simple application that displays the greeting “hello from youtube” when launched. The Agent returns a structured description of the requested behavior and how the interface should work.

Picoware's App Creator running on PicoCalc. The Agent is working through a request for an application that displays “hello from youtube,” while Flipper Zero and Cardputer-ADV sit alongside the device.

That can shorten the distance between an idea and a prototype, especially on a device where typing and editing large amounts of source code directly on the small screen would otherwise be cumbersome.

AI-generated code still needs review. An output that looks plausible can contain incorrect APIs, incomplete error handling, unsafe assumptions, or behavior that does not match the target hardware.

Inspect Firmware and Development Information

The Agent workflow can also be used as a development assistant. Instead of treating the handheld as a conventional chat client, the system can combine local model responses with information exposed by the device and its firmware.

This approach is particularly useful on small displays, where manually navigating logs, documentation, or command output can be slower than asking the Agent to interpret a specific request.

Manage the Device

Picoware's Agent framework also includes device-management functions. The model can work through tools exposed by the firmware rather than simply returning text for the user to execute manually.

One example in the video asks, “how many networks are nearby.” The Device Manager responds that six nearby Wi-Fi networks are available, demonstrating that the Agent can use device-level information to answer a practical request rather than relying only on general model knowledge.

Picoware Device Manager on PicoCalc answering the question “how many networks are nearby.” The interface reports six nearby Wi-Fi networks, showing how the Agent can combine local AI with information obtained from the device.

This is where an AI agent becomes different from a normal chatbot. The language model provides the interpretation and instruction layer, while the firmware determines which device operations and information sources are actually available.

Why a Shared Local AI Server Is Useful for Small Devices

The architecture addresses a basic mismatch in embedded AI projects: the most portable devices often have the least compute available for language models.

Using a shared server changes that tradeoff. A developer can keep the physical interface in a pocket-sized device while giving it access to a more capable local machine over the network.

One AI Backend, Multiple Maker Devices

One of the more useful ideas in JBlanked's experiment is that ZimaBoard 2 is not tied to a single front end. PicoCalc and Cardputer-ADV can participate through Picoware, while Flipper Zero can communicate with the same local AI environment through its own networking workflow.

This makes the server a reusable piece of a larger maker lab. Instead of rebuilding an AI environment for every new microcontroller or portable computer, developers can keep the inference service centralized and focus on building the client integration that makes sense for each device.

The concept can also simplify experimentation. A model can be changed on the server without replacing the handheld, while firmware on the handheld can evolve independently from the AI runtime.

What This Experiment Proves—and What It Does Not

JBlanked's build is a useful demonstration of how local AI can fit into embedded development, but it is important to distinguish the architecture from guarantees about performance or security.

Local Does Not Mean Zero Configuration

Running Ollama locally removes the requirement to send every inference request to a hosted chatbot service, but the complete system still needs normal server and network planning.

The initial model and application packages must be installed, the handheld devices need network access to the server, and any exposed service should be configured with the intended network boundaries in mind. Developers should also verify exactly which tools an AI Agent is allowed to call before enabling device-management functionality.

The accelerator configuration matters as well. The RTX 3060 visible in JBlanked's ZimaOS dashboard has 12GB of VRAM, so model choice still has to account for available GPU memory, runtime support, and the performance requirements of the intended workload.

For code-generation use cases, keeping backups or version control is especially important. If an AI-assisted edit produces an unusable application or firmware configuration, the developer needs a known working state to return to.

Who Should Consider a Setup Like This?

This architecture is especially interesting for developers and makers who already work with embedded devices but want to experiment with local LLMs without turning every project into a cloud API integration.

It may be useful for:

• Cardputer and PicoCalc developers building Picoware applications.
• Flipper Zero users experimenting with network-connected tools.
• Embedded developers who want AI assistance close to their test hardware.
• Homelab users looking for another practical workload for a local server.
• Makers who want multiple low-power devices to share one AI backend.

A cloud AI service may still be simpler for users who only need occasional chat or code generation and do not want to maintain a server. A larger workstation or more powerful GPU-equipped system may also be more appropriate when model size and inference speed are the main priorities.

The ZimaBoard 2 approach becomes more compelling when the objective is to keep the AI service inside the same homelab and make that service available to several independent projects.

Build a Local AI Hub for Your Maker Lab

JBlanked's project shows a useful direction for local AI: instead of asking whether every small device can run a language model, ask whether those devices can use a shared model running somewhere better suited to the job.

With ZimaOS hosting Ollama on ZimaBoard 2, Picoware providing an AI-assisted interface for devices such as PicoCalc and Cardputer-ADV, and a network-capable workflow bringing Flipper Zero into the same environment, the system becomes a flexible local AI hub for embedded experimentation.

The four demonstrations also show why the server should be evaluated as a complete system. The handheld devices provide the interfaces and hardware-specific functions, Ollama provides the model-serving layer, and the GPU visible in ZimaOS supplies additional compute resources for the local AI workload.

For another look at what local models can do on the same platform, see the ZimaBoard 2 local AI assistant test, which explores the relationship between compact server hardware, model size, storage, and AI workloads.

Watch JBlanked's complete video to see the setup and device workflow directly, or explore the Picoware project on GitHub if you want to understand how the Agent and supported devices fit together.

Want to see what other builders are doing with compact servers, local AI, and unusual hardware? Join the ZimaSpace Discord community to explore more builds, compare setups, and share your own experiments.