Koosha ParidehpourSystems / products / infrastructure

Koosha Paridehpour / Product

Leads cross-functional execution, ships commercial outcomes, owns product economics end-to-end.

I lead cross-functional execution from ambiguous initiative to working product. My work spans hardware launches, international distribution, and AI product strategy.

WITF Board / historical

product studies

Hardware launches, distribution, and outcomes — ordered by commercial impact.

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

Community signal, launch economics, and supplier readiness converged in ~4,900 sold line items.

~$432Krevenue in 30 dayscanonical user fact
systems

Runtime topology

ShareCLI

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

Coding-agent concurrency stops being hidden machine pressure and becomes an operable developer workflow.

ai-infrastructure

Policy routing sheet

Substrate

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

Explicit failure and budget controls make a multi-provider execution surface governable instead of one opaque adapter.

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.

A constrained research fork shortens the loop for comparing local-inference choices on Apple Silicon without overstating production readiness.

simulation

Simulation field note

NetWeave

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

A one-week prototype made the system tradeoff visible: individually attractive routes can degrade aggregate network flow.

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.

101 merged pull requests across 21 upstream releases, with maintainer acknowledgement, inside a 28-day contribution window.

21upstream releases naming contributionsrelease notes audit