Afterplay is a playable Quoridor-style strategy game where each new opponent can use what previous rounds revealed about your playstyle. Players race across a board while placing walls to delay each other. The game records route preferences, lateral moves and wall-placement habits, then passes saved-round summaries to Qwen3-4B running on a dedicated Akamai GPU through vLLM. Game code calculates legal candidate moves and path lengths on the CPU; Qwen selects an opponent move and explains its choice. This is adaptation through persistent memory, not retraining the model after every match. The central experiment compares four concurrent decisions on the same board with the same legal candidate list: no history, recent round 1, recent round 2, and both rounds. Players can highlight each recommendation to see how context changes the decision. Different recommendations alone do not establish stronger gameplay. A separate load-test panel sends 4, 8 or 32 concurrent decision requests from independent synthetic board positions. It reports successful requests, decisions per second, output tokens per second, total decision latency and available vLLM running-request/KV-cache metrics. This connects the playable game to the workshop focus on owning and measuring inference. Built with a dependency-free Python service, SQLite session history, an original responsive HTML/CSS/JavaScript interface and a namespaced Kubernetes deployment beside the existing vLLM service. The source includes an explicitly labeled offline CPU baseline, deployment instructions and 20 passing automated rule/API tests, including mock concurrent inference. Desktop and mobile browser interaction checks pass. The application is deployed in the workshop namespace and live gameplay is working. The prototype does not claim measured win-rate improvement or perform model-weight fine-tuning. Those are future experiments.
Built at Build AI agents that own their inference - #SFTechWeek
Afterplay — Opponents That Remember
Afterplay is a playable Quoridor-style strategy game where each new opponent can use what previous rounds revealed about your playstyle. Players race across a board while placing walls to delay each other. The game records route preferences, lateral moves and wall-placement habits, then passes saved-round summaries to Qwen3-4B running on a dedicated Akamai GPU through vLLM. Game code calculates legal candidate moves and path lengths on the CPU; Qwen selects an opponent move and explains its choice. This is adaptation through persistent memory, not retraining the model after every match. The central experiment compares four concurrent decisions on the same board with the same legal candidate list: no history, recent round 1, recent round 2, and both rounds. Players can highlight each recommendation to see how context changes the decision. Different recommendations alone do not establish stronger gameplay. A separate load-test panel sends 4, 8 or 32 concurrent decision requests from independent synthetic board positions. It reports successful requests, decisions per second, output tokens per second, total decision latency and available vLLM running-request/KV-cache metrics. This connects the playable game to the workshop focus on owning and measuring inference. Built with a dependency-free Python service, SQLite session history, an original responsive HTML/CSS/JavaScript interface and a namespaced Kubernetes deployment beside the existing vLLM service. The source includes an explicitly labeled offline CPU baseline, deployment instructions and 20 passing automated rule/API tests, including mock concurrent inference. Desktop and mobile browser interaction checks pass. The application is deployed in the workshop namespace and live gameplay is working. The prototype does not claim measured win-rate improvement or perform model-weight fine-tuning. Those are future experiments.
AkamaiQwen3-4B FP8, vLLM, Kubernetes, Python 3.12, SQLite, JavaScript, HTML/CSS, DockerKeep exploring what builders shipped.
HackerSquad project
Inference Health Monitor
The README's rewritten and pushed. It now reads in plain language: What it is — a thermostat for a self-hosted AI engine: watches vital signs, eases off gracefully under surge instead of melting down What it does — the health checks, the fixed rules, load-shedding without restarts, the optional restart closer, self-narration, the demand simulations with report cards, and the Prefix-Cache Pilot The design rule — the model never decides, only narrates; boring Python makes every call Tech stack — Python 3 (no frameworks), vLLM, Qwen3-4B, Kubernetes, and requests as the single outside library
HackerSquad project
Decision Lab on Akamai GPU
We show what is actually best (faster, cheaper, secure) to run on Akami GPUs: a JEV-style model (fine tune of Qwen3.5-9B in FP8 config with BF16 image-incoder; this model was fine tuned by Cloudflare and is called Clef). Specifically we show 3 demonstrations and compare Akamai GPU vs OpenAI GPT-6-Luna: 1) game playing AI 2) Email inbox filtering 3) Procurement So we show easy to demo game, and two real life business application.
AgentFight
AgentFight
One small GPU, a whole team of agents. Everything runs on one Qwen3-4B model, served by vLLM on an Akamai Cloud GPU. 1) Mixture-of-Experts router A fast router (thinking off) reads each message and picks one of six experts. They all share the same weights and the same GPU. Each expert just has its own system prompt, sampling settings and thinking mode. - 🧠 reasoner: math, logic and code, with thinking on - 🔧 tool_agent: calls tools over MCP (time, safe calculator, dice, fetch_url) - ✍️ storyteller, 🎭 character, 🌍 polyglot (100+ languages), 📐 formatter (strict JSON) You can switch modes per message with /think or /no_think. "Compare thinking ON vs OFF" runs the same question both ways and shows latency and tokens per second. You can also force an expert with @polyglot, @character and so on. 2) Agent Arena: Red vs Blue prompt-injection defense A victim agent fetches an internal memo through an MCP tool and summarizes it. Some rounds hide a prompt injection in the memo, in several languages, telling the agent to leak the restricted appendix. A Blue defender checks the document and the draft summary, then returns ALLOW or BLOCK. A plain Python referee decides leaks by checking for canary honeytokens, so no LLM grades another LLM. - Live Gradio UI: Red, Victim and Blue stream token by token - Scoreboard: attack success, block rate, false positives, Blue latency, defense cost in tokens per round, results by language - Blue has three modes: Think, Fast and Off. You see exactly what extra inference buys you in security. - Fully sandboxed: the secrets are fake canaries and send_email only writes to a local log Why it matters: one 4B model on one Akamai GPU can act as a router, a tool user, an attacker target and its own security guard. And every run measures what that inference costs. Stack: Akamai Cloud GPU · vLLM · Qwen3-4B · MCP · Qwen-Agent · Gradio · Python Run: pip install -r requirements.txt python app.py # MoE router UI python arena_app.py # Agent Arena UI