TYPO3 extension · 0.5.0

The AI layer for TYPO3.

Your extensions ask for AI. AiM decides where the request goes, and keeps the receipt.

An extension says what it needs. AiM picks the provider and model, enforces your rules, retries elsewhere when a provider fails, and writes down what it cost. Nothing about a provider, a key or a model lives in the calling extension.

TYPO3 12.4 · 13.4 · 14 PHP 8.1+ Provider deps: none Keys encrypted at rest GPL-2.0-or-later
View on GitHub Read the introduction
$ composer require b13/aim
AiM — Request Log
The AiM Request Log, listing every request with its provider, model, tokens, cost and grade

Why

One switchboard, not one integration per extension

Three extensions in one installation, each with an API key of its own, each talking to whichever provider its author happened to prefer, and no single place that knows what any of it cost. Add a fourth and you do all of it again.

Without AiM

  • API keys scattered across extension configurations
  • No overview of what AI is being used for
  • No cost control: any extension can burn the budget
  • No way to switch providers without touching code
  • No boundaries: confidential data can reach a cloud provider

With AiM

  • One place that holds every credential, encrypted
  • Every request logged: who, what, when, how much
  • Budgets and a rate limit per user, admins included
  • Providers swapped in the backend, not in code
  • A configuration can be pinned to its own model

For developers

Three lines in a consuming extension

Your extension does not know or care which provider answers. The administrator decides that, in the backend, after your code has shipped.

use B13\Aim\Ai;

public function __construct(private readonly Ai $ai) {}

$response = $this->ai->vision(
    imageData: base64_encode($fileContent),
    mimeType: 'image/jpeg',
    prompt: 'Generate alt text for this image',
    extensionKey: 'my_extension',
);

echo $response->content; // "A golden retriever playing fetch in a sunny park"

What you get

Six areas, all configured in the backend

All of it through TYPO3's own mechanisms: user groups, TSconfig, DataHandler, the Install Tool. Nothing invents its own permission model.

Providers

Any provider, no lock-in

Install a Symfony AI bridge and AiM finds it, whoever published it. Models and capabilities are read from the bridge itself. Endpoint URL and credential are separate fields, so a self-hosted gateway behind a token works too.

Governance

Who may spend what

Capability permissions and provider access per backend group, privacy levels per configuration, budgets, and a rate limit that is on by default. Credentials are encrypted and never shown again.

Tone

A site-wide tone of voice

Named prompt fragments on any page, inherited down the tree, reusable across sites, with a preview that shows exactly what would be sent without spending a single request.

Routing

Cheaper when it can be

Simple prompts go to cheaper models, chosen from your own cost, reliability and quality history. A failed provider is retried against the next one, and a configuration you pinned stays pinned.

Visibility

Every request, on the record

One log with tokens, cost, duration and the routing decision, optionally with a quality grade from a second model acting as judge. Plus dashboard widgets for the totals.

Built for prod

Three TYPO3 versions, two engines

TYPO3 12.4, 13.4 and 14, Composer and Classic mode, tested on SQLite and MariaDB, with static analysis and coding standards running in CI.

In the backend

Three modules under Admin Tools

Everything an administrator needs is in the backend: no configuration file to edit, no second tool to log into, and no AI knowledge required to run the thing. Provider records are ordinary TYPO3 records, so permissions, history and undo work the way your editors already expect.

AiM — Providers
The Providers overview listing each configuration with its endpoint, model and status
One row per configuration, with its endpoint, model, cost so far and connection status.
AiM — Request Log
The Request Log detail view of a single request, with its prompt, response, tokens, cost and grade
Any row opens up: the prompt that was composed, the answer that came back, and what the two cost.
AiM — Prompt Management
Prompt Management listing the pages that carry a tone-of-voice fragment
Which pages carry a tone of voice, and a preview of the prompt that would be composed for them.

Documentation

Read the guides here

If you are deciding whether AiM fits, the introduction is the shortest way in. If you are wiring it into an extension, start with using AiM. If you are the one who has to answer for the API bill, governance is the page to read.

GuideWhat it covers
Introduction What AiM is and why it exists, without the code. Start here.
Configuring a provider Every field, a worked example per provider shape, site settings, and registering a provider AiM does not know.
Using AiM The proxy API, the fluent builder, pipeline access, structured output, tool calling, streaming.
Governance Credential storage, restrictions, budgets, rate limits, privacy levels, rerouting protection.
Tone of voice Prompt composition, page-tree fragments, the fragment library, voice calibration.
The request pipeline Smart routing, grading, the eleven stages, and middleware of your own.
Backend modules The three modules, the dashboard widgets, and the database tables.
Release notes What changed, including important upgrade notes

Add AI to your extension, not another API key

AiM is alpha: the API works and is in production use, but it may still change before 1.0. Feedback is very welcome.

View on GitHub Open an issue