List every language codecalc can execute, with extension, compile flag, and what this machine resolved. status is installed (its command was found on the sandbox PATH) or supported (nothing for it here); status_basis is resolved, meaning nothing was executed to check. Run codecalc doctor --deep to promote a runtime to available by actually running it.

tier is a DIFFERENT axis from status: status says whether THIS machine resolved the command (resolution); tier says whether codecalc's own CI has actually executed this language and asserted on its output (reliability) — tested, best_effort (declared, plausibly works, never CI-checked), or plan_only (never validated anywhere). A language can be installed here and still be best_effort or worse — that combination is exactly "the toolchain resolved and may still be broken".

List execution providers (execution BACKENDS — local subprocess, gVisor-strict, remote) and their machine-readable capabilities.

This is about which BACKEND runs your code, not which LANGUAGE it runs — a provider's ready/strict fields are resolution facts about the backend itself. Per-language reliability (how much codecalc's CI has actually verified a given language's toolchain, vs merely resolved it) is a separate axis reported by list_languages/runtimes_status/codecalc doctor as tier; a ready provider says nothing about whether a specific language running through it has ever been execution-tested.

Execute code in language in a sandbox.

Returns stdout, stderr, exit_code, duration_ms, cpu_ms, peak_memory_kb, verdict (OK/TLE/MLE/OLE/RTE).

• session_id: run inside a session workspace (see session_start); with a stateful session (python3/node) interpreter state persists across calls.

• max_memory_mb / max_cpu: per-call resource ceilings.

• max_output_kb: raise/lower the stdout cap (default 64 KiB).

• no_net: block network egress. Linux: enforced in-kernel via a seccomp-bpf filter. macOS / no-seccomp kernel: best-effort symbol shim, disclosed in unenforced when that's the only guarantee that held. See SECURITY.md.

• compact: drop the diagnostic fields (timings, workdir, platform). Never drops unenforced or output_error — if a guarantee you asked for was not applied, a compact result still says so.

With session_id set and max_output_kb left at its default, output that would otherwise be truncated is instead SPILLED: the inline stdout/stderr still carry the same truncated prefix as before, and stdout_spill/stderr_spill name a codecalc://session/{sid}/files/... resource carrying the fuller stream (session_read_file or the resource route reads it back) — capped at 4 MiB, ..._spill_capped: true if even that was not enough to hold everything. Passing an EXPLICIT max_output_kb is honoured as a literal ceiling with no spill, same as before. Session-LESS runs (no session_id) have no workspace to spill into and keep the old truncate-and-drop behaviour.

Start a persistent session. python3/node get a stateful REPL worker (variables/imports persist across execute_code calls); other languages get a persistent workspace directory. Returns session_id.

Stop a session: kill its REPL worker (if any) and delete its workspace.

List active sessions and their languages/state.

List workspace files, optionally using a bounded cursor page.

Write a file into a session workspace (relative path, no escapes). Use this to seed input data for executed code.

List files created by executed code in a session (excluding runner internals like main.py/run.out).

Install a package for a language (uv pip / npm / gem / go get / cargo add...).

With session_id, installs into that session's workspace so executed code can import it. Without, installs into a shared cache.

NETWORK: yes, always. The package manager fetches from its registry (PyPI, npm, rubygems, crates.io). codecalc opens no socket itself; the child process does.

NOT SANDBOXED: the installer runs as a direct subprocess of the server, so install-time hooks (npm postinstall, Python build backends, Cargo build scripts) execute with the server user's filesystem access. The environment is still restricted to the allowlist, so secrets do not leak, but the filesystem is not confined. Do not point this at untrusted input. See SECURITY.md.

Execute code and STREAM progress + partial output as it runs.

Unlike execute_code (which returns only at exit), this reports progress notifications to the client while the program runs, so agents can see output before the process finishes. Returns the same result shape and applies the SAME ceilings: max_memory_mb, max_output_kb and max_cpu are forwarded to the executor exactly as execute_code forwards them.

One difference, deliberate: the wall-clock cap is 300s here against execute_code's 120s, because streaming exists for runs long enough to want progress.

Submit code for BACKGROUND execution; returns a run_id immediately.

Same request shape as execute_code (minus session_id: a run is a standalone process, not a session workspace). The work proceeds on a background worker; poll it with run_inspect(run_id) and, if needed, stop it early with run_cancel(run_id).

