ProxyLang vs JavaScript: The Token Math
ProxyLang is not trying to be a smaller Python or a prettier JavaScript. It is a language designed for agent-built software: compact enough for agents to author, explicit enough for humans to inspect, and governed enough for operational systems to run without loose execution paths.
The shift: from human-written code to agent-written systems
Most programming languages were designed around a human developer as the primary author.
A developer writes the code. The code calls libraries. Secrets live in environment variables. Logs are added later. Permissions are usually scattered across framework middleware, database policies, API routes, and application logic.
That model works, but it becomes fragile when agents start writing and modifying software.
Agents need a smaller surface area. Humans need clearer inspection. Companies need stronger governance. ProxyLang exists at that intersection.
The goal is not just to reduce lines of code. The goal is to reduce ungoverned implementation surface.
ProxyLang is agent-written, human-inspected, and runtime-governed.
The proof point: shop.pxy
The current proof point is shop.pxy: a complete e-commerce application in 157 lines and roughly 3.4 KB.
That single file defines a usable operational surface:
- themed marketing site
- navigation, pages, routes, and hero content
- authentication with a gated account page
- 4-product catalog UI
- cart and checkout
- payment provider integration
- settings form with text, email, password, number, select, and toggle inputs
- commerce backend with products, SKUs, and fulfillment logic
OrderFlowstate machine- audited lifecycle transitions
In a conventional Next.js and TypeScript implementation, that same surface would usually become a multi-file application: React pages, components, cart state, session handling, checkout API routes, payment integration, validation, order lifecycle logic, audit logging, and configuration.
ProxyLang compresses that into one governed source surface.
The highest-complexity .pxy today
The highest-complexity application ProxyLang can express end-to-end today is a single-file governed operational web app.
That means a real SaaS-style surface with:
- themed marketing pages
- authenticated and gated routes
- declared data schemas
- typed queries and mutations
- forms that write back to the database
- catalog, cart, checkout, payments, and subscriptions
- state machines for orders, approvals, inspections, or fulfillment
- agents that select from allow-listed actions
- tamper-evident audit logs
- default-deny permissions
Stitched together, that is roughly a 400–600-line .pxy file.
The important caveat: not every declared surface lowers fully yet. Site, data, forms, charts, commerce, machines, and agents are the core current lowering surface. Knowledge and launch constructs can parse, but should not be treated as fully lowered runtime surfaces yet.
Source-token comparison
A practical way to compare ProxyLang and JavaScript is not total runtime size. ProxyCore itself is a large Rust runtime. The better comparison is the source surface the developer or agent has to read, write, diff, audit, and maintain.
Using the rough estimate of one token per four characters, shop.pxy sits around 900 source tokens.
| Comparison | ProxyLang .pxy |
Equivalent Next.js + TypeScript |
|---|---|---|
| Application surface | Storefront, auth, account page, catalog, cart, checkout, payment provider, settings form, commerce backend, order state machine, audit transitions | React pages/components, cart store, auth/session handling, checkout API, payment integration, state machine, audit logger, validation, configuration |
| Realistic size | 157 lines / 3.4 KB | ~2,000–3,500 LOC |
| File count | 1 file | ~25–50 files |
| Estimated source tokens | ~900 | ~25,000–42,000 |
| Ratio | 1× | ~25–45× more |
For a larger kitchen-sink governed app, the comparison is likely closer to:
| Comparison | ProxyLang | JavaScript / TypeScript |
|---|---|---|
| App size | ~400–600 lines | ~6,000–12,000 LOC |
| Estimated source tokens | ~3,000–4,000 | ~75,000–150,000 |
| Practical ratio | 1× | ~10–30× more |
The ratio will vary by implementation quality, framework choices, generated code, and how much governance is included in the JavaScript version.
But the direction is clear: ProxyLang makes the operational source surface dramatically smaller.
Complexity is moved, not erased
ProxyLang does not eliminate complexity.
It relocates complexity.
The saved application tokens are paid for once inside ProxyCore: the runtime, parser, lowering system, permission model, state machine engine, audit layer, storage abstractions, adapter system, and execution controls.
That is the correct trade.
In JavaScript, each app often re-implements or reassembles the same operational concerns: routing, validation, database access, permissions, logging, lifecycle checks, payment flows, retries, and security boundaries.
In ProxyLang, those concerns become declarations that lower into a governed runtime.
ProxyLang is dense because ProxyCore carries the generality underneath it.
This is why the token comparison is meaningful for app authors and agents, but it should not be misrepresented as a claim that the entire system is smaller than JavaScript.
The whole system is not smaller.
The authored application surface is smaller.
That is where the leverage is.
Why this matters more for agents than humans
A human developer can navigate a 40-file codebase.
It is inefficient, but possible.
An agent has a harder constraint: context.
The more files, glue code, framework boilerplate, repeated validation logic, and scattered permission checks an agent has to hold in context, the more likely it is to miss something.
ProxyLang gives the agent a smaller working surface.
Instead of reconstructing intent from a large codebase, the agent can inspect a compact governing file:
site "ProxyShop"
auth:
provider email
commerce:
provider stripe
catalog products
machine OrderFlow:
placed -> paid
paid -> fulfilled
paid -> refund_pending
refund_pending -> refunded
audit:
log actor, action, resource, before, after, timestamp
The exact syntax will evolve, but the principle is stable: the source should expose system intent, permissions, lifecycle, and execution boundaries directly.
Agents should not have to infer governance from scattered implementation details.
The governance layer is the real difference
The core advantage is not that ProxyLang is shorter.
Short code can still be dangerous.
The real advantage is that ProxyLang is designed to make operational governance part of the source model.
Every important runtime object can have identity:
- agent ID
- user ID
- action ID
- API key ID
- provider ID
- resource ID
- state transition ID
- audit event ID
That changes how software is inspected.
A reviewer should be able to ask:
Who can act?
agent CommerceAgent
agent FulfillmentAgent
agent RefundAgent
What can they access?
can read orders
can update fulfillment_status
cannot read payment_method_raw
What keys can they use?
key stripe_refund_limited:
provider stripe
allow refund.create
used_by RefundAgent
audit required
What state transitions are legal?
machine OrderFlow:
placed -> paid
paid -> packed
packed -> shipped
shipped -> delivered
paid -> refund_pending
refund_pending -> refunded
What gets logged?
audit:
hash_chain true
log actor, key_id, action, resource, before, after, timestamp
This is the category shift.
In a conventional codebase, these controls may exist, but they are often distributed across many files and systems.
In ProxyLang, they should be inspectable from the governing source.
No ungoverned path by default
The strongest security claim is not “zero chance of leakage.”
That would be the wrong claim. No serious runtime should promise absolute impossibility. Leakage can still happen through bad adapters, misconfigured infrastructure, unsafe logs, prompt injection, broad permissions, human error, or compromised dependencies.
The stronger and more defensible claim is:
ProxyCore is designed so there is no ungoverned execution path by default.
That means:
- no raw secrets exposed to models
- no arbitrary SQL by default
- no arbitrary network calls by default
- no undeclared tool use
- no unlogged privileged action
- no state transition outside the declared machine
- no capability without actor identity
- no actor without permission scope
This turns leakage from a vague model-behavior problem into a runtime-governance problem.
The key questions become concrete:
- What can this agent see?
- What can this agent call?
- Which credential is being used?
- What scope does that credential have?
- What state is the system in?
- Was the action allowed?
- Was it logged?
- Can the transition be audited later?
That is the security posture ProxyCore should own.
ProxyLang spends tokens where control matters
The goal is not to make the fewest-token language possible.
A language can be tiny and still unsafe.
ProxyLang should spend tokens where the tokens create control:
- identity
- permissions
- secrets
- key scopes
- state transitions
- audit metadata
- data boundaries
- compliance rules
It should remove tokens where tokens create maintenance drag:
- framework glue
- repeated validation
- boilerplate routing
- ad hoc logging
- scattered authorization
- duplicated lifecycle checks
- hand-written integration plumbing
This is the correct density model.
ProxyLang is not just compressed JavaScript. It is compressed operational intent.
Why this is different from being “Python-like”
ProxyLang can borrow the readability of Python without becoming a Python clone.
Python-like simplicity is a syntax goal.
ProxyLang’s deeper goal is governance.
Python lets a developer write:
stripe.Refund.create(...)
ProxyLang should require a governed action:
action refund_customer:
actor RefundAgent
key stripe_refund_limited
require order.status == "paid"
transition OrderFlow: refund_pending -> refunded
audit required
The second version is not only more inspectable. It is operationally safer.
It tells the runtime who is acting, which key is being used, what condition must be true, which lifecycle transition is legal, and whether the action must be audited.
That is not just syntax.
That is an execution contract.
The category: agent-native governed software
The cleanest category for ProxyLang is not “low-code,” “workflow language,” “Python alternative,” or “JavaScript replacement.”
Those frames are too small.
ProxyLang is an agent-native governance language for operational software.
Its job is to let agents author and revise systems while keeping the execution surface bounded, inspectable, and auditable for humans.
A concise definition:
ProxyLang is an agent-native governance language for building operational software. It is compact enough for agents to author and revise, explicit enough for humans to inspect, and backed by ProxyCore so execution is identity-bound, permissioned, state-checked, and audit-logged by default.
That is the product category.
Not just agent-written code.
Agent-written software with runtime governance.
The actual token thesis
The token thesis should be stated carefully:
ProxyLang does not make the whole software stack 10–30× smaller. ProxyCore itself carries significant runtime complexity.
The claim is narrower and stronger:
For applications inside ProxyLang’s expressible surface, the source code an agent or human must inspect can be 10–30× smaller than the equivalent JavaScript or TypeScript implementation.
In the shop.pxy case study, the compression can be even higher: roughly 25–45× compared with a realistic Next.js and TypeScript build.
That matters because source tokens are now an operational constraint.
They determine how much of the system an agent can hold in context, how safely it can make changes, how easily a human can review those changes, and how much governance is visible at the source level.
The one-line takeaway
ProxyLang is not trying to be a smaller Python. It is a language for agent-built software where the source stays small enough for agents to operate on, and ProxyCore keeps every actor, key, action, state transition, and data access governed by default.
Or shorter:
Agent-written. Human-inspected. Runtime-governed.