Skip to main content

​
Runtime overview

Asymptote supports fx, Vercel Labs’ native coding agent, by reading the session records fx commits to disk. fx is the one supported runtime with no third-party observation surface at all. Its lifecycle hooks are Zig handlers compiled into the binary rather than commands a settings file can point at, it ships no OpenTelemetry export, and its plugin story is MCP — which describes the tools fx calls, not what fx did. What it does have is a durable, append-only record of every session under ~/.fx/sessions, so Asymptote reads that.
There is nothing to install into fx and nothing to configure inside it. Collection is an action you run rather than a setting Asymptote writes, which is why fx has a command instead of a beacon endpoint hooks install --harness target.

​
Prerequisites

Before collecting fx telemetry, make sure:
  • fx is installed and has run at least once, so ~/.fx/sessions exists.
  • beacon endpoint install has run so shared endpoint config and runtime log paths exist.
  • Something runs beacon endpoint fx sync on a schedule, or leaves --watch running. Nothing sweeps on its own.

​
Collection path

Every fx event carries harness.collection_method=poll. Asymptote sees what a turn did once fx committed it, rather than observing the agent as it works. Stating the consequence plainly: nothing on this path can hold or deny a tool call, and nothing appears in the runtime log until the turn is committed. A sweep reads each session’s log only as far as the manifest’s committed watermark, so a frame fx is still writing is left for the next sweep rather than counted as corruption. The cursor stores both the sequence number and fx’s log generation, because fx restarts sequence numbers when it compacts a log; without the generation a compaction would look like a rewind and replay the session. Re-reading is safe. Each event’s dedup id comes from the record’s own coordinates — session, log generation, sequence, and position within the turn — not from its content, so the same fx record maps to the same event on every sweep. fx has no OpenTelemetry export and no hook or plugin file for Asymptote to write, so there is no OTLP path and no managed file for this runtime.

​
Discovery and status

Asymptote detects fx through the fx executable, and treats ~/.fx as an additional signal. fx installed through its setup script, a shell alias, or a per-user bin directory is often missing from the PATH the endpoint process inherited while its profile directory is still present. The Pi, Oh My Pi, OpenCode, Cursor, and Hermes probes use the same fallback.
Show fx discovery state
fx reports as the vercel_fx harness with capability session_log, which no other runtime has. The other capabilities describe something Asymptote writes into the runtime and the runtime then calls; fx offers nothing to write into, so there is no marker to check. That changes what “telemetry enabled” can honestly mean here: the only evidence telemetry is flowing is that a sweep has actually run and is level with the sessions on this machine. A session whose manifest cannot be read is reported as not caught up rather than assumed to be, because it cannot say how far fx has committed.

​
Install or configuration support

See beacon endpoint fx for the full flag reference. --print is a dry run in both directions: it neither writes the runtime log nor advances the cursor, so running it twice shows the same events and running it does not quietly consume the work a later real sweep would do.

​
Telemetry coverage

​
Data handling

fx content is handled like every other runtime. Prompts, assistant replies, tool arguments, commands, command output, paths, and diffs are retained in local or customer-controlled logs, with local secret redaction and per-string limits applied before writing, and a hash and byte count on each content-bearing event. Events over the 64 KiB limit drop raw and retained content, preserve stable metadata, and set field_truncated. The sweep is local and offline. It reads files already on this machine and writes the runtime log; nothing about it reaches the network.

​
Known gaps

  • No approvals. fx persists permission feedback as text rather than a per-call decision, so there is nothing to record as an approval. Asymptote does not synthesize one, matching the Cline and Pi posture.
  • No session end. fx sessions are resumable, so there is no point at which fx declares one over. Asymptote does not invent a session.ended for a session that may be resumed tomorrow.
  • No enforcement, and none possible on this path. A poll sees a committed record. Even the optional, off-by-default policy provider seam (BEACON_POLICY_PROVIDER) has nothing to attach to here, because the tool call already ran.
  • Events land a turn late. fx commits a turn when it finishes, so telemetry arrives at turn granularity rather than as the agent works, and no sooner than the next sweep.
  • Nothing sweeps automatically. beacon endpoint fx sync runs when you run it. Schedule it, or leave --watch running, or the runtime log stops at the last sweep.
  • Unknown record kinds are skipped by name. A kind fx adds later is skipped as unknown rather than mistaken for one Asymptote maps, so new fx behavior needs a Beacon update before it appears.

​
Deployment notes

Confirm discovery sees the runtime, preview what a sweep would emit, then sweep and check the log:
For continuous collection, run the sweep under whatever scheduler the platform already uses — a launchd agent, a systemd timer, a Scheduled Task, or a cron entry — or leave beacon endpoint fx sync --watch running in the operator’s session. The interval floor is 5 seconds; a sweep re-reads each changed session’s log, so a very short interval spends real work to shorten a window fx’s own commit latency already bounds.

beacon endpoint fx

Flags, output, and cursor behavior for the sweep.

Supported agent harnesses

Return to the runtime support overview.