GitHub

Why Seq

Words are the source.

The Seq programming language puts the language model where a compiler belongs: in the build. You write requests. You run a native program.

01 · The language

The request is the source

A Seq file declares which model writes the program, which language the program is written in, a name, and an ordered list of steps. Each step holds requests in plain language.

  • Steps run in source order. That order is fixed by the compiler, not left to the model.
  • The model receives the whole workflow at once, so a later step can use what an earlier step creates.
  • Seq has no expressions, branches, loops, imports, or parallel steps. The generated program may use them internally.
Tour the language
src/main.seq
model("https://huggingface.co/Qwen/Qwen2.5-Coder-1.5B-Instruct")
backend.C()
name = "top3Company"

step step1():
    ask("create a database file company.txt with 5 sample stock transactions")

step step2():
    ask("for each transaction created give me the total revenue of the company")

step step3():
    ask("create an image chart showing the 3 companies with the highest revenue")

02 · The model

A model at compile time.
Native code at run time.

ask() is a compile-time directive. Once a build is accepted, the model's part is over.

At compile time

  • The model writes a plan for the whole workflow, then one C function per step, then test cases.
  • Every response is constrained by a JSON schema, sampled at temperature 0 with a fixed seed.
  • Inference is local: llama.cpp on a loopback port. Nothing from a project leaves the machine.
  • Compile and link errors go back to the model for repair, at most twice.

At run time

  • What runs is a static executable, compiled by GCC with -O3.
  • It never contacts a model, and could not: generated programs have no network.
  • An unchanged workflow reuses the accepted build: no inference, no compilation.
  • A failed build never replaces the last accepted build and never runs a stale executable.

03 · The sandbox

Generated code is untrusted

seqc treats the model's responses, the code built from them, and the contents ofinput/ as untrusted. Prompting does not enforce anything. The kernel does.

  • Compilers and generated programs run under Landlock and a seccomp filter, with no privileges needed.
  • If the sandbox cannot be applied, nothing runs. There is no fallback to unrestricted execution.
  • seqc never installs what a model asks for. A plan that needs anything beyond the C library,libm, and the Seq runtime fails the build.
Read the security notes
Network
None. TCP, UDP, and Unix sockets are all denied.
New processes
None. A generated program cannot start another program.
Reading
Its own executable and the project’s input/ directory. Nothing else on the host.
Writing
The staging directory of its run: regular files and directories only.
Resources
CPU time, wall-clock time, address space, file size, and output size are all limited.

04 · The record

Every build explains itself

An accepted build keeps the generated C, its assembly, the executable, and the tests beside your outputs. You can read exactly what will run.

  • The executable is linked from the emitted assembly, so the .c, .s, and.bin files correspond by construction.
  • Each run records its plan, every inference request and response, compiler logs, and the hashes of what it published.
  • Publishing never replaces a file seqc did not create, unless you pass --force.
Read the architecture
A project after one run
top3Company/
├── seq.lock                 pinned model
├── src/main.seq             the workflow
├── input/                   read-only data for the workflow
└── output/
    ├── company.txt          published results
    ├── top3Company.png
    └── temp/                compiler-owned
        ├── top3Company.c    generated program
        ├── top3Company.s    its optimized assembly
        ├── top3Company.bin  executable linked from that assembly
        ├── test/            generated Google Test file and binary
        ├── build.json       manifest of the accepted build
        └── runs/<run-id>/   plan, attempts, logs, and manifests of each run

05 · The limits

What Seq does not promise

A language built on a model should say plainly where it stops.

  • A request is not a specification

    Parsing and step order are deterministic. The synthesized program is not. A program that compiles is not proof that it does what the request meant.

  • Generated tests are reported, not enforced

    The model writes the tests as well as the program. Failing cases are shown and recorded; they do not block a run.

  • Not yet verified with a real model

    The pipeline is covered by a deterministic suite that uses a scripted model. Pass rates with real model weights have not been measured yet.

  • Version 0.1 is narrow

    Linux x86_64 and the C backend only. The sandbox is proven only on WSL2 so far. There is no remote inference.