You told it exactly what to build. It built that drifted anyway — and you find out after the run.
Aexol ships code from a spec you approve. The output forecast lands before the agent executes, and every build is checked against your spec while it runs. Approval moves in front of execution.
Free to start · No credit card · The agent runs on your machine
forecast before tokens
spec plain text, in your repo
checks during generation
cost capped per project
code stays on your disk
“I've paid a total of $20 and in 10 days, my cost, according to Claude code's cost tracker is like $400”joshuamorton · Hacker News · item 48752397
one comment on one thread. three more, same year, same complaint, different angle:
HN 44755842
“With Opus / Claude Code it will follow instructions until it doesn't and then suddenly — it creates a web worker instead of using Bull which it did first for exactly the same case.”
HN 47939003
“The average dev was hitting $2k/mo in Claude code costs. That is no longer a helpful tool… it costs like ~15% of an actual dev.”
HN 47327659
“I built OopsDB after letting Claude Code run wild — watching it decide the best way to fix a bug was to drop my dev database. Basically playing Russian roulette.”
So what do you do? You write longer prompts. You remind it every single time. You re-read every diff like it's a stranger's code, hoping the tests catch what it broke. And when the context fills up, it drifts anyway — while every run and every commit quietly burns tokens. The loop isn't a prompting problem. It's that approval comes after execution — after the drift, after the tokens, after the damage.
The problem isn't your prompt.
It's the order of operations.
that's the entire shift. everything else on this page is what falls out of flipping the order — not a new promise.
Flip the order, and the session reads differently.
Same repo, same agent, same work. The only change: you approve in front of execution — so the forecast, the spec check and the cost cap all land before anything runs. The numbered marks point at the four things that fall out of that flip.
You read the program first
Files, tables, resolvers, tests — forecast before execution. You adjust it, then approve it. Nothing touches your repo until you say so.
Held to your spec, mid-build
main.aexol is machine-checked on every build. Drift gets caught at generation time — not in code review, not in production.
The cost sits on the forecast
Compressed prompts, fewer round-trips, usage capped per project. You know what a build costs before you run it — not on the 1st of next month.
It runs where your code lives
Execution is local. The relay routes identity, never your content. Your source stays on your disk.
releases on the 0.9 line. every one dated, every one public. this page describes a shipped tool, not a waitlist.
- the language
- An AI-native specification language with its own parser, validator, inference engine and code generators. Not a prompt wrapper wearing a UI.
- the spec
- Plain text you own. Types, roles, workflows in one readable file that versions with your repo like any other source file.
- the record
- Every release ships in a public changelog — so nothing below is a promise you can't go and check.
- the execution
- Local by default. The relay routes identity, never your content.
We're not going to tell you this is 10× faster than your current agent — nobody selling you a number like that has the benchmark, and neither do we — the numbers we do publish are community model benchmarks and quant benchmarks. What we can show is the mechanism: the forecast lands before execution, the compliance check runs during it, and usage is capped per project. Run it against your own repo and judge the output, not our copy.
- Aexol Studioplan-mode spec editor · forecast + compliance viewsincluded
- Spectral agent (CLI)the local executor · Node 20+ · your machineincluded
- main.aexol → artifactsGraphQL schema · Prisma schema · resolvers · tests · frontendfirst build
- Compliance checkvalidated against your spec on every buildalways on
- Public changelogevery release, dated, checkablealways on
Then: Pro credits when you scale. Flat plans, usage capped per project, no surprise line items. No card to start.
SPECS-NOT-VIBES
Your first forecast today. Not in a sprint.
Three commands, one spec file. If you've written a Prisma or OpenAPI schema, you already know most of the shape.
npm i -g @aexol/spectralThe local agent. Node 20+, nothing hosted runs your code.spectral initScaffolds main.aexol — plain text, yours to edit by hand.spectral serveStudio on localhost. Write the spec, read the forecast, approve the build.Under 10 minutes · Free to start · No credit card
The things you'd ask before switching.
Answered plainly — including the ones with uncomfortable answers.
Do I have to learn another DSL? +
main.aexol is plain text you own — types, roles, workflows, in one readable file. Studio helps you write it, and it versions with your repo like any other file. If you can write a schema, you can write a spec.
Will it fit my stack? +
It generates typed schemas, resolvers and tests, and works alongside shell, Git and MCP tooling. If you already work spec-adjacent — OpenAPI, Prisma, GraphQL — you know the shape of it. It is not a claim that it will rewrite your existing monolith.
Why is the cost predictable? +
Because it's on the forecast: compressed prompts, fewer round-trips, usage capped per project, flat plans. We're not claiming a multiple versus your current agent — we're claiming the number is in front of you before you run, and it doesn't wander.
What about my code? +
The agent runs on your machine. The relay routes identity, never your content. Your source stays on your disk.
What if the forecast is wrong? +
You approve the forecast before execution, and the compliance check runs during the build against your spec. If it drifts, you see it before merge. Not a guarantee the first forecast is the one you keep — a guarantee you get a vote.
Are you SOC2 / on-prem ready? +
Not today, and we'd rather lose you here than surprise you in procurement. Execution is local, but if you need signed attestations this quarter, buy the tool that has them.
Some people should not switch. Honestly.
A tool you have to babysit isn't worth switching to. The honest line, in diff form — read the minus lines first.
- P.S.
- The free tier is the demo. If the forecast and the compliance check don't change how you ship, you've lost ten minutes — not a subscription. There's nothing to cancel.
- P.P.S.
- Nothing here is unverifiable: the changelog is public, the spec is plain text you keep, and the agent runs on your hardware. Check all three before you believe any of them.
- P.P.P.S.
- If unpredictable runs and a bill you can't forecast are genuinely working for you — don't switch. This is for people who ship and are tired of paying to review someone else's drift.
Stop approving after execution.
Write the spec. Read the forecast. Then let it build.
Start free — take back controlFree to start · No credit card · Your code stays on your machine