TaurusX Engines

TaurusX Engines are the AI model layer — the part of the system that actually generates responses. Rather than exposing raw API access to a specific vendor, TaurusX wraps all AI models behind a unified Engine Abstraction Layer.

This means that when you use TaurusX, you are using a TaurusX engine — not a named external model. The kernel chooses which model to use based on context, plan tier, and message complexity, and that choice is completely transparent to the surface.

The Engine Abstraction Layer (EAL) is the kernel subsystem that manages all AI model calls. Every surface — mobile chat, Continuum, TX Terminal, CLI — routes all AI requests through the EAL. No surface calls a model provider directly.

The EAL provides:

• Model-agnostic interface — one API surface regardless of which model is underneath
• Automatic fallback — if the selected engine is unavailable, the EAL reroutes to the next available engine
• Consistent billing — all engine calls are metered in TaurusX Cycles regardless of underlying model cost
• Plan enforcement — the EAL checks plan tier before dispatching; free users cannot call enterprise engines
• Prompt injection — the EAL injects the active tone, state, and accessibility flags into every prompt automatically

The Routing Engine is the decision layer that sits in front of the EAL. For every incoming message, it determines which TX Engine to invoke based on:

By default, TaurusX selects the best engine for each message automatically. You do not need to choose. However, you can direct the Routing Engine explicitly using an inline directive:

Inline directives are stripped from the message before it reaches the engine. The model never sees the directive — only the cleaned message and the injected system context.

Billing is metered in Cycles — TaurusX's internal unit of AI consumption. Each engine has a different Cycle cost per token. The current Cycle balance is shown in the Continuum dashboard and in the Capability Panel.