Jasper

A mobile development workstation and AI development agent for Android.

Jasper is a project I’ve been planning around a simple idea:

Your phone should be able to do more.

The goal is to bring a complete development environment to Android, allowing developers to build, run, test, debug, secure and deploy software directly from their phones without needing a traditional PC.

Jasper isn’t meant to be just another AI coding assistant or a mobile code editor. It’s designed to be a complete mobile development workstation with the AI capabilities built directly into the workflow.

The Development Environment

At its core, Jasper provides the tools you’d normally expect from a development environment:

Linux through PRoot
An integrated terminal
PTY support
CodeMirror-powered code editor
File manager and file editor
Git support
Browser-based project previews
Project templates and blank projects
Support for long-running processes
Foreground services and wake locks
ARM64 support

Everything is designed around Android and a mobile-first workflow rather than trying to squeeze a desktop IDE onto a touchscreen.

AI Development Agent

Jasper also includes an AI development agent that works alongside the developer throughout the development process.

It isn’t limited to generating code. Jasper can help with planning, architecture, implementation, debugging, testing, security and deployment.

It supports both local and online models. Local models can run through llama.cpp and GGUF, while online models can come from providers such as Anthropic, OpenAI, DeepSeek and OpenRouter.

Users can also configure custom providers and endpoints.

Jasper isn’t locked to a single model either. It can work with multiple models, fallback chains, model combinations and intelligent routing.

The idea is that users shouldn’t have to think about which model to use for every single task. Jasper can consider the task, its complexity, required capabilities, available models, cost, latency, privacy requirements and device resources when deciding how something should be handled.

Agents and Skills

Jasper can use specialist agents for different areas of development, such as backend, frontend, databases, security, QA and DevOps.

These don’t necessarily require separate models. The same model can take on different specialist roles using different instructions, tools, permissions and context.

Skills work differently.

Skills define how an agent should perform a particular task. Jasper will include built-in skills while allowing users to create, edit, disable, delete and add their own.

This also means useful skills from existing open-source projects can be adapted instead of reinventing everything.

MCP and Integrations

Jasper supports MCP for connecting external tools and services.

Users can add and manage their own MCPs, while Composio can make connecting everyday applications and services easier through a simple authorization flow.

Custom MCPs will still be supported for tools that aren’t covered by Composio.

The goal is to give users control over what Jasper can access rather than silently connecting everything.

Discuss and Build

Jasper has two primary modes: Discuss and Build.

Discuss is for conversations, brainstorming, planning, architecture and questions. It shouldn’t accidentally modify the user’s project.

Build is where Jasper can actually work on the project, including creating and editing code, running commands, testing, debugging, securing and deploying.

This separation gives the developer a clear boundary between talking about an idea and actually making changes.

Security

Security isn’t intended to be an afterthought.

Jasper can analyze applications for vulnerabilities and loopholes, understand discovered issues, create patches, apply them, test the patches and verify that the problems have been fixed.

There is also a permission and policy layer controlling what agents and tools are allowed to do, with sensitive actions potentially requiring confirmation from the user.

Memory

Jasper uses a unified memory system built around a memory graph.

Instead of constantly sending entire project and conversation histories to the model, Jasper can retrieve the pieces of information that are actually relevant to the current task.

Memory can contain things like user preferences, projects, architecture decisions, development history, skills and relationships between different pieces of information.

Projects can also have their own knowledge containing architecture, conventions, requirements, constraints and important decisions.

The goal is to give Jasper useful context without wasting tokens and resources.

Efficiency

Efficiency is another important part of Jasper.

For code, Jasper takes inspiration from Ponytail to reduce unnecessary code, abstractions and dependencies.

For AI, it takes inspiration from Caveman to reduce unnecessary output and context while preserving important technical information such as commands, paths, errors, warnings and code.

The goal isn’t simply to use less. It’s to avoid wasting resources while keeping the information necessary to get the job done.

Backup

Jasper will use an encrypted .jasp backup format for moving a user’s configuration and development context between devices.

Backups can include memory, settings, skills, MCP configuration, agent configuration, providers, models, credentials, project metadata and optionally project source code.

Large or regenerable data such as node_modules, .git, build files, caches, model binaries and runtime binaries won’t need to be included.

This keeps backups practical while allowing Jasper to restore the important parts of a development environment on another device.

Built on Open Source

Jasper doesn’t need to reinvent every part of its system.

I’m looking at existing open-source projects such as Strix for security workflows, Agency Agents for specialist agents, Ponytail and Caveman for efficiency, and Graphify for the memory graph.

These aren’t necessarily dependencies that Jasper will blindly adopt. They’re foundations and ideas that can be studied, adapted and changed to fit Jasper’s architecture.

The Philosophy

Jasper is being built around a few principles:

Mobile first.
It should feel natural on a phone instead of feeling like a desktop application squeezed onto one.

User control.
Users should control their models, providers, agents, skills, MCPs, tools and permissions.

Local first.
The device should do as much as possible. Cloud services should be options, not requirements for the core development environment.

Simple by default.
Jasper can have a lot happening underneath without forcing the user to understand every internal system.

Open.
Good existing open-source work should be reused and improved where possible.

No unnecessary complexity.
If something can be solved with a small and reliable solution, there is no reason to turn it into a massive system just because we can.

Where Jasper Is Now

Jasper is still in the planning and research stage.

I’m currently defining the architecture, researching existing solutions and figuring out which parts should be built from scratch and which parts can be adapted from existing open-source projects.

The actual implementation will happen incrementally.

The end goal is simple:

A developer should be able to pick up their Android phone, open Jasper, and have everything they need to build software.

No traditional PC required.