{
  "id": 18531747,
  "title": "Two Free Adapters, One Contract to Test",
  "url": "https://urgent.news/2026/11/06/two-free-adapters-one-contract-to-test",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-06T17:09:31.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/codepro_4664/two-free-adapters-one-contract-to-test-4o2d"
  },
  "original_language": "en",
  "account": "Two free adapters and a single contract are required to test the free model and server options. Before committing to any vendor, it is essential to establish constraints through a constraint interview. Every free dependency must be scrutinized in three ways: capacity, boundary behavior, and dependencies on system components.\n\nMonkeyCode offers a free model and server option, with a starting budget of 10 million free tokens. Confirm the current number in your dashboard before planning anything, as numbers can change. Both latency and model identity are harder to verify upfront, so label them as unknown in your design. It is better to have an honest unknown than a false assumption that becomes a false assumption in testing.\n\nDesign the data flow with two separate lanes: one for token usage and another for compute usage. These lanes should fail for different reasons, so keep them apart. The API calls the model lane on request, while the worker calls the server lane on a schedule. Both lanes sit behind interfaces you own.\n\nIn your interface, export a usage object with inputTokens and outputTokens, an inferencePort function that handles completion requests, and a runtimePort function that runs jobs. There should be no throw for expected failures, as running out of tokens is normal on a free tier. Instead, return a value indicating the issue. Keep the shape of your adapter, swapping in the real endpoint and header names.",
  "summary": "Two Free Adapters, One Contract to Test A free tier is a contract, not a promise. Write the contract down first. Then test it before you build on it. Most teams do this backwards. They wire the free endpoint into the app, ship, and learn the rules when something breaks. That is not architecture review. That is archaeology after the outage. This is an architecture review you can run this week. Two…",
  "key_points": [
    "Two free adapters required to test model and server options",
    "Constraint interview needed to establish constraints",
    "Separate lanes for token and compute usage in design"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}