DEV Community: Mikołaj Badyl

Run Coding Agents on a Server, Check from Your Phone

Mikołaj Badyl — Thu, 03 Sep 2026 19:08:04 +0000

Where to run the agent

A coding agent like Claude Code or OpenCode needs a machine that stays on all the time. You do not need a powerful or expensive computer. The agent itself is light because the heavy work happens over an API. A small cloud server with 2 CPU cores and 4 GB of memory costs about 5 USD per month. You can also use a used mini PC, a Raspberry Pi, or even an old laptop.

Pick a Linux system you know. Ubuntu 24.04 LTS is a good choice because it is stable and well supported. Install Python, Git, and the agent software. The agent will ask for an API key. To get the key, open a browser on your laptop, log in to the agent’s website, and copy the key. Then paste it into the terminal on the server.

Start the agent once to check it works. Run a simple command like ./agent --version. The agent should print its version number. Then close the SSH session. The agent should keep running. If it stops, you need a way to keep it alive. A tool like systemd or tmux can help. For example, create a systemd service file:

[Unit]
Description=Coding Agent
After=network.target

[Service]
User=agentuser
WorkingDirectory=/home/agentuser/agent
ExecStart=/usr/bin/python3 /home/agentuser/agent/agent.py
Restart=always

[Install]
WantedBy=multi-user.target

Save the file as /etc/systemd/system/agent.service. Then run:

sudo systemctl daemon-reload
sudo systemctl enable agent
sudo systemctl start agent

Now the agent will start automatically when the server boots. It will also restart if it crashes.

The phone problem

A phone is not a laptop. It has limits that make SSH hard to use.

The screen locks after a few minutes. When the screen locks, Android may freeze or kill background apps.
The network changes often. It switches from wifi to mobile data, or from one wifi network to another. Each switch can break the connection.
The app freezes when it goes to the background. Android does this to save battery. A plain SSH client loses the session when this happens.

The usual fix is tmux. Install it on the server. Start a tmux session. Run the agent inside it. If the connection drops, tmux keeps the process alive. When you reconnect, tmux attaches you back. But tmux has problems:

You must install it on every server you use. If you forget, the session dies.
You must remember to start a session. If you run the agent without tmux, it stops when the connection drops.
tmux has its own commands. You must learn them to use it well.

Keep the session alive without tmux

A small helper program can do what tmux does, but without setup. The helper is called termphin-agent. It is a Rust program, about 490 KB for Linux arm64 and 540 KB for Linux x86_64. You upload it to the server over SSH. It runs in the background and keeps the shell alive.

Here is how it works:

You start an SSH session from your phone.
The app uploads the helper to the server. It puts the helper in ~/.termphin/agent.
The helper starts a new shell. The shell runs inside the helper.
If the connection drops, the helper holds the session. It keeps the shell alive.
When you reconnect, the helper reattaches you to the same shell. The screen state, cursor position, and scrollback are all there.

The helper is optional. Without it, the app works as a plain SSH client. But with it, you do not need tmux.

There are failure cases. The helper can crash or be killed. If the server runs out of memory, the Linux kernel may kill the helper. If the server reboots, the helper stops. To handle these cases, the app checks if the helper is running when you reconnect. If the helper is not running, the app starts a new session.

What a coding agent needs from a terminal

A coding agent shows diffs, spinners, progress bars, and full-screen text interfaces. A plain SSH client often gets these wrong. The terminal must render:

Box-drawing characters. These are used for tables, menus, and borders.
Colours. These are used for syntax highlighting, diffs, and status messages.
Cursor movement. This is used for spinners, progress bars, and interactive prompts.

If the terminal does not render these correctly, the output looks broken. For example, a diff may show as a wall of text instead of aligned lines. A spinner may jump around instead of spinning smoothly.

Termphin uses a real native terminal engine. It is drawn by Flutter, not a browser. The engine is a fork of the Dart package xterm version 4.0.0. It is open source under the MIT license. This means full-screen text user interface programs render correctly.

