Tyler Gillam

Tyler Gillam is a software engineer who helped build DigitalOcean’s Inference Router, which selects language models for individual requests according to the task, cost, latency, and developer preferences. His work gives application builders practical controls over a consequential decision: which model should handle each step, and how to tell whether that choice improves the finished work.

Gillam’s engineering practice connects developer needs with product delivery. He meets developers, translates their problems into product ideas, and helps build and launch features. In inference routing, that means turning application requirements into settings developers can inspect, test, and revise. Code generation, bug fixing, and test writing can have different model pools and priorities, even within the same coding-agent session.

Opening up the routing decision

Gillam argues that automatic routing becomes frustrating when it behaves like a black box: a poor selection leaves the developer with little ability to improve the next decision. His approach emphasizes developer-controlled routing, with explicit task descriptions, eligible models, and selection policies that can change as a team learns what works.

DigitalOcean’s routing architecture combines Plano’s open-source proxy with a purpose-built routing model. Gillam helped build parts of the router, contributing to infrastructure designed to let developers inspect and adapt routing decisions without depending on an opaque, locked-in selector.

The configuration separates task matching from model selection. Developers describe a task in natural language, define the models eligible to perform it, and specify how to choose among them. A manually ordered pool can favor one model and fall back to another when it fails. A speed-oriented policy can instead select the model with the fastest recent responses. This makes preferences operational: they determine how requests move through the application.

Making routing measurable

Gillam’s practical contribution is especially clear in the coding workflow he configured inside OpenCode. He connected routing controls to evaluation and a working agent, making the consequences visible at several levels:

• Workload-specific correctness evaluation. Gillam showed a previously run evaluation that reported correctness scores of 90 percent for his router and 95 percent for the comparison model, alongside lower token usage and faster responses for the routed configuration. He used those results to move beyond judging whether an application looked convincing. Those reported scores describe that evaluation; they do not establish equivalent quality, and his suggestion that the difference fell within the judge’s margin of error was not independently established.

• Visible decisions inside coding workflows. His OpenCode setup built a spinning-wheel application, added unit tests, and wrote a README. An observability panel displayed matched tasks, selected models, token usage, and accumulating cost while the agent worked. Developers could see how different development steps triggered different routing choices and what those choices cost.

• Cost comparisons with bounded conclusions. The demonstration reported final session costs of 14 cents for the routed workflow and 44 cents for the comparison configuration. Gillam also compared the generated applications visually, treating that assessment as subjective. The example showed lower spending in that session; establishing a general savings rate or equivalent output quality would require broader evaluation.

Gillam emphasizes a continuing improvement loop: route requests, evaluate the resulting work, adjust the configuration, and repeat. His distinctive emphasis is on making model selection something developers can improve inside their own applications. Explicit controls provide ways to change behavior; evaluation helps determine whether those changes are useful.