Introducing Talos

We're introducing Talos, a backend you describe instead of write. You declare your tables, write the rules of your app the way you would explain them to a colleague, and map each URL to a sentence. A small language model reads the sentence and writes the query plan; Talos runs it against your database, safely.

Talos is available today on npm as @athenox/talos, under the MIT license.

It is also Korollr's first step toward software written with AI — not a model that writes code for you to review, but one that sits inside the application and does part of the work at run time. A backend is where most of an app's repetitive code lives, so that is where we started.

Here's what you can expect:

• Describe, don't write. No SQL, no controllers, no migrations. A route is a line: 'DELETE /api/recipes/:id': 'delete the recipe {id}'.

• Compiled once. A sentence goes through the model on its first call. The plan is kept, with its parameters as slots, and replayed without the model after that: a route costs what its SQL costs.

• The model plans, the code decides. Who may read or write what, which rows belong to whom, what a valid value looks like: all of it is ordinary, deterministic code. The model is never asked whether something is allowed.

• Free-text requests. "The easy desserts under 30 minutes" works too, for a search box or an assistant, with the same permissions as any route.

• A full backend kit. Accounts and sessions, uploads with image processing, full-text search, similar items and recommendations, RSS and sitemaps, CSV import, rate limiting.

• No database to set up. Leave the database out and Talos keeps its own, built from your schema. Or bring SQLite, MySQL, MariaDB, or a Drizzle schema.

• Small by design. The model ships inside the package and runs on an ordinary CPU. No GPU, no API key, no network call to think.

How it works

An app is a schema, a few lines of prose, and a table of routes:

import { defineApp, defineRoutes } from '@athenox/talos'

const app = defineApp({
  prompt: `
    show the recipes and the cooks.
    a member may add a recipe, and change or delete their own.`,
  schema: { tables: [{
    as: 'recipes', table: 'recipes',
    columns: { id: 'id', title: 'title', course: 'course', author: 'author_id' },
    enums: { course: ['main', 'starter', 'dessert'] },
    roles: { write: ['member', 'admin'] },
  }] },
})

// member: the signed-in account; own: the rows that are theirs
export default defineRoutes(app, {
  'GET    /api/recipes':     { say: 'show the recipes', orderBy: '-id', limit: 20 },
  'POST   /api/recipes':     { say: 'add a recipe', guard: member },
  'DELETE /api/recipes/:id': { say: 'delete the recipe {id}', guard: member, where: own },
})

The model reads your schema, your rules and the request, and generates the plan — the operation, the table, the filters, the values — by pointing into what it read. That is how it names tables and columns it never saw in training. Every answer carries the plan it ran in a header, so a route is never a mystery: read it once when you add it.

Sentences can be written in English or in French. A misspelt table or column name is read as the word it was meant to be, and an opening verb — delete, add, change, show — settles the operation.

Safe by default

A model that is right almost every time is not a permission check. So in Talos the model only says what was asked. Whether it is allowed is decided by the roles in your schema and the guards on your routes; rows that belong to a user are pinned to that user whatever plan came back; every value written goes through your rules first. A plan that does not fit is refused, not guessed at.

Built to be helped

Every Talos instance has an id, and every model call has one too, returned with each answer. When something goes wrong, those ids are all it takes for us to see what happened: the plan the model made, the error that followed, how long it took.

To make that possible, Talos reports how it runs — errors right after an answer, the plans it made without their values, latency, versions, your schema without a single row. What your users type is anonymised before it leaves: words outside the model's vocabulary and your app's own words become placeholders. Each part can be turned off on its own, or all of it with one line. Developers can also send feedback on any call, with a rating, a comment, or both.

Limits

Talos is built on a small model. On routes, where the HTTP method fixes the operation and the URL names the row, it is dependable. On free-text requests it can misread a sentence, and it does not always recognise a request that has nothing to do with your app. Anything that writes belongs in a route; free text is best kept for reading. Check the plan of a new route before relying on it.

Talos runs on Node 22.13 or later, and its HTTP helpers target h3 1.x, the version Nuxt 4 and Nitro use.

Availability

Talos is available now:

npm install @athenox/talos

The documentation ships with the package: a guide to the schema, routes, accounts, files, search and telemetry, and a reference of every export. Talos is released under the MIT license.

This is a first step. The model behind Talos will keep learning to read more of what an application needs, and more of the code around it will become something you describe rather than write.