What is Acrux Core?

Acrux Core is an LLM-ops platform: one place to manage the prompts your app sends to language models, route those calls through a smart gateway, see exactly what happened on every request, and measure whether changes made things better.

Everything in Acrux Core is team-scoped — you sign up, get a workspace, and invite teammates. You talk to it two ways: the web app (for authoring and inspection) and the REST API + SDK (for your running application).

The five building blocks

Acrux Core is built from five pieces that each stand on their own but are designed to snap together.

Block	What it does
Prompts	Versioned, templated message sets. Move a production alias between versions without redeploying your app.
Gateway	One OpenAI-compatible endpoint in front of every provider (OpenAI, Anthropic, Gemini, OpenRouter, …). Bring your own keys; get routing, cost, and caching.
Tracing	Every gateway call is recorded as a trace with spans — model, tokens, latency, cost. Report your own spans from app code too.
Tools	Callable functions, versioned exactly like prompts, that you attach to a prompt and hand to the model.
Evaluation	Build datasets from real feedback and run experiments to compare prompt or model versions on quality.

How they connect

The blocks form one continuous line from authoring to measurement:

Author a prompt  →  call it through the gateway  →  the call is traced
      (Prompts)              (Gateway)                   (Tracing)
                                  │
                          attach tools                collect feedback
                             (Tools)                  → build a dataset
                                                       → run an experiment
                                                          (Evaluation)

A concrete run looks like this:

1. You author support-reply in the Prompts UI and promote v2 to production.
2. Your app calls the Gateway with a reference to that prompt. The gateway renders the template, picks the model, and calls the provider.
3. The call shows up in Tracing with its model, token counts, and latency.
4. Your prompt hands the model a get_weather Tool; the model calls it and you return the result.
5. Users thumbs-up/down the answers; you turn that feedback into a dataset and evaluate a new prompt version against it.

Who it's for

• App developers who call LLMs from Node or Python and want prompts they can change without shipping code.
• Teams who need one audited, cost-visible path to every model provider.
• Anyone who has outgrown hard-coded prompt strings and print-statement debugging for LLM features.

Ready? Head to the Quickstart to make your first call in a few minutes, or read Core concepts for the mental model first.