Skip to main content

flameox

Bounded local runtime evidence for coding agents.

Flameox coordinates profilers, benchmark tools, trace processors, and direct local targets. It gives an agent a short path from an explicit native artifact or live command to bounded evidence, while keeping preservation optional.

There is no workspace to initialize, flameox.toml, SQLite control plane, durable job to poll, or parent-directory discovery. Analyze existing artifacts by passing their exact paths and formats.

Quick start

uv sync --extra dev --extra memory --extra trace --extra cpu
uv run flameox mcp inspect
uv run flameox analyze artifact.preview /absolute/path/to/artifact.json
uv run flameox capture --provider direct --cwd "$PWD" -- python benchmark.py

The MCP server has no workspace or project binding:

uv run flameox mcp serve

Run the short global setup wizard through npm:

npx flameox@latest setup

Setup detects Claude Code, Cursor, OpenCode, Codex, Gemini CLI, and Google Antigravity, then asks which clients should use Flameox. It preserves unrelated client configuration and writes a Python 3.12 uvx launcher pinned to the exact Flameox release that ran setup. Restart or reconnect changed clients afterward. For automation, pass --client codex --yes, repeat --client, or use --all --yes; --dry-run reports the same global paths without writing them. Detection is never automation consent.

Explicit --provider selections prepare the exact version-pinned uvx environment in the saved launcher by resolving it once into uvx's cache; they do not create a persistent global uv tool installation. Each invocation declares the complete managed provider set for that launcher rather than adding to remembered state. Use --timeout-seconds for a slow cold resolution. System and vendor tools are diagnosed with external install guidance. Setup never initializes or mutates a project.

Authority model

explicit artifact paths / typed direct target
                    │
                    ▼
         bounded process-lifespan runtime
             │                │
             ▼                ▼
       inline evidence   session scratch/cache
                              │
                       explicit preservation
                              │
                              ▼
             user Flameox data directory

Analysis and unpreserved capture make no durable Flameox writes. Capture artifacts stay in bounded session scratch until preservation, least-recently-used eviction, or server shutdown. An evicted analysis_id returns EXPIRED_SESSION_ANALYSIS; preserve conclusions before relying on them. The first preserve_evidence call creates the user-level Flameox data directory and stores native bytes and a canonical evidence bundle by SHA-256. FLAMEOX_DATA_DIR overrides the platform default for isolation or another storage location. Flameox never edits project Git files.

The console-retention default is bounded diagnostics in memory, with explicit omission counts. Keep native artifacts when needed; retain full console output on disk only when it is the evidence, an oracle needs it, or the caller requests it. Preservation alone does not request full logs. See console retention.

Workload time and RSS budgets are optional: use target.budget in MCP or --workload-budget in CLI capture. They do not inherit analysis-worker limits; cancellation and storage protection remain active when no workload budget is set.

The agent owns hypotheses and narrative findings in its own notes. Flameox owns only observed inputs, effective requests, execution provenance, typed evidence, coverage, truncation, limitations, and optional immutable preservation.

MCP interface

The server exposes six operations. Read-only analysis and executing capture remain separate for accurate MCP effect annotations, while each accepts a discriminated capability request that retains capability-specific options and provider validation:

analyze              capture_and_analyze
prepare_providers    preserve_evidence
rescue_evidence      query_evidence

The two operation schemas advertise every capability's exact options and compatible providers. Analysis and capture have separate names and annotations because reading an artifact and executing a target are materially different effects. Tool search happens in the MCP client; Flameox does not require an additional catalog-search call.

For example, a bounded artifact preview calls analyze with the capability inside request and the response bound beside it:

{
  "request": {
    "capability_id": "artifact.preview",
    "sources": [{"kind": "path", "path": "/absolute/path/to/output.log"}]
  },
  "page_size": 100
}

capture_and_analyze uses the same outer shape, with target and provider added to request. Omit request.experiment for one run. Add an experiment design only when the capability supports paired cases:

{
  "request": {
    "capability_id": "artifact.preview",
    "target": {
      "argv": ["python", "benchmark.py"],
      "cwd": "/absolute/path/to/project"
    },
    "provider": {"kind": "direct"}
  }
}

When a result contains next_page, call its named tool with its arguments unchanged. Capture continuations use analyze; they never run the target again.

