Home / Work / Prime
DEVELOPER TOOLING · IN DAILY USE

Ask in English.
Watch it plan.
Then run it.

Prime is a terminal agent written in Rust. You describe what you want; it proposes the shell actions that would achieve it, shows them, executes with live timing, and reads the output back. It carries persistent memory across sessions, tracks a task list, and pools multiple API keys behind a rotating provider so a rate limit never interrupts the work.

Type
Internal tooling — used daily
Language
Rust · async · single binary
Providers
Google AI Platform · Ollama (local)
Resilience
Key pool + rotating provider
State
Persistent memory · sessions · todo
Interface
Streaming box-drawn terminal UI
/ 01
The Problem

The most common developer workflow with a language model is the worst one: switch to a browser, describe the situation from memory, copy a command out, paste it into a terminal, and lose all context the moment the tab closes. The model never sees the actual machine, so its answers are generic.

Free and low-cost API tiers also rate-limit aggressively. A tool that dies on 429 halfway through a task is worse than no tool, because it fails at the point you were relying on it.

/ 02
The Approach

Prime lives in the terminal, where the work is. It knows the working directory and can run commands, so it answers from the actual machine state rather than from a description of it. Proposed actions are printed before they run — the interface makes the plan visible instead of executing silently.

Rate limits are handled by a key pool behind a rotating provider. Multiple credentials are held, and when one is exhausted, the next takes over transparently. The agent keeps working rather than surfacing a provider error to the user.

Responses stream token-by-token into a box-drawn terminal interface that shows execution state — "executing in 2s", "completed in 3.2s" — so a long operation is legible rather than a frozen prompt. Memory, sessions and a task list persist to a config directory, so context survives across invocations.

Provider choice is abstracted: a hosted model for capability, a local Ollama model when the work must not leave the machine. Same interface either way.

/ 03
The Hard Parts
  1. Parsing intent out of a stream Actions have to be extracted from a response that is still arriving, so the interface can render structure while text is mid-flight — without committing to an action that the model has not finished writing.
  2. Rotation that is invisible but not reckless Failing over between credentials must distinguish a rate limit from a genuine error. Retrying a malformed request across every key in the pool burns the whole pool for nothing.
  3. Terminal rendering that survives real terminals Box-drawing, live timing and streaming text have to behave across terminal emulators, widths and encodings — including Windows consoles, where assumptions from POSIX tooling quietly break.
  4. Memory that helps rather than misleads Persistent context is only useful if it stays relevant. Stale memory injected into a prompt actively degrades answers, so what is retained is deliberately narrow.
/ 04
The Outcome

A native binary that starts instantly and is used daily in our own work. Because it is Rust with no runtime, it installs anywhere without a Python environment or a Node toolchain.

Prime is also our proving ground for agentic patterns we deploy in client systems: streaming interfaces, provider abstraction, credential pooling with graceful degradation, and propose-then-execute flows where an action is visible before it happens. Those patterns are the difference between an AI feature that survives production and a demo.

Stack Rust Async / Tokio Streaming responses Provider abstraction API key pooling Ollama (local inference) Terminal UI Persistent session state

An agent that can't see your machine
is just an expensive search box.

AI THAT SURVIVES PRODUCTION

The demo always works.
The third week is the hard part.

Contact Us →