Use this instead of execute_code when you would rather not hold an MCP call open for the whole computation. timeout is still the WORK's own deadline (same 120s ceiling as execute_code) — it bounds the run, not how long you wait to collect it.

Admission is capped (CODECALC_MAX_ACTIVE_RUNS, default 64): past that many runs still running/cancelling at once, this returns a resource_exhausted error rather than growing without bound — call run_inspect/run_cancel to make room, or wait for one to finish.

Retention: see run_inspect.

Poll a background run started with run_submit.

While running: {"ok": True, "state": "running"|"cancelling", "run_id", "provider_id", "started_at", "deadline"}.

Once terminal (state "finished"/"cleaned"/"recovered"), this returns the SAME result shape execute_code returns — stdout/stderr/exit_code/ verdict/unenforced/provider (the interface_version/provider_id/limits receipt)/... — merged with a small set of run_* extras (run_id, provider_id, started_at, deadline, state, cleaned; see server.py's _RUN_EXTRA_KEYS). Read ok and verdict on a terminal result to tell a clean finish from a failure; a run stopped by run_cancel is only reflected there for a provider that actually supports cancellation (see run_cancel's own docstring) — check the result the same way you would any other run.

Retention: a finished run's result stays inspectable for the life of this server process — call this as many times as you like; nothing is consumed by reading it. What IS released on the first terminal read is the PROVIDER's own resources for that run (RunSupervisor.cleanup(), idempotent on repeat calls) — the in-memory record of the run itself is not evicted; there is no cap or TTL on it here, deliberately: the durable state machine, leases and TTL-based eviction are out of this residual's scope (see run_supervisor.py's own docstring). A long-lived server that calls run_submit very many times will grow this table; the on-disk crash-recovery journal underneath it is already bounded (RunSupervisor.max_completed), independent of this.

Cancel a background run started with run_submit.

Idempotent: calling this on a run that is already finished/cleaned reports cancelled: false, state: <its actual terminal state> rather than erroring — matching execute_code's own "no partial result" rule, there is nothing partial to hand back either way.