It exposes one resource template, flameox://evidence/{evidence_id}, for the digest-bound, redacted projection of the canonical immutable manifest. Full argv, environment values, working directories, and host paths remain available only through explicit local manifest inspection. Native artifact bytes are deliberately not available as MCP resources.

Direct capture accepts an argv array, an absolute cwd, bounded environment overrides, a compatible typed provider, capability-specific options, and an optional experiment design. Shell strings are never accepted. page_size is the only caller-facing response bound; process, memory, traversal, and storage ceilings remain server policy. Work belongs to the live MCP request, so progress and cancellation apply directly and no detached task survives a restart.

Managed external collectors such as py-spy execute from Flameox's uvx environment. In-process collectors such as coverage.py and Memray are verified in, and run with, the workload's declared Python interpreter. Flameox does not substitute one Python runtime for the other. When a capture reports a missing managed provider, prepare_providers prepares its version-pinned uvx environment and returns that same launcher for reconnection. The agent supplies the complete provider list it wants in that launcher; Flameox does not merge it with prior calls. Preparation does not modify the running MCP process. When the client must reconnect, the result returns a typed next_action with kind: "reconnect_mcp", an agent-facing message, and the launcher to use. The managed provider IDs are aiperf, memray, otlp, perfetto, py-spy, and torch. Host tools, drivers, and permissions are never installed or changed; the same result reports their setup guidance.

Comparison is intentionally a two-stage workflow. Flameox captures representative baseline and candidate summaries separately, optionally preserves them, and then passes both artifacts to an analyze call with the matching comparison request.capability_id: benchmark.compare, inference.compare, or kernel.compare. Those variants are intentionally absent from capture_and_analyze: experiment capture measures cases and reports an effect, but it is not a substitute for comparing explicit native artifacts.

Evidence quality

An investigation still follows:

symptom → capture or explicit artifact → bounded evidence → hypothesis
        → discriminating experiment → supported, refuted, or inconclusive finding

A profile supports exploration, not causality. Confirmatory claims require a representative target, declared metric and estimand, compatible identities, preserved samples, a practical threshold, and an appropriate semantic oracle.

See architecture, storage and evidence, interfaces, runtime safety, and investigations for the contracts.

Development

Flameox requires Python 3.12 or newer and uses the committed uv.lock.

uv run ruff check src tests tools
uv run ruff format --check src tests tools
uv run mypy src tests tools
uv run lint-imports
uv run pytest -q

The project is licensed under the MIT License.

Metadata

Release files for flameox 0.2.7

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for flameox 0.2.7
File Size Uploaded
flameox-0.2.7.tar.gz 15.9 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for flameox 0.2.7
File Interpreter ABI Platform
flameox-0.2.7-py3-none-any.whl Python 3 none any Details

Total release size: 16.2 MB

Release files / flameox-0.2.7.tar.gz

Download URL flameox-0.2.7.tar.gz
Size 15.9 MB
Tags Source
SHA-256 checksum
How to use checksums
7285259d3b7ec4dd08814eff6c35655fc054d560c61c6a9c9da7cf1e6d05a0aa
BLAKE2b-256 checksum
How to use checksums
8e491c8f4ddeced757078dc4c1608d376688be8adeb98c5b93e956757ef12e8f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.

Transparency log

Release files / flameox-0.2.7-py3-none-any.whl

Download URL flameox-0.2.7-py3-none-any.whl
Size 235.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
830ddca6ad3a31dbfbf3a4fa2adf833d57862a2b96bc09b8d356d3f722ffd515
BLAKE2b-256 checksum
How to use checksums
781ef55aa0798ad24ca3b3ed508a7552d56938d722f5d5d33fcfed56ad3409e5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.

Transparency log

Release history Release notifications | RSS feed

0.2.9

2 release files

0.2.8

2 release files

This release

0.2.7 This release

2 release files

0.2.6

2 release files

0.2.5

2 release files

0.2.4

2 release files

0.2.3

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.1.15

2 release files

0.1.14

2 release files

0.1.13

2 release files

0.1.9

2 release files

0.1.8

2 release files

0.1.7

2 release files

0.1.6

2 release files

0.1.5

2 release files

0.1.4

2 release files

0.1.3

2 release files

0.1.2

2 release files

0.1.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page