Brass: an AI-first programming language

A token-efficient programming language designed for AI to write and humans to trust.

Welcome to Brass • AI Token Efficiency • All Docs • Request for Comments

Brass is a language designed to help AI models spend fewer tokens understanding and changing code. The language itself favors explicitness over abstraction and is designed with built-in tooling, allowing AI models to navigate code and gather context more efficiently. Brass, the language and its tooling, comes down to three ideas:

Make Code Rules Obvious. Each record lists its own fields. A function’s declaration shows its inputs, promises and access to outside services, so a model or reviewer can find those facts without tracing them through other implementations.
Never Break a Promise. A function’s promises sit right next to its declaration, separate from the code that does the work. A model can rewrite the body, but the full checker must prove that it still keeps those promises or reject the program.
Own Code Discovery and Changes. The brass command shows declarations, finds their uses and checks patches before writing them. Those answers help a model decide what else it needs to read and which code to change.

Brass v0.3 includes the language specification and a working tool for navigating, editing and checking code. The tool checks program structure and runs examples. Brass and its tool have been tested against Python; here's how it went.

A formal compiler and runtime are what's up next for Brass.

Interested and looking for a place to start? Go with Welcome to Brass Language, a walk through the language, set in a dinosaur park where the code keeps the gates shut.

How Brass stacks up against Python

In these trials, Brass used fewer model calls and cost less than Python.

The chart below follows ten attempts to add cash advances to the same expense-report system: five in Brass and five in Python. Each row shows one session, from its first read to its last check.

Brass used 13 to 27 tool actions per session; Python used 52 to 87. A single model call can request several actions, so this chart counts the individual reads, edits and checks.

Those ten sessions are part of a 40-session comparison. Claude Sonnet ran three tasks: adding "cash advances" behavior to a small and a larger codebase, and then adding trip planning behavior.

Each scenario had five Python sessions and five Brass sessions. Another ten tested Brass with ordinary file tools only. In the results below, Brass means the language and its tooling together.

Across the three scenarios:

Fewer calls. Brass averaged fewer than half as many requests to the model as Python.
Less text sent. Brass sent the model half as much text as compared to Python.
Lower bills. Average costs were 14 to 24 percent lower, depending on the scenario.
Correctness. Every hidden test passed in 13 of the 15 Brass sessions and all 15 Python sessions.
More reasoning. The model did 1.4 to 1.8 times as much thinking in Brass (the hidden reasoning it does before answering). Unfamiliarity may explain some of that difference, but these runs did not establish the cause.

The next chart shows every session, so you can see the spread behind the averages. Each dot is a session; the bar marks its row's average. The “lang. only” rows show Brass using ordinary file tools, without the brass command.

In an earlier test, giving Python a similar tool and a quick guide to the code closed most of the difference in total text sent to the model.

The full write-up explains the comparisons. The 40-session snapshot and earlier tests contain the inputs, finished programs and results.

A quick Brass example

Here's a small Brass file that adds two numbers. The comments call out what makes it Brass:

# Code comment: an example add.brass file for adding two values
module math.add

interface
  # No access parameter, so add can't reach any outside services.
  fn add(a: Int, b: Int) -> Int
    before a > 0 and b > 0          # callers must provide positive values
    after result == a + b           # the result must equal their sum
    example add(2, 3) == 5          # one test, run on every check

body
  fn add(a, b) = a + b

As you can see, the interface states the function's requirements and the body implements them. If a model changes the body to cap the result at 100, add(2, 3) still passes its example, but larger inputs break the after promise. The full checker must reject that edit.

A few more simple code examples can be found in Brass — everyday code.

Exploring Brass

If you want to dive deep, I suggest reviewing documents in the following order:

Welcome to Brass Language: a getting-to-know-you tour of the language, set in a dinosaur park.
The AI Token Efficiency of Brass: what the trials measured.
Cheat sheet: every common form on one "page", with notes for Python and Rust programmers.
Specification for the rules, grammar for how it looks, and principles for the why.

Also check out examples/ for complete example programs and History if you are interested in understanding how Brass came to be.

FAQ

Why create another language instead of improving Python's tooling?
Applying the tooling in Brass to Python could help, and early testing showed this (to be explored more in the coming months). But specific to Brass, the language puts permissions and contracts into the language itself and leaves out things like inheritance and exceptions, which make it harder to trace how code connects. Designing the language and tooling together lets those choices shape how code is written, inspected and checked.

So is Brass a language or tooling to help an AI model?
Both, designed together. The language puts a function's inputs, promises and permissions in its declaration, so the facts a model needs are in one place. The brass tool reads those declarations back: it shows them, finds their uses and checks a patch before writing it. In the results, “Brass” means the two together. The language was also tested with ordinary file tools only, and that setup cost more than Python. See The AI Token Efficiency of Brass.

Does Brass have a target use case?
Brass was designed to target software whose permissions and business rules need to stay clear as it changes: payments, authorization, workflows, tools used by AI agents and provisioning. User interfaces, heavy numerical work and hard real-time systems aren't what Brass is designed for, at least for now.

How can a model use Brass without a large body of existing code to learn from?
The trial sessions worked from a language reference and existing Brass programs, without training specifically for Brass. They completed the tasks, though they generally used more reasoning tokens than Python. Familiar syntax, explicit rules and tool feedback are intended to make that learning manageable.

Does token efficiency mean writing shorter code?
No. Brass favors explicit declarations, even when they add lines. The aim is to reduce the work a model does to understand and change a program while keeping the code clear enough for a person to review.

What comes next?
The full checker, which proves every function's promises, then a compiled runtime. Once those exist, the trials can measure the whole job, from first read to working program, fixes included.

Request for comments

Where does Brass make sense to you or what needs clarity? Brass is still a new idea, I'd like to hear what you think.

Open an issue with your question or comment, or write to pcnofelt@[your standard google email provider].com.

There is also a Discord, new and worth a try: join the Brass Discord.

The Brass specification and documentation are licensed under CC BY 4.0, and the code under the Apache License 2.0. See LICENSE-docs for details. © 2026 Peter Nofelt. Brass is a trademark of Peter Nofelt.