Clear tasks first
Start with tasks that can be checked.
The plan would break a request into explicit units that can be reviewed independently.
Roadmap: Fusion Swarm
One request, several models, one reviewed answer.
Fusion Swarm is planned. It would split independently checkable tasks across available models, review their work, and return one response to your app.
Fusion is available when the models needed for the request are online. Fusion Swarm has no public release date.
How work movesRoadmap
01 / plan
Explicit work
Break only independently checkable work into a task
graph.
Research model
Implementation model
Review model
03 / verify
One final answer
A separate model checks the result before it returns.
Planned workflow
Your app sends one request.
TEKIZ.AI would assign the separate tasks, check the results, and return one response. Your route settings would control which models may run each part.
Choose available models
Match each task to an eligible model.
TEKIZ.AI checks health, provider access, capability, cost, speed, concurrency, and local memory limits before assigning work.
Review the result
One model returns the final answer.
One model reviews the work and returns the final response. When possible, it differs from the model that did the original work.
What works today
Use Fusion today. Swarm is planned.
Available with enough model capacity
Fusion
Fusion splits suitable work, selects available models, and checks the result before returning one response through the normal OpenAI-compatible interface.
tekizai/fusionprofile- Optional frontier planner
- Parallel tasks with a final review
- Hosted access only when the status surface reports capacity
Roadmap, no public release date
Fusion Swarm
Swarm adds more detailed planning, specialist roles, extra review, and one final response while keeping the same routing and safety limits.
- Network-wide role selection
- Clear handoffs between models
- Fixed budgets and concurrency limits
- Opt-in Community capacity where it is attested and approved
Route boundaries
Customer approval controls every route.
The planned workflow could use cloud, local, and approved Community capacity. Each model would run within the customer's provider access and the host's limits. Personal subscriptions would stay with their owners.
Customer authorization: work stays within the
provider access and route policy the deployment is authorized to
use.
Local models: an Ollama node can keep an approved
model ready within its memory and concurrency limits.
Community is opt-in: private-alpha Community work
requires the customer's permission, a verified online node, and a
separate model checking the result.
One accountable response: each model contributes
its part; the client receives one reviewed answer with the usual
routing details.
Build with the current system