Read a diff on a small screen

A diff can be long. On a phone, you scroll. But the terminal must keep the lines aligned. If the rendering is wrong, the diff is unreadable.

Here is an example of a diff that works:

--- old_file.txt
+++ new_file.txt
@@ -1,5 +1,5 @@
 Line 1
-Line 2
+Line 2 updated
 Line 3
 Line 4
 Line 5

The - and + signs must line up. The colours must be clear. The font must be readable at small sizes.

To make diffs readable on a phone:

Pick a font like Fira Code or JetBrains Mono. These fonts have clear shapes and good spacing.
Adjust the line height. A value of 1.2 to 1.4 works well.
Adjust the padding. A value of 4 to 8 pixels keeps the text away from the edges.
Use a colour scheme that works in daylight and at night. For example, Solarized Dark or Gruvbox.

If the diff is still hard to read, zoom in. The app lets you pinch to zoom. You can also change the font size in the settings.

Answer an agent prompt that needs a key press

Some agents ask for a key press to continue. For example:

The agent is ready. Press Enter to proceed.

On a phone, you do not have a physical keyboard. A toolbar with special keys helps. The toolbar has keys like Esc, Tab, Ctrl, and the arrow keys. You can tap these keys instead of typing them.

The toolbar is customizable. You can save different layouts for different tasks. For example:

A layout for coding agents. It has Esc, Tab, Ctrl, and the arrow keys.
A layout for plain SSH. It has Page Up, Page Down, and function keys.

To create a layout:

Open the toolbar settings.
Tap the + button to add a new layout.
Drag keys from the palette to the toolbar.
Save the layout.

The toolbar can float or dock. In portrait mode, it floats. In landscape mode, it docks to the side.

Send a file from the phone into the agent

An agent may ask for a file. For example:

Upload the config file to /home/user/config.yaml

On a phone, you pick the file from the file browser. The app uploads it to the server and inserts the path into the prompt.

The file browser is built in. It works like a local file manager. You can:

Walk the server’s filesystem.
Preview images, text files, and code.
Open files in a syntax-highlighted editor.
Upload files from your phone to the server.
Download files from the server to your phone.

To upload a file:

Open the file browser from the app.
Navigate to the folder where you want to upload the file.
Tap the + button and select Upload.
Pick a file from your phone.
The app uploads the file and shows the path.

The editor supports syntax highlighting for many languages. It also has line numbers and basic formatting. You can edit a file and save it back to the server.

Run the same saved command on several machines

You may run the same agent on several servers. Instead of typing the command each time, save it as a snippet. A snippet is a saved command with a name. You can run it on any machine with one tap.

For example, save a snippet called start_agent:

cd ~/agent && ./agent.py --config config.yaml

To run the snippet:

Open the snippets menu.
Tap the snippet name.
The app pastes the command into the terminal and runs it.

The app remembers the run history. It shows the exit code and the time. If the command fails, you can see why.

You can also edit or delete snippets. For example, change the config file path or add a new flag.

Reach a dev server the agent started through a tunnel

An agent may start a dev server on a random port. For example, a web server on port 3000. To reach it from your phone, set up a tunnel. The tunnel forwards a local port on your phone to the server’s port.

For example, forward port 8080 on your phone to port 3000 on the server:

Open the profile for the server.
Go to the Tunnels section.
Tap Add Tunnel.
Set Local Port to 8080 and Remote Port to 3000.
Save the profile.
Connect to the server. The tunnel starts automatically.

Now open a browser on your phone and go to http://localhost:8080. You should see the dev server.

You can also set up tunnels on the fly. For example, if the agent starts a server on port 4000, create a new tunnel without editing the profile.

Safety rules for letting an agent run while nobody is watching

An agent runs code. It can make mistakes. Set limits to reduce risks.