Propagation depends on the SELECTED PROVIDER (see list_execution_providers' cancel capability). The built-in local provider does not support stopping a run once it has started; that is reported honestly here rather than silently pretended to have worked — the computation keeps running to completion and its result stays available via run_inspect, so bound it in advance with run_submit's own timeout instead. A provider that DOES advertise cancel: true reaches the full spawned process tree the same way execute_code's own cancellation does — RunSupervisor already owns that; this tool only calls it.

Symbolically evaluate or simplify a math expression, e.g. 'integrate(x2, x)' or 'sqrt(144) + 210'.

Build the truth table for a boolean expression: 'a and b or not c', 'p xor q', 'a implies b'.

Check an SMT-LIB2 formula with Z3: sat/unsat/unknown plus a model. Example: '(declare-const x Int)(assert (> x 5))(check-sat)'.

unsat is graded solver_proven — see grade_basis for the engine version and timeout bound it was decided within. sat is graded ungraded: it's a real decided answer, just not a proof — reserving solver_proven for unsat means a counterexample can never wear a proof grade. unknown carries no proof either way and is also graded ungraded.

Solve a system of equations; system is ';'-separated equations, variables comma-separated. Example: system='x + y = 10; x - y = 2', variables='x, y'.

Structured matrix operations: det, inverse, eigenvalues, transpose, rank, trace.

evaluate_expression refuses Matrix([[1,2],[3,4]]) on purpose — [/] are denied there to block subscript-based RCE escapes, and a matrix literal is collateral from that (correctly aimed) screen. This tool is the structured replacement: rows is a JSON array of arrays (row-major), never a string to parse. Each entry is either a JSON number, used directly, or a scalar expression string ('1/2', 'sqrt(2)', 'x+1'), screened per-entry the same way evaluate_expression screens its input before anything reaches SymPy. op is one of det/inverse/eigenvalues/ transpose/rank/trace. Example: rows=[[1,2],[3,4]], op='det' -> -2.

Estimate the asymptotic (Big-O) time complexity of a code snippet via structural analysis.

Empirically measure time complexity by running code at increasing input sizes.

Contract: the code must read an integer N from stdin (first line) and do work sized by N. codecalc runs it at each size in sizes (comma-separated) and fits the growth curve to estimate Big-O (O(1), O(log n), O(n), O(n log n), O(n^2)...). Example python: 'import sys\nn=int(sys.stdin.readline()); s=0\nfor i in range(n): s+=i\nprint(s)'

Run the same code in multiple languages side by side.

snippets maps language name -> code (each snippet must be valid in its own language). Returns per-language stdout/stderr/exit/duration plus which was fastest. Example: {"python3": "print(67)", "node": "console.log(67)"}

Check every language runtime for available updates (NON-MUTATING).

Reports current vs latest version per language, which package manager owns it (mise/rustup/swiftly/apt/npm/uv), and the exact command that would run. Optional languages = comma-separated subset, e.g. "python3,node,rust".

Each entry also carries tier (registry.RELIABILITY_TIERS) — see list_languages for what tested/best_effort/plan_only mean. A current, up-to-date toolchain can still be best_effort: tier is orthogonal to whether the update check below found a newer version.

NETWORK: yes. Non-mutating refers to this machine's runtimes, not to traffic — each package manager is asked what the latest version is, and they answer by contacting their own remote index.

Update language runtimes. SAFE BY DEFAULT: with apply=False this is a dry run — it returns the update commands that WOULD run without changing anything. Pass apply=True to actually execute them (mise up, rustup update, swiftly update, apt-get upgrade of language packages, npm -g update, uv tool upgrade). languages = comma-separated subset; empty = all.

PRIVILEGE: the apt manager updates system packages and its command begins with sudo. Those commands do NOT run unless the HOST has set CODECALC_ALLOW_RUNTIME_APPLY=1; without it they are reported as skipped with ok: false and the variable named, and the rest still run. Every entry carries an elevated flag either way. mise/rustup/swiftly/npm/uv touch user-owned toolchains and are never gated.

NETWORK: yes, on both paths. apply=False still asks each manager what the latest version is, which is a remote lookup; apply=True additionally downloads and installs. "Dry run" bounds what changes on disk, not what is sent.

Read a file from a session workspace.

Text files return content. With as_image=True (or for image files), the file is returned as an inline image the model can see. Use session_files to discover paths; session_artifacts lists what executed code produced.

Run a multi-file program in a session: execute entry_file, which may import other files already in the session workspace (helper.py, data/...).

Runs as a fresh process in the session workdir (not the REPL worker), so relative imports and data files resolve. Returns stdout/stderr/verdict plus the entry file's path. Oversized output spills into the session workspace the same way execute_code's does — see its docstring for stdout_spill/stderr_spill.

Convert a value between units (dimensional analysis via sympy).

Supports metric/imperial length, mass, time, speed, energy, power, force, pressure, temperature (°C/°F/K), volume, area, data sizes, frequency. Examples: ('60','mph','km/h'), ('100','celsius','fahrenheit'), ('1','gb','mib'). Use list_units for the full alias table.

Look up a physical constant (speed_of_light, planck, avogadro, gravity, electron_mass, gas_constant, ...) or list all 22 with values.

List every supported unit alias for convert_units.

EXACT arithmetic: 0.1 + 0.2 == 0.3 is True here (False in plain Python).

Everything is an exact rational, integers are arbitrary precision. Supports

• • • / // % ** comparisons, bitwise ops (& | ^ << >> ~) on integers, and whitelisted math functions (sqrt, log, sin, ...) plus pi/e/tau. Use BEFORE asserting any computed number: thresholds, ratios, overflows, 'X is N% of Y'. Examples: '2**64 - 1', 'comb(52,5)', '0.1+0.2 == 0.3', '0xff & 0x0f'.

Exact threshold check with a verdict and the shortfall when it fails.

a OP b with op in ==, !=, >, >=, <, <= (= accepted for ==). Both sides are evaluated exactly and printed as fractions — a threshold comparison written out cannot be gotten backwards. Example: ('1/25', '>', '0.05').

Exact share and percentage of PART / TOTAL (rationals accepted).

mean, median, sample stdev, and coefficient of variation (CV).

CV > 0.2 means run-to-run noise swamps the effect being measured — the numbers cannot be compared across runs.

p50/p90/p95/p99 by nearest-rank AND linear interpolation.

Warns when n < 100 that p99 is just the maximum wearing a label.

Birthday-bound hash collision probability: 1 - exp(-n^2 / (2*2^b)).

Sizes hashes: 1e6 items into 64 bits is ~2.7e-8; 1e5 into 32 bits is ~0.69 — the answer to 'can I truncate this to 8 hex chars?' (no).

Byte sizes both ways: binary (KiB/MiB/GiB) AND decimal (KB/MB/GB).

The 1024/1000 gap is where '291 MB' and '277 MiB' silently disagree by 5%.

Humanised duration plus per-day and per-30d rates.

Epoch seconds/millis/micros/nanos to ISO 8601 UTC (implausible readings suppressed).

hex/oct/bin of N; with WIDTH, two's complement and signed-overflow detection. base_repr(3000000000, 32) says plainly it does not fit i32.

Convert a value between ANY bases 2..36, fractions included; bases that cannot represent the fraction (e.g. 0.1 in base 2) are flagged non-terminating. radix_convert('zz', 36, 7) is one call.

What binary64 actually stores for X: exact value, raw bits, ULP, both neighbours, and whether the literal is representable. float_repr(0.1) shows 0.1000000000000000055511151231257827...; float_repr(0.25) says EXACT. Above 2^53 warns consecutive integers are indistinguishable.

Which widths (i8..i64/u8..u64) hold N, and the wrapped value where they do not. Flags anything past 2^53 as unable to round-trip through a JS number or JSON float. int_widths(3000000000) shows the i32 wrap.

popcount, bit length, trailing zeros, power-of-two check, next power of two, and (with align) padding needed to reach an alignment boundary.

Programmer-mode bit ops: and or xor nand nor xnor not shl shr sar rol ror at width 8/16/32/64. Every result shows unsigned, signed (two's complement), hex, octal and binary. shr is logical (zero-fill); sar is arithmetic (sign-propagating) — 0x80 shr 1 = 0x40 (+64) but 0x80 sar 1 = 0xC0 (-64). A left shift that drops bits says OVERFLOW and shows the unbounded answer.

Are two expressions algebraically identical? Refs: 'is (ab)/c the same as a(b/c)?' answered exactly. Caveat: symbolic identity says nothing about float rounding, integer truncation or modular overflow.

Solve for a root or crossover: 'x**2 - 4 = 0', '2*x + 1 = 7'.

Asymptotic behaviour: limit of EXPR as var -> point (default oo). 'limit_expression("n*log(n)/n**2", "n")' returns 0 — settles complexity arguments faster than arguing.

Simplified, factored and expanded forms of an expression.

PROVE that a port is equivalent: run both programs, compare their output.

You write the translation — you are the language model. This runs your source and your port on the same inputs and reports, per input, whether they matched, diverged, or could not be compared (a runtime that is missing or a program that failed on both sides is INCONCLUSIVE, never a pass).

Use it after porting anything: python3 -> go, node -> rust, a rewritten function against the original. Pair with compare_edge_cases to find the inputs worth testing.

A pass is graded cross_checked (two independent implementations, run and agreeing — see grade_basis for which runtimes). A non-pass is graded ungraded: never a softer positive grade.

Run the same logic in N languages on edge-case inputs and flag divergence.

snippets maps language -> code (provide a correct snippet per language; write one per language). Default inputs cover empty, zero, negative, and float-precision cases: ['', '0', '1', '-1', '10', '100', '0.1\n0.2']. Returns a per-input matrix plus a divergences list where languages disagree on identical input.

PROVE an optimisation: same outputs, and measurably faster.

You write the optimised version. This runs both against the same inputs to confirm they still agree, then TIMES both at increasing sizes and compares. Accepted only if equivalent AND at least min_speedup faster.

A rejection tells you which gate failed and by how much — "correct but only 1.09x" is the answer an optimiser that fabricates wins cannot give. A candidate that is faster but wrong fails the first gate, and its speed is never measured, because a faster wrong answer is not an optimisation.

An accepted result is graded cross_checked (see grade_basis for the runtime and the measured speedup). A rejection — wrong OR merely not faster enough — is graded ungraded: correctness alone does not earn a grade for the optimisation claim this tool exists to answer.

Extract a named function (with its imports + referenced helpers) into a standalone program and run it in the sandbox.

python3 gets exact ast extraction; other languages best-effort block extraction (pass call to execute non-python). Returns the extracted program and per-input runs.