EDA Bridge Runtime

Ask naturally. Reach the right EDA. Keep the work recoverable and verifiable.

简体中文 ·

One conversation can reach real, editable EDA results

Ask in normal engineering language. The vendor Bridge performs the ADS or AEDT work while Runtime keeps the selected target, purpose, retry identity, long-job receipt, timing, and evidence consistent across local and SSH execution.

Editable ADS result	Editable HFSS result

The retained public journeys built an ADS circuit, simulated 31 finite rows and freshly reopened its native DDS page; and built a three-layer HFSS layout with two ports, solved five frequencies and freshly reopened its native Report. Codex and Pi each completed each journey with one recoverable Runtime plan.

Model state you can inspect	The route that keeps it recoverable

These are real application-window captures from public synthetic projects, not mockups or Python replots. EDA Bridge Runtime is the shared, vendor-neutral path behind the vendor Bridges: it preserves execution continuity and evidence while ADS and AnsysEM Bridges retain version-specific runtime integration.

Capability is not measured by wrapper count. An Agent combines exact Context, version-matched official docs, and a small packaged Bootstrap Experience Library, then runs official vendor code through a governed transaction. High-frequency operations may remain as asset-bound compiled shortcuts to save tokens and reduce transcription errors; the shortcut never becomes the source of truth or the only route to that capability.

What this changes for an engineer

You want to…	Runtime makes sure…
Use normal language instead of assembling SSH commands	The selected local or remote connection is reused automatically.
Keep a long EDA task alive after a disconnect	The job is recorded before work starts and can be resumed by receipt.
Avoid repeating a mutation after a timeout or retry	The same request identity returns the existing run instead of blindly running again.
Know what happened and why	Each call records its concise purpose, observed Agent identity, phases, timing, result, and evidence links.
Switch between Codex and Pi Agent	Both use the same typed Runtime and vendor-Bridge contracts.
Work locally today and remotely tomorrow	Local and SSH routes follow the same protocol and safety rules.

What the public tests show

When the engineer is watching the open EDA application, small supervised edits stay in that same graphical process. The accepted ADS and AEDT paths apply a typed patch, read the changed object back immediately, preserve an exact retry without creating duplicates, and can roll back only that patch without saving.

Accepted live operation	ADS 2026 Update 2.1	AEDT 2026 R1
Warm edit	93–187 ms	296–453 ms
Create object(s) + readback	253 ms	937 ms
Exact replay, zero duplicate objects	3 ms	12 ms
Patch-local rollback	21 ms	204 ms

These are bounded functional observations from disposable projects on 2026-08-31, not a statistical vendor comparison. ADS reports end-to-end warm calls and Bridge round trips for object operations; AnsysEM reports warm live calls and adapter time. Both Codex and Pi Agent passed the create, replay, and rollback contract. The machine-readable source data and chart generator keep this public presentation tied to the retained evidence.

Complete journeys show where long-task time goes

The newest acceptance cases are complete user journeys, not isolated API calls. ADS started from an empty workspace, built and simulated a circuit, exported 31 finite rows, and freshly reopened an editable DDS page. HFSS 3D Layout started from an empty project, built three layers and two ports, solved five frequencies, and freshly reopened a native S-parameter report. Codex and Pi each completed each journey with exactly one Runtime plan.

Journey	Codex wall / Bridge + EDA	Pi wall / Bridge + EDA
ADS circuit → data → two-page DDS	40.594 s / 5.157 s	36.953 s / 5.157 s
HFSS layout → solve → report	242.657 s / 209.360 s	229.328 s / 202.641 s

These are the final frozen 2026-08-30 public baseline: one retained functional trial per Agent and EDA, not statistical speed claims. They show the useful boundary: the ADS engineering work took seconds, while the HFSS solve dominated the long workflow. Packet-level network time was not measured separately, but no dominant SSH command cost was observed.

The chart reports the frozen 2026-08-30 median wall time from six bounded public test cases, with three trials per Agent and task. Both Agents used the same Runtime and Bridge path. Agent-heavy tasks show the largest difference; AEDT-lifecycle-heavy work is dominated by the EDA itself. This is an engineering baseline, not a universal Agent ranking. See the full method, pass rates, and interpretation boundary.

The checked ladder covers documentation evidence, exact idempotent replay, typed ADS and AnsysEM work, a real generated-input Momentum solve, and a one-turn cross-EDA workflow. Sanitized acceptance evidence is maintained in Acceptance.

A separate 2026-09-01 ADS 2027 comparison tested the current Runtime MCP plus current Runtime/ADS Skills against the official ADS MCP with three fresh runs per Agent and case. Runtime passed 22/24 overall and all 18/18 knowledge runs; the official surface passed 18/24 overall and all 6/6 execution runs. Runtime's successful governed native batch had a 2.379 s median, but its Agent path was materially heavier. See the ADS adapter's audited method and data.

Start with one Agent profile

Install Runtime on the computer where the Agent runs:

python -m pip install "eda-bridge-runtime==0.1.0a39"
eda-runtime doctor

Create the isolated profile for the Agent you use:

eda-runtime agent-profile codex install
eda-runtime agent-profile pi install --help

The administrator selects vendor Skills and connection details once. Engineers then start the generated profile and speak naturally; they do not maintain SSH commands, metadata files, or Runtime logs by hand.

Install the matching vendor Bridge on each EDA host:

• ADS Agent Bridge
• AnsysEM Agent Bridge

If the Agent and EDA share one machine, register a local connection. If they are separate, register SSH. Both still pass through Runtime so audit, retry, target, and evidence behavior do not split into two systems.

Safety promises

• Every Agent-originated action carries a concise purpose.
• Mutations require a stable identity and are never blindly replayed.
• A disconnect does not imply that a long EDA job failed.
• Context tokens contain locators and fingerprints, never credentials.
• The append-only ledger stores fingerprints and bounded metadata, not chat transcripts or raw operation payloads.
• Vendor-specific behavior stays in vendor Bridges, not in the Runtime core.
• Advisory experience is hashed package data, never executable Markdown; its absence cannot block governed native execution.
• Runtime does not claim a solve, artifact, or persisted change without corresponding Bridge evidence.

Next

• add more vendor Bridges without changing the user's conversation pattern;
• make version-matched official APIs broadly reachable through one governed native execution and transaction envelope, without rebuilding vendor APIs as Bridge wrappers;
• make long-job recovery and evidence review easier to see;
• retain more complete, real engineering journeys across circuit, layout, EM, simulation, extraction, and native plotting.

Learn more

• How the pieces fit together
• How EDA capability grows without rebuilding vendor APIs
• Agent host, EDA host, and combined deployment
• MCP and Codex integration
• Pi Agent pilot
• Protocol schema
• Current scope

eda-bridge-runtime is public alpha software. Begin with disposable work and review the vendor Bridge's capability and evidence boundary before using it on important projects.