Use a dedicated user account. Do not run the agent as root. Create a user like agentuser and run the agent under that account.
Set a memory limit. For example, 2 GB. Use systemd or cgroups to enforce the limit.
Set a CPU limit. For example, 50% of one core. This prevents the agent from using all CPU.
Use a firewall. Only allow connections from your IP. For example, use ufw:

sudo ufw allow from your.ip.address to any port 22
sudo ufw enable

Check the logs often. The app can show the last lines of the session. You can also log the session to a file:

script -f /home/agentuser/session.log

Then run the agent inside script. The log file will record everything.

Use SSH keys instead of passwords. The app stores keys in an encrypted vault on your phone. The vault is protected by a PIN or fingerprint.
Verify host keys. The app checks the server’s host key before connecting. It fails closed if the key does not match. You can pin the key in the settings.

One honest option among others

I built Termphin, an SSH client for Android, to solve these problems. It is a native app, not a WebView or a browser wrapper. The terminal engine is a fork of the Dart package xterm version 4.0.0. It is open source under the MIT license. The Android app itself is not open source.

Termphin keeps sessions alive without tmux. A small helper agent runs on the server and holds the session. If the connection drops, the helper keeps the shell alive. When you reconnect, the helper reattaches you exactly where you left off. The helper is optional. Without it, the app works as a plain SSH client.

The terminal renders coding agents correctly. It handles diffs, spinners, and full-screen text interfaces. You can adjust the font, size, line height, padding, and colour scheme. The app has eight colour schemes and supports light and dark themes.

The app has a built-in SFTP file browser. You can walk the server’s filesystem, preview files, and edit them in a syntax-highlighted editor. You can upload files from your phone to the server and download files from the server to your phone.

You can save commands as snippets and run them on any machine. You can set up tunnels to reach dev servers. The app supports jump hosts, port forwarding, and keyboard-interactive auth for 2FA.

The app is free on Android today. There are no ads and no in-app purchases in this release. The iOS, Windows, macOS, and Linux clients are in the works but not released yet.

Conclusion

Running a coding agent on a server and checking it from a phone is possible. The hard part is the phone. The session must survive a locked screen, a network switch, or the app going to the background. The terminal must render diffs, spinners, and full-screen interfaces correctly. The app must let you send files, run saved commands, and reach dev servers through tunnels.

With the right setup, you can start a long job and check on it from anywhere. The agent stays alive, the terminal works, and the phone does not get in the way.

Generating OpenAPI specs without writing a single line of YAML

Mikołaj Badyl — Wed, 25 Feb 2026 16:20:55 +0000

If you've ever tried to write an OpenAPI spec by hand, you know how painful it is. Hundreds of lines of YAML, manual endpoint definitions, request/response schemas - and if your API changes, you have to update it all again.

I ran into this problem while building Octrafic. The tool requires an OpenAPI spec to understand your API structure - and not everyone has one. So I built a scanner that generates it automatically from your source code.

How it works

The scanner uses a pipeline called OOPS that works in four stages.

1. Framework detection

It starts by reading your root config files - go.mod, package.json, requirements.txt and so on. From that it figures out your language and web framework without touching the rest of your codebase.

2. Route discovery

Using heuristics specific to the detected framework, it finds exactly which files contain your routing logic and endpoint definitions. It skips everything irrelevant - node_modules, test directories, etc.

3. Parallel endpoint extraction

Instead of dumping your entire codebase into the LLM context, it isolates each routing file and queries the AI in parallel. This keeps token usage low and extraction fast. It pulls out methods, paths, summaries, and request/response payloads.

4. Spec generation

Everything gets aggregated and formatted into a valid OpenAPI 3.1 YAML file, ready to use.

Usage

One command:

octrafic scan -p ./my-backend-project -o api-spec.yaml

Once the scan finishes, you can immediately start testing:

octrafic -u http://localhost:8080 -s api-spec.yaml

CI/CD support

The scanner runs completely non-interactively, so you can wire it into your pipeline:

