A statically typed scripting language and virtual machine for safely executing AI-generated code.
Autolang is designed for one specific problem:
Allow AI to generate executable code without exposing your entire runtime.
Instead of letting an LLM execute Python or JavaScript directly, you expose only the functions you choose. AI writes the workflow, while your existing backend performs the actual work.
Tool calling works well for simple, sequential tasks. But consider a case where you need to classify 1,000 customers by purchase history, segment them into tiers, and apply different discount rules to each group.
With tool calling, the model makes one API call per customer, waits for the result, reasons again, then calls the next. That is 1,000+ round trips - each one adds latency and token cost.
With Autolang, the model generates a short script once. The script runs locally against your registered functions. No round trips. No repeated reasoning.
` Tool calling Autolang
LLM -> call tool LLM -> generate script once -> wait -> compile -> reason -> run locally -> call tool -> wait Done. Result returned immediately. -> reason -> ... `
Autolang is a good fit when:
- you are processing many items (hundreds or thousands)
- each item follows the same logic but with different data
- round-trip API cost and latency adds up
- you want to avoid repeated LLM reasoning for the same task
Modern LLMs are increasingly capable of generating code.
The challenge is not code generation - it is execution.
Running AI-generated Python or JavaScript means exposing a large runtime with unrestricted APIs, dynamic imports, filesystem access, networking, and unpredictable memory usage. Even with Docker or MicroVMs, every agent still carries the cost of a full runtime.
Autolang approaches the problem differently.
Instead of sandboxing an operating system, it sandboxes the language itself.
Scripts can only call APIs that you explicitly register.
AI | Autolang Compiler | Type Checking | Bytecode | Autolang VM | Registered JS / C++ Functions
This makes execution predictable, lightweight and suitable for large numbers of concurrent AI agents.
Cheaper and faster models make more mistakes. Autolang is designed to help them recover.
- Static typing catches type errors before execution
- Detailed stack traces tell the model exactly what went wrong and where
- Friendly error messages with hints make it easier for smaller models to understand and fix their own code
- Restricted API surface means the model can only call what you expose, reducing the chance of hallucinating nonexistent functions
This matters more as you scale down model size. A model that cannot understand a generic JavaScript stack trace can still fix its Autolang code when the error message explicitly tells it what to correct.
- Static type checking
- Custom bytecode virtual machine
- No GC
- No JIT
- Opcode execution limits
- Null safety
- Native JS bindings
- Native C++ bindings
- @js_object interoperability
- Per-library language restrictions
- Compile-time diagnostics
- Fast startup
- Small memory footprint
Autolang is a good fit if:
- your application lets AI generate code
- you need to control what AI can access
- your backend already exists
- scripts are short and executed frequently
- startup latency matters
- memory usage matters
Typical examples:
- AI Agents
- Internal automation
- Workflow engines
- Business rule execution
- Embedded scripting
- Multi-agent systems
- Customer segmentation and classification
- Internal SME tools that let AI operate on your existing data
Autolang is not intended to replace Python, JavaScript or C++.
It does not replace Docker or KVM for OS-level isolation.
It is probably not the right choice if:
- you need a general-purpose language
- your programs are thousands of lines long
- you require unrestricted OS access
- your application does not execute AI-generated code
Measured on:
- Windows 11
- Intel Core i5 12th Gen
- 16GB RAM
| Metric | Result |
|---|---|
| Native cold start | ~10 ms |
| Node.js cold start | ~20 ms |
| Warm execution | ~1-2 ms |
| Core runtime | ~0.5 MB (0 script line) |
| Full stdlib | ~0.61 MB (0 script line) |
| 1,800-line test peak | ~3.8 MB |
Autolang optimizes total execution time:
Compile + Execute = Fast response
This is especially useful for AI-generated scripts, which are usually short and executed many times.
Bash npm install autolang-compiler
Bash clang++ tests/main.cpp -O2 -std=c++17
Requires a C++17 compiler.
Register a native function:
s compiler.registerBuiltInLibrary(example, @native(hello) fun hello(name: String): String , {}, { hello(name) { return Hello + name; } });
Run a script:
`kotlin @import(example)
println(hello(Autolang)) `
Output:
Hello Autolang
The script cannot access anything except the APIs you registered.
Suppose you have an internal product that needs to classify customers by purchase behavior. You expose a single database function and let AI generate the classification logic.
` s compiler.registerBuiltInLibrary( company/database,
class Product(
remaining: Bool
price: Int
)
@js_object
class Products {
@native(get_products)
fun getProducts(): Array<Product>
}
,
{ autoImport: true },
{
get_products() {
return db.query(SELECT * FROM products);
}
}
);
await compiler.compileAndRun(classify.atl, var expenseCount = 0 var normalCount = 0 var cheapCount = 0
Products.getProducts()
.filter {|product| product.remaining}
.forEach {|product|
when (product.price) {
> 3 -> expenseCount += 1
== 3 -> normalCount += 1
else -> cheapCount += 1
}
}
println(Expensive: + expenseCount)
println(Normal: + normalCount)
println(Cheap: + cheapCount)
); `
The model only sees Products.getProducts(). It cannot query your database directly, access other tables, or call anything outside the registered API.
Instead of asking an LLM to repeatedly call tools:
LLM -> Tool -> LLM -> Tool -> LLM
Autolang allows the model to generate an entire workflow once:
LLM -> Autolang Script -> VM -> Registered APIs
This reduces:
- latency
- token usage
- repeated reasoning
- unnecessary API round trips
while keeping execution inside a restricted environment.
Autolang uses a Kotlin-inspired syntax designed to be easy for both developers and LLMs.
kotlin val name = Autolang var count = 10
`kotlin var user: User?
println(user?.name ?? Unknown) `
`kotlin val numbers = [1, 2, 3, 4]
val even = numbers.filter {|v| v % 2 == 0 } `
`kotlin class Animal { fun sound() = ... }
class Cat extends Animal { @override fun sound() = Meow } `
More examples are available in the documentation.
Autolang does not replace your backend.
Instead, it allows you to expose existing functions to AI through native bindings.
kotlin @native(read_user) fun readUser(id: Int): User
The implementation remains inside your application.
Scripts can only call the functions you explicitly register.
Complex JavaScript objects can be wrapped using @js_object.
This allows AI-generated scripts to use fluent APIs while the actual object remains entirely on the host side.
`kotlin @js_object class QueryBuilder {
@native(where)
fun where(field: String, value: String): QueryBuilder
@native(execute)
fun execute(): Array<Order>
} `
Example:
kotlin Database.createQuery() .where(status, completed) .execute()
This makes existing ORMs and query builders accessible without exposing JavaScript itself.
Autolang uses:
- Reference Counting
- Hot Restart
Instead of relying on a garbage collector, memory is reset after each script execution, providing predictable execution costs and consistent latency.
Autolang assumes AI-generated code is untrusted.
Security is enforced before and during execution.
Built-in protections include:
- Static type checking
- Restricted language features
- Opcode execution limits
- Managed memory limits
- Registered APIs only
- Disabled filesystem by default
- Disabled networking by default
- Domain allowlists
- File path allowlists
- Per-library permissions
Autolang is a language-level sandbox.
It complements - but does not replace - OS-level isolation when stronger security guarantees are required.
Documentation includes:
- Getting Started
- Language Guide
- Standard Library
- AI Integration
- Native Bindings
- Security
- Examples
- API Reference
- Live Playground
https://autolang.vercel.app/docs
Current development focuses on:
- Better error messages
- Additional standard library modules
- Performance optimizations
Contributions are welcome.
If you discover a bug or have an idea for improving Autolang, feel free to open an issue or submit a pull request.
Please read the documentation before contributing to understand the project architecture and design philosophy.
MIT License c 2026 Autolang Project