← Back to blog

Token Efficient Language

Token Efficient Language — or how we stopped wasting tokens on semicolons

Over the last couple of months, and especially after Claude's usage limits got tighter, we always used to joke with our friends about ways to reduce token usage. We'd seen things like the Caveman Claude — a kid who made Claude talk like a caveman and cut output tokens by 75% — and many other creative workarounds. But lately, me and some friends came up with an entirely different approach to the token problem.

Caveman Claude had a great idea: "why waste tokens with lot words when few words do trick". But this solution is incomplete — it only affects Claude's natural language responses. The moment Claude writes actual code, all that token savings goes out the window. A simple for (int i = 0; i < n; i++) still costs you 18 tokens whether Claude is speaking like Shakespeare or a caveman.

Luckily, together with @rodrihern_, @LolooMendez, and @pascalordanoo we thought of another approach. And that's how we came up with TEL — Token Efficient Language.

So what the F*ck is TEL?

TEL is a language designed to represent C (in the future also Java, Typescript, React and Rust) programs in a compact syntax that minimizes token consumption when interacting with LLMs — while still being readable and understandable by a developer. Think of it as a bijective compression layer, for example: for every valid C program, there exists exactly one equivalent TEL representation, and vice versa.

The compiler works as a source-to-source transpiler: your LLM writes in TEL, and it outputs standard C code. The transformation preserves 100% of the semantic information. Nothing is lost.

Why does this matter?

Right now, when developers use LLMs like Claude, GPT, or Gemini to write, review, or modify C code, the inherent verbosity of C generates excessive token consumption — both in input (prompts, file contents, command outputs) and in output (responses). This has a direct impact on three fronts:

  • Cost — LLM providers charge per token. Every semicolon, every pair of curly braces, every unsigned long int declaration is money.
  • Latency — More tokens means longer response times.
  • Context window — Tokens wasted on syntax noise reduce the space available for actual semantic content.

TEL attacks all three problems at once.

OK but how?

Here's a taste of the core transformations:

  1. Semicolons are gone. Statements end with newlines. That's one token saved per statement — and it adds up fast.
  2. Indentation replaces braces. Blocks are delimited by indentation (Python-style) instead of { }. Two tokens eliminated per block.
  3. Compact keywords. fn instead of writing the return type before the function name. ret instead of return. w for while. sw for switch. ? for if. td for typedef. str for struct.
  4. Smart defaults. The classic for (int i = 0; i < n; i++) becomes fd i 0 n. Because let's be honest, 90% of for loops are just iterating from 0 to n.
  5. Implicit includes. If your program calls printf, the compiler auto-includes <stdio.h>. If you use malloc, it includes <stdlib.h>. No need to write what the compiler can infer.
  6. Type shorthands. unsigned long int (3 tokens) becomes uli (1 token). unsigned int becomes uint. void becomes v.
  7. Implicit returns. If the last expression in a function matches the return type, the return is implicit.

Show me the numbers

Here's a simple hello world:

// C — 27 tokens, 99 characters
#include <stdio.h>
 
int main(int argc, char * argv[]) {
    printf("hola mundo");
 
    return 0;
}
// TEL — 8 tokens, 29 characters
main
    printf("hola mundo")

That's a 70% reduction in tokens and a 71% reduction in characters — for the most basic program imaginable. The savings scale up as programs get more complex.

A function with a for loop goes from 45 tokens in C to 32 in TEL. A struct definition with typedef drops from 26 to 21. Five #include directives go from 26 tokens to 16. And this is just the beginning.

The bigger picture

In a world where developers are increasingly hitting usage limits and token budgets are a real constraint, what if the code itself could be more efficient? Not the algorithms — the representation. Caveman Claude optimized the conversation. TEL optimizes the code.

Imagine a workflow where your codebase is stored in TEL, LLMs read and write in TEL, and only the final build step transpiles to your language. You'd process more code within the same context window, get faster responses, and spend less money — all without losing a single bit of semantic information.

If you're interested in compilers, token optimization, or just think semicolons are overrated — follow along. We're just getting started.

Built by Bautista Pessagno, Rodrigo Hernandez, Lorenzo Méndez, and Pascal Ordano. 2026.