Koosha ParidehpourSystems / products / infrastructure

Koosha Paridehpour / Engineering

OS-adjacent runtimes, agent infrastructure, distributed backends, and compiler-/kernel-aware engineering.

I work at the systems boundary — where process management, provider routing, and runtime constraints shape what software can actually do.

Technical domains

Systems & Runtime

OS-adjacent runtimes, process management, FUSE, Tokio async runtimes

Distributed Backends

Provider routing, circuit breakers, SSE streaming, budget enforcement

AI / Agent Infrastructure

Multi-provider dispatch, agent orchestration, MCP tooling, observability

Performance & Tooling

Rust performance cores, speculative decoding, evaluation harnesses

WITF Board / historical

engineering studies

Systems, runtimes, and infrastructure — ordered by technical depth.

systems

Runtime topology

ShareCLI

Rust runtime that observes and coordinates hundreds of concurrent AI coding agents: process bursts, resource contention, and filesystem behavior.

Process observation, queueing, coalescing, and optional FUSE views make burst contention inspectable at the host boundary.

ai-infrastructure

Policy routing sheet

Substrate

Multi-provider routing layer holding provider failures, budgets, and rate limits at one policy boundary across four interfaces.

One policy boundary coordinates provider health, rate limits, retries, fallbacks, budgets, and auditable execution across four interfaces.

ai-ml

Fork-delta experiment

phenotype-omlx

Apple Silicon inference research fork with Rust performance cores, multi-backend routing, and evaluation tooling for comparing local model variants.

The experiment boundary keeps upstream MLX functionality distinct from fork-added multi-backend routing, Rust performance cores, and evaluation paths.

simulation

Simulation field note

NetWeave

Traffic simulation where independently optimal routes produced network-wide congestion: local decisions degrading global flow.

Directed-graph routing handles strategic movement while disjoint cellular automata expose lane-level congestion, waves, and gridlock.

physical-product

Material artifact

GMK Arch

Arch Linux keycap set I designed and shipped: ~4,900 sold line items across a 10-region retail network in 30 days, ~$432K revenue.

Transparent GMK Arch wordmark specimen with a pale ARCH letterform and teal Arch Linux and GMK marks.
physical-product / historical

Kitting coverage, manufacturer constraints, and a 10-region vendor network shaped one coordinated release.

~4,900sold line itemscanonical user fact
ai-infrastructure

Upstream routing overview

OmniRoute

Routing intelligence, provider integrations, and reliability hardening for a 60K-star AI routing platform: 101 merged PRs in 28 days.

OmniRoute / routing plateConceptual model
OmniRoute conditional routing overviewConceptual routing overview, not a universal execution trace or live telemetry. Direct-model and combo strategies differ; fallback depends on eligibility, error classification and configured limits. Request -> Target selection: resolve the requested model or configured combo. Target selection -> Provider execution: select an eligible target and connection; provider breaker, connection cooldown and model lockout have distinct scopes. Provider execution -> Response: a successful attempt returns a response. Provider execution -> Failure state: classify an unsuccessful attempt; not every error changes every failure mechanism. Failure state -> Target selection: eligible fallback or bounded retry only when policy permits. Failure state -> Response: stop or exhausted attempts return an error; fallback is not guaranteed.RequestTarget selectionProvider executionResponseFailure state
  1. Request
  2. Target selection
  3. Provider execution
  4. Response
Failure state

Execution failure: eligible fallback or bounded retry returns to selection. On stop or exhausted attempts, return an error response.

  • Request / response path
  • Conditional failure path
OmniRoute / upstream routing overview. Failure paths are conditional; dashed in the diagram.

Conceptual routing overview, not a universal execution trace or live telemetry. Direct-model and combo strategies differ; fallback depends on eligibility, error classification and configured limits.

Read routing paths
  1. Request -> Target selection: resolve the requested model or configured combo.
  2. Target selection -> Provider execution: select an eligible target and connection; provider breaker, connection cooldown and model lockout have distinct scopes.
  3. Provider execution -> Response: a successful attempt returns a response.
  4. Provider execution -> Failure state: classify an unsuccessful attempt; not every error changes every failure mechanism.
  5. Failure state -> Target selection: eligible fallback or bounded retry only when policy permits.
  6. Failure state -> Response: stop or exhausted attempts return an error; fallback is not guaranteed.

Fallback cooldowns, latency-optimized routing, and fallback-cache scoping by target URL hardened dispatch under provider degradation.

101merged pull requestsupstream PR history