Daedalus is a local-first AI runtime for running and assembling AI systems on a user's own machine.
The goal is not to build another chatbot or another model. Daedalus is intended to provide the layer between models and the applications, agents, skills, tools, and capabilities that use them.
A user should eventually be able to install Daedalus, connect or install models, install skills, and have the runtime manage the tools and capabilities required to complete tasks.
Status: Early development. Many of the runtime, skill, MCP, marketplace, and desktop concepts described below are planned rather than implemented.
Daedalus is intended to become an operating environment for local AI.
It separates several pieces that are often bundled together:
- Models — the learned intelligence.
- Model providers/runtimes — systems such as Ollama that execute models.
- Skills — instructions and resources that teach an agent how to perform a type of task.
- MCP and tools — capabilities that let an agent interact with external systems.
- Agents/tasks — the runtime logic that combines models, skills, and capabilities to accomplish work.
- Applications — interfaces such as the current Next.js application and the planned desktop application.
Daedalus should manage these pieces without making any single model, provider, framework, or interface the definition of the project.
The intended execution model is:
User
│
▼
Task
│
▼
Daedalus Runtime
│
├── Select / configure model
├── Load relevant skills
├── Resolve required capabilities
├── Start or connect tools / MCP servers
└── Execute the task
│
▼
Result
The long-term goal is for users to think about what they want to accomplish, rather than manually assembling an AI stack every time.
Daedalus is model-independent. Ollama is the first local model runtime integration, not Daedalus itself.
Users should be able to use models available through local runtimes or other providers. Daedalus should eventually understand model capabilities and use that information when deciding how a task can be executed.
A model may eventually describe capabilities such as:
capabilities:
text: true
vision: false
audio: false
tool_calling: true
structured_output: trueCapability metadata describes what a model can support; it does not guarantee quality. A smaller or older model may technically be able to use a tool while being much worse at deciding when or how to use it.
Daedalus should therefore keep model selection separate from skills and tools. A skill should not be permanently tied to one model.
Daedalus intends to follow the established Agent Skills convention rather than replacing it with a completely different format.
A skill primarily describes how to accomplish a task and may contain instructions, references, scripts, and assets.
A conceptual skill package may look like:
my-skill/
├── SKILL.md
├── manifest.json
├── references/
├── scripts/
├── assets/
└── mcp/
SKILL.md remains the primary skill definition.
A major goal is for a skill to be easy to install and use. When a skill needs MCP servers, scripts, or other tools, the package should be able to include or declare those dependencies so Daedalus can resolve them automatically.
The intent is:
Install Skill
│
▼
Read SKILL.md / metadata
│
▼
Resolve dependencies
│
├── MCP servers
├── Tools / scripts
├── Other resources
└── Optional model requirements
│
▼
Configure runtime
│
▼
Skill ready
Packaging capabilities with a skill does not mean that every skill must contain an MCP server. A skill may use MCP, local scripts, other tools, or no external tools at all.
MCP is a capability layer, not a replacement for the skill system.
Daedalus should act as the MCP client/runtime and expose available tools to the agent/model through an appropriate interface. The model itself does not need to implement the MCP protocol.
This separation allows the same skill to work with different models while Daedalus handles the connection between the model, skill, and tools.
Conceptually:
Skill
│
┌────────┴────────┐
│ │
Instructions Capabilities
│ │
│ ┌──────┴──────┐
│ │ │
│ MCP Scripts/Tools
│ │ │
└──────────┴──────┬──────┘
▼
Daedalus
│
Model
Older or weaker models may not be as good at deciding when to use a capability. That is a model-quality problem rather than a reason to make the capability unavailable. Daedalus can eventually provide adapters or structured interfaces for models with different tool-use abilities.
Daedalus should eventually be able to select an appropriate model for a task based on factors such as:
- Required capabilities
- Model availability
- Hardware constraints
- Context requirements
- Expected quality
- Latency
- Local versus hosted execution
The runtime may therefore route different tasks to different models rather than forcing one model to perform everything.
For example:
Task
│
▼
Daedalus
│
┌───────────┼───────────┐
▼ ▼ ▼
Reasoning Vision Coding
│ │ │
Model A Model B Model C
This is a planned capability of the runtime, not a claim that the current implementation already performs automatic model routing.
A long-term goal is to build a marketplace around the Daedalus runtime.
Developers could publish and potentially sell:
- Skills
- Agent workflows
- MCP integrations
- Tools and scripts
- Model configurations
- Model packages where licensing permits
- Other AI capabilities
The important idea is that Daedalus provides the runtime and distribution layer, while developers can create the capabilities that run on top of it.
A marketplace item could conceptually look like:
GitHub Code Review
────────────────────────
Skill: github-code-review
Includes:
✓ Instructions
✓ References
✓ Scripts
✓ MCP dependencies
Compatible models:
✓ Coding models
✓ General reasoning models
[ Install ]
The marketplace is not currently implemented. Licensing, packaging, payments, developer accounts, moderation, and compatibility systems will need to be designed before it becomes a production service.
Daedalus is designed around local AI, but the architecture should not prevent hosted providers from being used when local hardware is insufficient.
The intended provider model is:
Daedalus
│
┌────────────┼────────────┐
│ │ │
Local Hosted Custom
│ │ │
Ollama Provider Provider
Other / API / API
runtimes
Local execution provides privacy, control, and potentially lower marginal inference costs. Hosted providers can provide access to larger or more capable models when appropriate.
The provider should remain an implementation detail of the runtime wherever practical.
Persistent memory is a planned part of Daedalus.
The goal is to make memory:
- Explicit
- Inspectable
- Editable
- Permission-aware
- Separate from the model
- Controlled by the user
Daedalus should not automatically treat every conversation as permanent memory.
Potential operations include:
save_memory
search_memory
update_memory
delete_memory
The exact memory architecture is not finalized.
Daedalus is intended to eventually become a normal downloadable desktop application rather than requiring users to clone the repository and run a development environment.
The current direction is to use Electron around the existing Next.js application:
Next.js application
│
▼
Electron desktop shell
│
▼
Bundled Chromium
│
▼
Daedalus desktop application
The exact production architecture for running Next.js server-side functionality inside the packaged application is still being worked out.
The eventual goal is normal cross-platform distribution through direct installers and appropriate app-store channels.
The current implementation is intentionally much simpler than the long-term vision.
The current application is a Next.js/React/TypeScript application. Ollama is the initial target for local model communication.
Conceptually, the current foundation is:
┌─────────────────────┐
│ Daedalus UI │
│ Next.js │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Daedalus App/API │
│ TypeScript │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Ollama │
│ Local Runtime │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Local Model │
└─────────────────────┘
The repository should continue building this foundation before adding the larger runtime ecosystem.
Daedalus is being developed incrementally.
- [/] Establish reliable local model communication
- Improve model/provider configuration
- [/] Stream model responses
- Establish conversation history
- Build the runtime bootstrap
- Detect local runtime/model availability
- Create a modular provider abstraction
- Implement model metadata/capabilities
- Build the task/agent execution loop
- Implement tool calling
- Integrate MCP
- Implement skill discovery and loading
- Support the standard
SKILL.mdconvention - Allow skills to package/declare their required capabilities
- Build capability and dependency resolution
- Experiment with model routing
- Add filesystem and terminal capabilities
- Add vision and other modality support
- Build user-controlled memory
- Define Daedalus package metadata around the standard Agent Skills convention
- Build skill installation and management
- Build MCP dependency installation/configuration
- Build a model/skill registry
- Explore a marketplace for models and skills
- Establish licensing and compatibility metadata
- Build developer tooling/SDKs
- Build the Electron desktop application
- Make development and production services dynamically select available ports
- Support automatic environment and model detection
- Explore guided setup for required local runtimes
- Support normal desktop distribution
- Integrate Daedalus with development environments
The current application is built with:
- Next.js
- React
- TypeScript
- Tailwind CSS
- Motion
Ollama is the current local AI runtime integration.
Other technologies will be introduced only as they become necessary. The repository should not describe planned technologies as current dependencies.
Daedalus will be developed incrementally rather than attempting to build a fully autonomous system immediately.
The broad progression is:
Local Model
│
▼
Reliable Runtime Connection
│
▼
Chat Interface
│
▼
Conversation Context
│
▼
Memory
│
▼
Tool Calling
│
▼
MCP
│
▼
Skills
│
▼
Capability Resolution
│
▼
Model Routing
│
▼
Agent Runtime
│
▼
Marketplace
Each layer should be validated through working implementations before the next layer becomes a major dependency.
Daedalus and Prometheus are separate projects.
Daedalus focuses on building and experimenting with a practical runtime around existing AI technology: models, providers, skills, tools, memory, and agents.
Prometheus is a separate future project focused on exploring a new AI architecture based on knowledge gained through experimentation.
DAEDALUS
│
▼
Build and study AI systems
│
▼
Experiments
│
▼
Identify limitations
│
▼
PROMETHEUS
│
▼
Explore new architecture
Daedalus does not need to become Prometheus. Its purpose is to provide a practical environment for learning what works and what does not.
Early development.
The current priority is making the local runtime foundation reliable and establishing the architecture that will eventually support models, skills, tools, memory, and agents.
The marketplace, advanced capability resolution, automatic model routing, and desktop distribution are future goals and are not yet fully implemented.
This project is currently experimental. See the repository license for the current licensing terms.