export OCTRAFIC_PROVIDER=claude
export OCTRAFIC_API_KEY=your_key_here
export OCTRAFIC_MODEL=claude-haiku-4.5
octrafic scan -p . -o spec.yaml

Why I built this

Octrafic lets you test APIs using plain English instead of writing test scripts. But it requires an OpenAPI spec to understand your API structure - without one, it can't work.

The scanner removes that barrier. You point it at your project, get a spec, and go straight to testing - without writing a single line of YAML.

It's open-source, still early, feedback welcome.

GitHub: github.com/Octrafic/octrafic-cli
Docs: docs.octrafic.com

Stop writing API test scripts. Use plain English instead.

Mikołaj Badyl — Tue, 24 Feb 2026 16:13:00 +0000

Writing API tests is tedious. You either click through Postman manually, write JavaScript test scripts, or wrestle with curl flags you forget every time.

I built Octrafic to fix that - you describe what you want tested in plain English, and the AI handles the rest. This is a quick guide on how to actually use it.

Installation

Single binary, no runtime dependencies.

# Linux/macOS
curl -fsSL https://octrafic.com/install.sh | bash

# Homebrew
brew install octrafic/tap/octrafic

# Windows
iex (iwr -useb https://octrafic.com/install.ps1)

Set up your AI provider

Octrafic supports Claude, OpenAI, OpenRouter, Gemini, Ollama, and llama.cpp. You bring your own API key - nothing goes through my servers.

Run octrafic for the first time and it'll walk you through the setup.

If you want to run everything locally without any API key, Ollama works great:

ollama pull qwen2.5:7b

Then point Octrafic at it during setup.

Load your API

octrafic -u https://api.example.com -s openapi.json -n "My API"

-u - your API base URL
-s - path to your OpenAPI/Swagger spec
-n - project name

Start testing

Once you're in the TUI, just describe what you want tested:

test the login endpoint with valid credentials
test the login endpoint with a wrong password
test creating a new user and check the response structure
run edge cases on the /users endpoint

The AI figures out the right HTTP method, URL, headers, and payload based on your spec. It executes the request and shows you the response with a pass/fail result.

Authentication

Pass auth via CLI flags when starting a session:

# Bearer token
octrafic -u https://api.example.com -s spec.json \
  --auth bearer --token "your-token-here"

# API key
octrafic -u https://api.example.com -s spec.json \
  --auth apikey --key X-API-Key --value "your-key-here"

# Basic auth
octrafic -u https://api.example.com -s spec.json \
  --auth basic --user admin --pass secret123

Or use environment variables if you don't want credentials in your shell history or project files:

export OCTRAFIC_AUTH_TYPE=bearer
export OCTRAFIC_AUTH_TOKEN=your-token-here
octrafic -u https://api.example.com -s spec.json

One important thing - your actual tokens and passwords are never sent to the AI. The AI only knows the auth type and header names. Your credentials stay on your machine.

Export your tests

After running tests interactively, you can ask the AI to export them:

export these tests to postman
export tests as a shell script
export to pytest and name it test_users_api.py

You can also export a test plan before executing it, useful if you just want to generate tests and run them later.

Files are saved to ~/Documents/octrafic/tests/.

Run tests in CI/CD

For pipelines, use the octrafic test subcommand - no TUI, no prompts:

octrafic test \
  --url https://api.example.com \
  --path tests/api-tests.json \
  --auth bearer \
  --token $API_TOKEN

Or generate and run tests from a prompt directly:

octrafic test \
  --url https://api.example.com \
  --spec openapi.json \
  --prompt "test all user endpoints"

Exits with 0 if all tests pass, 1 if anything fails.

GitHub Actions example:

- name: Run API tests
  run: |
    octrafic test \
      --url ${{ secrets.API_URL }} \
      --path tests/api-tests.json \
      --auth bearer \
      --token ${{ secrets.API_TOKEN }}

Save your project

By default, new sessions are temporary. Use /save to persist your project, or watch for the temp indicator in the status bar.

That's the basics. It's open-source and still early, so if something doesn't work or you have ideas, open an issue.

GitHub: github.com/Octrafic/octrafic-cli
Docs: docs.octrafic.com

I added CI/CD support to my natural language API testing CLI

Mikołaj Badyl — Fri, 20 Feb 2026 20:03:43 +0000

Today I shipped v0.4.0 of Octrafic. Here's what changed and why.

If you haven't seen it before - Octrafic is a CLI tool that lets you test APIs using plain English instead of writing test scripts. First post here.

The problem with the previous version

Octrafic worked well interactively. You'd open the TUI, describe what you want tested, get results. Fine for day-to-day use.

But if you wanted to wire it into a CI/CD pipeline, it just didn't work. The TUI would block, waiting for input that was never coming.

Headless mode

The main addition in v0.4.0 is the new octrafic test subcommand. It runs non-interactively - no TUI, no prompts.

You can either run an existing test file:

octrafic test \
  --url https://api.example.com \
  --path tests/api-tests.json

Or generate and run tests on the fly from a prompt:

octrafic test \
  --url https://api.example.com \
  --spec openapi.json \
  --prompt "test all user endpoints"

Exits with 0 if all tests pass, 1 if anything fails. Easy to plug into GitHub Actions or any other pipeline.

Export to Postman, curl, pytest

Once you've run your tests interactively, you can ask the AI to export them:

export these tests to postman
export tests as a shell script
export to pytest and name it test_users_api.py

The exported files include auth configuration too, so they work out of the box. Useful if you want to run them outside of Octrafic or commit them to your repo.

/save command and temp project indicator

Small thing, but it was causing real confusion - you'd close the session and lose everything because you didn't realize the project wasn't saved. There's now a clear indicator in the UI and a /save command to make it explicit.

Still a solo project, still early days. But it's getting more useful with every release.

GitHub: github.com/Octrafic/octrafic-cli
Website: octrafic.com
Docs: docs.octrafic.com
Full release notes: docs.octrafic.com/releases/v0.4.0.html

API Testing Tools in 2026: Why I Built My Own (After Comparing All the Popular Ones)

Mikołaj Badyl — Tue, 17 Feb 2026 21:47:45 +0000

After years of using Postman for nearly every project, I started noticing the friction. The mandatory login, the Electron window eating my RAM, the team plan that suddenly costs way more than it used to. So I started exploring alternatives - and I genuinely tried all the popular ones. Some were great, some surprised me, and a few solved problems I didn't even know I had.

But none of them solved the problem I cared about most: making API testing feel like a natural part of the development loop rather than a separate ritual you have to context-switch into. That frustration eventually led me to build Octrafic. Before I get to that, let me give you an honest rundown of what's out there.

The Landscape: An Honest Comparison

Postman

Postman is the undisputed industry standard, and for good reason. The ecosystem is mature - collections, environments, team workspaces, mock servers, monitors, documentation generation. If your company is onboarding a team of 20 engineers onto a shared API workflow, Postman is probably still the answer.

The problem is that Postman has been aggressively moving upmarket. The free tier keeps shrinking, the desktop app requires you to be signed in, and it's noticeably resource-heavy for what is fundamentally an HTTP client. If you're a solo developer or a small startup, you're paying enterprise prices for features you'll never touch.

Best for: Enterprise teams with a real budget and a need for collaboration features.

Insomnia

Insomnia was my go-to replacement for a while. It's genuinely lighter than Postman, has a clean UI that stays out of your way, and its GraphQL support is excellent - auto-completion from your schema, query builders, the works.

The anxiety around Insomnia is mostly about ownership. Kong acquired it a few years back, and since then there have been some controversial moves around syncing and account requirements. The community forked it into Insomnium as a response. If you're okay with the uncertainty, it's a solid tool. If you want something more stable long-term, that uncertainty is a real factor.

Best for: Solo developers, especially those working with GraphQL.

Thunder Client

Thunder Client is a VS Code extension, which is either its biggest strength or a dealbreaker depending on your workflow. If you live in VS Code, and a lot of developers do, having your HTTP client as a sidebar panel is genuinely ergonomic. No context switching, no separate window, requests sit right next to your code.

The tradeoff is that you're in VS Code for everything. Advanced scripting, pre-request flows, CI/CD integration - Thunder Client handles the basics well but starts to feel limited for anything complex. It also means you're tied to the VS Code ecosystem.

Best for: Developers who use VS Code as their primary environment and mostly need quick endpoint validation.

Hoppscotch

Hoppscotch is impressive as a piece of software. It's fully open-source, runs in the browser, has a modern UI, and you can self-host the entire thing. There's no installation, which makes it great for quickly sharing a request with a teammate or testing something on a machine you don't control.

The limitation is that "runs in the browser" is both its superpower and its constraint. Offline capability is limited, and anything involving local environments or internal APIs requires some extra setup (their self-hosted agent). For pure open-source enthusiasm and accessibility, it's hard to beat.

Best for: Quick ad-hoc tests, teams that want a self-hostable open-source option, situations where installation isn't possible.

Bruno

Bruno is the tool that's gotten the most traction among developers frustrated with Postman's direction. Its core idea is elegant: API collections are stored as plain text files on your filesystem, which means they live in your Git repo alongside your code. No cloud sync required, no proprietary format.

It's offline-first by design, the UI is clean, and the philosophy resonates with developers who care about owning their data. The main caveat is that it's a newer tool - the ecosystem is smaller, some edge cases feel rough, and advanced scripting is still maturing. But the trajectory is good.

Best for: Teams that want their API collections version-controlled in Git, developers who want to avoid cloud lock-in.

The Gap I Kept Hitting

After going through all of these, I had a clear picture of the tradeoffs. But I kept running into the same wall, regardless of which tool I was using.

Manual GUI testing is fine when you're exploring a new API. But when you're deep in development - building a feature, refactoring an endpoint, dealing with a regression - the workflow becomes repetitive and tedious. Click, fill in params, click send, check response, repeat. Writing actual test scripts requires learning each tool's specific scripting API, which is its own investment.

More fundamentally: automation felt like an afterthought in all of these tools. The core experience is built around clicking through a GUI, and scripting/CI integration is layered on top. What I wanted was the inverse - a tool where automation and repeatability are the primary experience, and the interface facilitates that rather than fighting it.

I also noticed that nobody was taking AI seriously in this space. Not in a meaningful way, anyway. There were some autocomplete features here and there, but nothing that actually changed the testing workflow.

Why I Built Octrafic

So I built Octrafic - an AI-powered CLI tool for API testing, written in Go, fully open-source.

The core idea is simple: instead of clicking through a GUI or writing test scripts in a proprietary DSL, you describe what you want to test in plain English and the AI agent handles the execution.

# Start an interactive session against your API
octrafic --url https://api.example.com --spec path/to/spec

Then just describe what you want:

> Check if the /users endpoint returns paginated results with proper metadata
> Test that creating a user with a duplicate email returns a 409 conflict
> Verify that the authentication token expires after the documented TTL

The agent figures out what requests to make, runs them against your real endpoints, validates the responses, and tells you what it found. No test script to write. No learning a new assertion syntax.

If you have an OpenAPI spec, you can import it and Octrafic immediately understands your full API surface - endpoints, parameters, schemas, expected responses. This makes testing substantially more precise since the AI has context about what your API is actually supposed to do.

octrafic --spec ./openapi.yaml --url https://api.example.com

A few things I want to be upfront about: Octrafic requires your own LLM API key (OpenAI, Anthropic, or any OpenAI-compatible provider including local models via Ollama). The AI-powered workflow is powerful but different from traditional testing - it's better suited to exploratory and regression testing than to pixel-perfect assertion-based test suites. It's also a young project. Version 0.3.3 is out, and I'm actively building in public.

Side-by-Side Comparison

Tool	Type	Pricing	Standout Feature	AI-Powered	Open Source
Postman	GUI Desktop	Free / Paid plans	Team collaboration, full ecosystem	Partial	No
Insomnia	GUI Desktop	Free / Paid plans	GraphQL support, clean UI	No	Yes (forked)
Thunder Client	VS Code Extension	Free / Paid plans	IDE integration, zero setup	No	Partial
Hoppscotch	Web / Self-hosted	Free / Paid plans	No install, self-hostable	No	Yes
Bruno	GUI Desktop	Free	Git-friendly collections as files	No	Yes
Octrafic	CLI	Free (bring your own LLM key)	Natural language testing, CLI-first	Yes	Yes (MIT)

Where This Leaves Us

Every tool in this list has a legitimate use case. Postman makes sense for large engineering teams who need shared workspaces and are willing to pay for it. Thunder Client is the obvious choice if you're in VS Code all day and just need fast endpoint validation. Bruno is compelling for teams who want their API collections to live in Git like everything else.

I built Octrafic because I believe the future of API testing is conversational and automation-first. Describing what you want to verify and having an AI agent execute it is a fundamentally different experience than clicking through a GUI - and it fits better into how development actually flows when you're deep in a feature.

If that sounds useful, the project is open-source on GitHub and I'd genuinely appreciate feedback from people trying it on real APIs. And if you're happy with one of the other tools, that's completely valid - I still think Bruno and Hoppscotch are excellent.

Octrafic on GitHub · Documentation · octrafic.com

I Built an AI CLI That Lets You Chat With Your APIs

Mikołaj Badyl — Wed, 11 Feb 2026 00:10:35 +0000

Tired of writing Postman test scripts? I built Octrafic - a CLI tool where you describe API tests in plain English and AI executes them. It's open-source, runs locally, and supports multiple LLM providers.

Why I Built This

API testing sucks. You're either:

Clicking through Postman manually (doesn't scale)
Writing JavaScript test scripts (tedious boilerplate)
Using curl and forgetting the syntax every time

I wanted something faster: load your API spec, describe what you want tested, get results. The AI figures out the right HTTP requests, payloads, and validations.

How It Works

1. Install (single binary, no dependencies)

# Linux/macOS
curl -fsSL https://octrafic.com/install.sh | bash

# Homebrew
brew install octrafic/tap/octrafic

# Windows
iex (iwr -useb https://octrafic.com/install.ps1)

2. Configure your AI provider
Octrafic supports Claude, OpenAI, OpenRouter, Ollama, or llama.cpp. You bring your own API key - nothing goes through my servers.

# Run
octrafic

3. Load your API

octrafic -u https://api.example.com -s openapi.json -n "My API"

4. Start testing
The AI understands your API structure and generates appropriate requests based on natural language:

Technical Stack

Go - Single binary distribution across Linux, macOS, Windows. No runtime dependencies.

Bubble Tea - Terminal UI framework for interactive chat interface. Arrow key navigation, command history, proper scrolling.

Multi-LLM Support - Built adapters for Claude, OpenAI, OpenRouter, Ollama, and llama.cpp. Switch providers without changing your workflow.

Real Use Cases

API Exploration - Point it at an unfamiliar API and ask questions. What does this endpoint do?
What parameters does it accept?
Faster than reading docs.

Quick Testing - Test this endpoint with edge cases generates multiple requests with boundary conditions, missing fields, invalid data types.

Manual Testing Alternative - Instead of clicking through Postman, describe what you want tested. The AI executes and shows results.

Local Models - Privacy-focused? Run Ollama or llama.cpp locally. Your API data never leaves your machine.

Current State

It works. I use it daily for API testing. A few other developers are using it too.
That said, it's alpha software. Some features are rough. But the core is solid and I'm actively fixing issues.

GitHub repo: https://github.com/Octrafic/octrafic-cli
Website: https://octrafic.com
Try it. Open issues for bugs. PR's welcome if you want to contribute.