Development record
A request sent through the OpenAI-compatible provider adapter is never judged against the chosen model's size before it is sent. In a user test on 2026-10-03, an intent consistency check sent to a keyless local service carried about 29,300 tokens against a model the service runs at about 29,200, and the service refused it with HTTP 400, about 0.5% over. Some servers publish each model's served size in their model list; the standard list has no such field, and a published figure may be the trained size rather than the served one. Routed out of the guided-connect draft itd-2610030821294016 by its record review; a follow-up of the adapter's streaming fix captured the same day.
A request sent through the OpenAI-compatible provider adapter is never judged against the chosen model's size before it is sent. In a user test on 2026-10-03, an intent consistency check sent to a keyless local service carried about 29,300 tokens against a model the service runs at about 29,200, and the service refused it with HTTP 400, about 0.5% over. Some servers publish each model's served size in their model list; the standard list has no such field, and a published figure may be the trained size rather than the served one. Routed out of the guided-connect draft itd-2610030821294016 by its record review; a follow-up of the adapter's streaming fix captured the same day.
Grounds
- pursued: a vLLM request whose /tokenize count plus max_tokens exceeds max_model_len is refused before the chat call; every other request, including one only a bytes estimate puts over, is sent unchanged and the server's own refusal is kept, as size_test.go's fake-server tests prove. What would show it wrong: a vLLM version whose /tokenize count differs from the prompt its chat endpoint judges, or which refuses on a different sum.
Frontmatter
| id | iss-2610030956156354 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610030956156354-a-request-sent-through-the-openai.md
open on GitHub ↗ · commit history ↗
mentions4
- dcn-26100900000000012026-10-09 — Rulings of the product thinker on the three hand-backs of the 2026-10-07/08 autonomous drain (asked by abcd-0b, one question at a time, answers verbatim): (1) iss-2609251618079479, whether the build-sequence chapter's build-milestone sense retires with the phase: "Rewrite in today's terms" — 06-delivery/01-build-sequence.md stays a current chapter, its build order restated as dependencies with no milestones (neither retired as history nor kept as a second sense of the word). (2) iss-2610040758569116, whether an agent may run 'abcd decide accept', which stamps the person's git name as accepted_by: "Agents too, disclosed" — no guard block as for 'source ledger --flip'; the commit's Assisted-by trailer is the disclosure. (3) iss-2610030956156354's open design point, whether a step still falls back to the agent harness when the size count already sent the brief to the person's own model server and the chat call then fails: "Move to the harness" — no answer received is the trigger, not nothing sent; recorded as iss-2610090701491123, since the resolved fix stops instead.
- iss-2610090701491123The product thinker ruled on 2026-10-09 that once abcd has sent a brief to the person's own model server for the size count, a later failure before any answer still moves the step to the agent harness: 'no answer received' is the trigger, not 'nothing was sent'. Today the adapter stops with an error instead, because the fix for iss-2610030956156354 stopped reporting such a failure as unreachable, and only an unreachable error falls back (internal/core/oracle/dispatch.go FellBack).
- itd-2610030821294016Connecting a model service from inside your coding session looks up the details and offers the choices
- spc-2610031241482088connecting-a-model-service-from-inside-claude-code-works-out