Builder documentation
Build for Glixo Code and Agxos
Glixo modules extend the IDE, the agent, and the Agxos desktop through one catalog pipeline. Every installable package ships a glixo.module.json manifest, a zipped artifact, and optional marketplace assets.
How it works today — and where it's heading
Everything below is the current platform, and it works end to end. There are three ways a module runs:
- Built-in providers (Anthropic, OpenAI, Gemini, Ollama, storage) are native to the host and ship preinstalled as browse-only modules — you never write inference code for them.
- Declarative extensions — providers that bind a built-in adapter, IDE surfaces, themes, template Agxos apps — ship no runtime of their own.
- Executable extensions that need their own backend spawn an out-of-process adapter over stdio.
Direction (in progress, not yet shipped): a next-gen platform that keeps built-in providers native, moves third-party executable extensions to a sandboxed WebAssembly runtime, and leaves declarative extensions runtime-free. Build against the current model — declarative contributions are stable — but treat the out-of-process adapter path as experimental: it's the piece the next version replaces, so don't over-invest in it.
What you can build
See every extension type → — each with a real, copy-pasteable example.
- Providers & adapters — declarative model & storage providers.
- Agent extensions — tools, skills, MCP servers, and run-time context.
- IDE UI surfaces — sidebars, settings panels, commands, routes.
- Agxos apps — windowed desktop apps (template or coded bundle).
- App Maker — describe an app in plain language; the agent scaffolds and publishes it.
- Extend an existing app — fork a catalog app and add features.
Workflow at a glance
- Create or fork a module under
glixo-community-modules/catalog/. - Validate the manifest on glixo.dev or via the API.
- Pack artifacts and sync the catalog for local testing.
- Sign in and publish — marketplace browsing stays public.