Checklist
Test API portability with a behavior contract
A reusable worksheet for comparing the responses your application depends on when two servers expose similarly named endpoints.
THE SHORT ANSWER
Matching endpoint names reduce integration work; matching application behavior still needs a test.
Compatibility has a scope
Simon Willison’s archived post asks what API clones inherit when the original interface changes. The llama.cpp server documentation provides a concrete example: it lists compatibility endpoints and qualifies the strength of its compatibility claim. The practical question is therefore narrower than “does this support the API?” Ask which request and response behaviors your application actually relies on.
Write the smallest contract
Select one normal request and one failure case from your application. Record required fields, optional fields you read, streaming termination and error handling. If the application uses tools, include argument parsing and tool-result ordering. State whether a difference is acceptable, needs an adapter or blocks migration. Avoid adding every feature a provider advertises; a large unused checklist can hide the behavior that matters.
Keep the migration evidence
Run the same saved requests against explicitly named server versions only when you are ready to test. Preserve raw responses with secrets removed and inspect the application’s final behavior as well as HTTP success. The worksheet is an original starting point; no cross-provider calls were made here. Revisit it when either side changes rather than assuming a successful smoke test grants permanent portability.
Put it to work.
- List the behaviors you consume.
- Include one error case.
- Inspect streaming completion.
- Version the saved contract.
Take the template.
Original CooScope text for your own working notes. Fill in the blanks with evidence from your task.
CooScope — API behavior contract Original portability worksheet; consult the linked server documentation. Application operation: [operation] Server/model revisions: [A] / [B] Saved request: [redacted fixture] Required response fields: [list] Streaming completion rule: [rule] Tool argument/result expectations: [rule or not used] Expected error case: [input and handling] Observed differences: [record after testing] Decision: [compatible/adapter needed/blocked] Limit: this contract covers listed application behaviors only. Evidence context: https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
Go to the source.
Original material, with its own scope and publication date. This note is an explanation, not a CooScope performance test.
Source published · Editorial review
Archived English post text; primary sources reviewed separately. Generated annotations, media and missing replies are outside the evidence scope.
- @simonw — archived X post (2025-03-11)
- llama.cpp — Server API documentationLink / source review: 2026-10-15