Your AI assistant does not burn tokens on your app. It burns them on your infrastructure.
Where the tokens go
Three places, and only the first is obvious.
What the model writes. Every schema, route, config and deploy file is output.
What the model reads back. Those files return to context every time it checks a field name or a return shape.
What the machine sends back. Install logs, stack traces, failed migrations, rollback dumps. Input the model did not choose, cannot shorten, and has to read.
On top of that, every turn resends the whole conversation. Ten turns of backend debugging do not cost ten turns. They cost closer to the sum of one through ten. Cutting the code in play does not subtract from your bill. It divides it.
A login
Ask an assistant for signup and login with email confirmation. With a conventional stack it starts here:
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email TEXT UNIQUE NOT NULL,
password_hash TEXT NOT NULL,
name TEXT,
verified BOOLEAN NOT NULL DEFAULT false,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE TABLE sessions (
token TEXT PRIMARY KEY,
user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
expires_at TIMESTAMPTZ NOT NULL
);
CREATE INDEX sessions_user_idx ON sessions (user_id);
Then a migration file to apply it. Then bcrypt, a JWT library, a signing secret, refresh logic, auth middleware, four routes, an SMTP provider, a verification email template, CORS, environment variables, a Dockerfile, a deploy step.
Then it opens a terminal. Install the packages. Run the migration. Start the container. Find out why the container cannot reach the database. Deploy. Find out why the deploy rolled back.
In Skapi, that is the whole thing:
<form action="welcome.html"
onsubmit="skapi.login(event).catch(err => alert(err.message))">
<input name="email" required />
<input type="password" name="password" required />
<button type="submit">Login</button>
</form>
No table, no token library, no route, no email template, no terminal. Our full auth template covers signup, email verification, login, logout, forgot password, password reset, password change, profile update and account removal in twelve HTML pages and 770 lines, and that counts the markup and the stylesheet. Roughly six thousand tokens for the entire system. Eleven method calls.
A table
Now a photo feed. Posts that can be private or public, with likes, hashtags, and an ordering by most liked.
With a conventional stack: a posts table, a likes table with a unique constraint so nobody likes twice, a tags table, a join table, indexes on created date and like count, another migration, an ORM model for each table, then a storage bucket, a signing endpoint and a CORS rule for the images.
In Skapi, one call:
skapi.postRecord(event, {
table: { name: 'posts', access_group: isPrivate ? 'private' : 'authorized' },
index: { name: 'likes', value: 0 },
tags: hashtags
});
It takes the form, uploads the image inside it, stores the caption, applies the permission, indexes it for sorting and attaches the tags. The index is an argument. The access rule is an argument. There is no schema at all, because the client decides the shape of a record at the moment it posts one.
The tokens follow the infrastructure
A conventional stack splits your app in half and makes your assistant build both sides plus the seam between them. One table lives in six places at once: the migration, the model, the type, the validator, the query and the client that reads it. Rename one field and that is six edits, with a runtime error waiting at the one it missed.
Half the work is also invisible. A file can be read. A database, a container, a policy and an environment variable cannot, so the model runs commands just to learn what is there, and pays for whatever the machine prints back.
Skapi has no second half. Nothing to deploy, nothing to migrate, no hidden state to go and inspect. Your assistant writes the page, and then it is finished.
Go build with Skapi, and stop worrying about your tokens.
Baksa, Creator of BunnyQuery