Program-Aided Language Models (PAL): make the model write code instead of doing math

Ask GPT-4 to compute 847 × 326 + 1729 in plain prose. It'll guess. Sometimes correctly, sometimes not, often confidently wrong. Models are not calculators; they're probabilistic next-token predictors. Math that compounds across many digits is exactly where they fail in subtle, hard-to-catch ways.

Now ask the same question with a different framing: "Write Python that computes 847 × 326 + 1729 and prints the result." The model writes three lines of correct code. Run that code. Get the answer. Always correct, always verifiable, always reproducible.

That's Program-Aided Language Models (PAL): have the LLM produce executable code that solves the problem, then run the code deterministically. Math the model would have botched becomes math Python solves correctly — by construction.

The mental model: offload computation to deterministic tools#

Models excel at translation — natural language → some other representation. They struggle at execution — actually computing results that require precise arithmetic or state tracking.

PAL plays to the strength and avoids the weakness. The model translates the natural- language problem into code (its strength). The code runs in a Python interpreter (its strength). The two artifacts together solve the problem far more reliably than either alone.

It's the same principle behind tool use more broadly — LLMs as orchestrators, not computers. PAL is the specific case where the "tool" is a code interpreter.

The basic PAL pattern#

1. Pose the problem. Natural language input from the user or upstream task.
2. Generate code. Ask the model to write executable code that solves it. Include constraints (which library, which language, output format).
3. Execute in a sandbox. Run the code in an isolated environment with limited time and no network/file-system access.
4. Use the output. The code's stdout (or returned value) is the answer. Either return it directly to the user or feed it back to the LLM for natural-language formatting.

Solve the problem below by writing Python code.

Rules:
- The code must be self-contained — no imports beyond Python's standard library.
- Print the final answer to stdout.
- Do not include explanatory prose, only the code.

Problem:
"""
{{problem}}
"""

Python:

Your application code parses the response (it should be just code), runs it in a sandbox (e.g., a sub-process or a hosted code-execution API), and captures stdout. That's your answer.

Why PAL beats CoT for computational tasks#

Chain-of-Thought exposes reasoning in tokens. That works for logic and planning, where the model's limitation is single-pass attention, not arithmetic. For arithmetic specifically:

• CoT is unreliable. The model can correctly state "I need to multiply 847 by 326" and then produce the wrong number. Reasoning correctly about arithmetic doesn't make the arithmetic correct.
• PAL is exact. Once the code is correct, the result is correct. No probabilistic sampling, no accumulating errors.
• PAL is auditable. If something's wrong, you can read the generated code and find the bug. A wrong CoT answer requires you to re-derive the correct one to find the error.

Sandboxing is non-negotiable#

Generated code is untrusted. Even when you're sure the prompt produces deterministic, safe code, never run it in an environment that can:

• Access your network or file system
• Run for unlimited time
• Use unlimited memory
• Import arbitrary libraries

Production patterns:

• Hosted code-execution APIs. OpenAI's code interpreter, Riza, E2B, Replit's API. They run the code in isolated containers with sane defaults.
• WebAssembly sandboxes. Pyodide for in-browser Python execution — useful for client-side PAL.
• Sub-process with restrictions. Docker container, restricted user, no network, time-limit, mem-limit. Works but takes more setup.

When PAL pays off#

Going further: production patterns#

Modern tool-use APIs implement PAL natively#

OpenAI's code interpreter, Anthropic's tool use, and Gemini's code execution all let the model invoke a code-running tool as part of normal tool-use flow. You define a run_code tool; the model calls it when it decides math is the right approach. Cleaner than hand-rolled PAL prompts; same idea underneath. See agent tools.

Result explanation as a second pass#

If users want a natural-language answer, run a second LLM call that takes the original question + the code + the code's output and produces a friendly explanation. The user sees prose; the computation underneath is exact.

Fallback for code that errors#

Sometimes generated code crashes (syntax error, runtime exception, infinite loop). Pattern: catch the error, feed it back to the model with a "the code above produced this error; please fix it" prompt, retry up to N times. After N, fall through to plain CoT or surface the error to the user.

Pair with reasoning models#

Reasoning models (o1, o3, Claude with extended thinking, Gemini thinking) often produce cleaner, more correct code on the first try. PAL with a reasoning model is particularly powerful for complex multi-step computations — the reasoning model handles the planning, code handles the execution.

Common mistakes#

• Running generated code in your main process. Never. Sandbox always, even for "safe" prompts.
• No timeout on execution. A bad while True takes down your worker. Always cap execution time.
• Using PAL for non-computational tasks. Code can't write a poem. PAL is the wrong tool for subjective or pure-reasoning tasks.
• Trusting the code without checking the result. Generated code can have logic bugs that produce a confidently-wrong number. For high-stakes tasks, run a verifier (different model, sanity check on the output magnitude, etc.).
• Not parsing the response strictly. Models sometimes wrap code in markdown fences or add explanation. Strip these; or use a stop-sequence based prompt that ends right after the code block.

Quick reference#

What to read next#

For the broader pattern of LLMs invoking external tools, ReAct and agent tools. For the alternative when computation isn't the bottleneck, Chain-of-Thought. For per-model code-execution support, see the ChatGPT, Claude, and Gemini guides.