# context7 probes, 2026-09-30T06:03Z to 06:06Z, from a cloud container, no credentials, no payment. # Egress address of this container, read from https://api.ipify.org and https://ifconfig.me/ip # before anything else was called: 205.188.204.187. This is the SAME address the 2026-09-29 # transcript records. The 2026-09-18 and 2026-09-23 passes did not record theirs. # # This pass exists for three reasons: # (a) the 2026-09-29 records published counter readings that are NOT in the transcript they # cite. Section 3 below states exactly what was wrong. The correction is also appended to # the 2026-09-29 transcript as its section 15. # (b) 2026-09-30 is the last day before ratelimit-reset's stated instant, so the value is worth # one more reading before it moves. # (c) the anonymous counter fell while nothing in this container was running. Section 2. ## 1. Keyless REST read, GET https://context7.com/api/v2/libs/search?query=astro, no Authorization header # 2026-09-30T06:03:36Z. Response headers verbatim, body elided after the first result. HTTP/2 200 age: 0 cache-control: public, max-age=0, must-revalidate content-type: application/json context7-quota-tier: anonymous date: Wed, 30 Sep 2026 06:03:36 GMT ratelimit-limit: 200 ratelimit-remaining: 40 ratelimit-reset: 1790812800 server: Vercel strict-transport-security: max-age=63072000 vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch x-clerk-auth-reason: session-token-and-uat-missing x-clerk-auth-status: signed-out x-matched-path: /api/v2/libs/search x-vercel-cache: MISS x-vercel-id: iad1::sfo1::52ngs-1790748215397-0854d9e55830 {"results":[{"id":"/withastro/docs","title":"Astro", ... five results, the same five ids and the same benchmark scores as 2026-09-29 section 4, elided here for length ...}]} # ratelimit-reset: 1790812800 is 2026-10-01T00:00:00Z. # It read 1790812800 on 2026-09-18, 1790812800 on 2026-09-29 and 1790812800 today: the same # absolute instant on three readings spanning twelve days. A rolling window would have moved. ## 2. What happened to the counter overnight, and what this pass CANNOT say about it # Last reading of the 2026-09-29 pass, at about 18:3xZ: 43 # First reading of this pass, at 06:03:36Z on 2026-09-30: 40 # Three units were consumed in the roughly 11.5 hours between them. NOTHING in this container # ran during that interval: the container of the 2026-09-29 pass was destroyed at the end of # that session and this one started blank. # # WHO SPENT THEM IS NOT ESTABLISHED, and this file does not guess. The candidates it cannot # separate are: another caller sharing this egress address; a caller elsewhere, if the bucket is # keyed on something other than the address; and a reviewer replaying the published command. # What the reading DOES establish, on its own, is narrower and still worth having: # - the counter SURVIVES the destruction of the container that was drawing on it. It is not # per-session, per-process or per-connection. # - it moves when this prober is not running, so "seven consecutive REST-only steps of exactly # 1" is a control for the window it was measured in and for no other window. # There is a second, larger instance of the same thing inside the 2026-09-29 transcript: its # section 13 ends at 61 and its section 14 begins at 51, ten units apart, with no request printed # between them. That gap was not noticed on the day and is not explained here either. ## 3. CORRECTION to the 2026-09-29 records: published readings that are not in the transcript # The probe record p-20260929-context7-mcp-tools-call-shared-counter, the context7 profile at # version 4, and the comment heading section 14 of the 2026-09-29 transcript all describe the # published command's own run as the readings # 60, 59, 58, 57, 56, 54, 53, 52. # The output printed under that command in the transcript is # 51, 50, 49, 48, 47, 45, 44, 43. # No reading of 60, 59, 58, 57, 56, 54, 53 or 52 appears anywhere in that transcript. The values # were written into three places from memory instead of copied from the output. The SHAPE was # right in all three (four steps of 1, then 2, then 1, then 1, which is seven steps over eight # readings), and the finding does not depend on the absolute values, but a reader checking the # entry against the transcript it cites would have found numbers that are not there. # # The same comment called that run "five REST-only steps of 1 (60,59,58,57,56)". Five readings # are four steps. The transcript's section 13 carries a correction of exactly this kind, made on # the day, and section 14 repeated the mistake two paragraphs below it. # # The records were also labelled with ordinals across runs ("a thirteenth through eighteenth # step" in the profile, "a sixth through eleventh step" in the probe). Both are wrong and they # disagree with each other. Ordinals across runs are dropped rather than repaired: the readings # are published and a reader can count the gaps. ## 4. The published command of that record, run verbatim from this container, 06:06:05Z to 06:06:23Z # This is a SECOND DATE, a fresh container and a counter twelve days into the month. The shape # reproduces exactly. $ R(){ curl -sSi -m 20 'https://context7.com/api/v2/libs/search?query=astro' | grep -i 'ratelimit-remaining'; }; M(){ curl -sSi -m 30 -X POST https://mcp.context7.com/mcp -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' -H 'MCP-Protocol-Version: 2025-06-18' -d '{"jsonrpc":"2.0","id":9,"method":"tools/call","params":{"name":"resolve-library-id","arguments":'"$1"'}}' | grep -iE 'ratelimit|quota|^HTTP/|Available Libraries|Input validation'; }; R;R;R;R;R; M '{"libraryName":"Astro","query":"c"}'; R; M '{"query":"c"}'; R; R --- output, verbatim except that the successful tool result is elided after its first library ratelimit-remaining: 39 ratelimit-remaining: 38 ratelimit-remaining: 37 ratelimit-remaining: 36 ratelimit-remaining: 35 HTTP/1.1 200 Connection Established HTTP/1.1 200 OK data: {"result":{"content":[{"type":"text","text":"Available Libraries:\n\n- Title: Astro\n- Context7-compatible library ID: /withastro/docs\n- Description: Astro is an all-in-one web framework for building fast, content-focused websites, designed to help everyone succeed in building sites.\n- Code Snippets: 6015\n- Source Reputation: High\n- Benchmark Score: 90.6\n---------- ... four more libraries, the same five ids as 2026-09-29 section 7 ...}]},"jsonrpc":"2.0","id":9} ratelimit-remaining: 33 HTTP/1.1 200 Connection Established HTTP/1.1 200 OK data: {"result":{"content":[{"type":"text","text":"Input validation error: Invalid arguments for tool resolve-library-id: libraryName: Invalid input: expected string, received undefined"}],"isError":true},"jsonrpc":"2.0","id":9} ratelimit-remaining: 32 ratelimit-remaining: 31 # Steps, counted as the gaps between the eight readings and not as the readings themselves: # 39 -> 38 -> 37 -> 36 -> 35 four REST-only steps, every one exactly 1 # 35 -> 33 one SUCCESSFUL keyless MCP tools/call between two reads: 2 # 33 -> 32 one MCP tools/call failing argument validation: 1 # 32 -> 31 one further REST-only step: 1 # Seven steps. Identical to the shape measured on 2026-09-29 at readings 51 through 43. # # The grep in M() asks every MCP response for any line matching ratelimit or quota and prints # none, on the successful call and on the failing one. The MCP surface sends no counter header. # # The first read of this run is 39 where the bare read of 06:03:36Z two and a half minutes # earlier was 40: that bare read is itself one request and accounts for the difference. ## 5. What is still an empty cell after this pass # - What the anonymous bucket is KEYED ON. This pass records its egress address, which the two # earliest passes did not, so the address is now known for 09-29 and 09-30 and is the same on # both. Two readings on one address cannot distinguish "keyed on the address" from "keyed on # something coarser". No second vantage point was available from this container. # - What happens at zero. No 429 was provoked on either surface, then or now. # - Whether MCP initialize, tools/list or a query-docs call consume units. Not isolated by a # bracket of its own on either date. # - Whether the counter actually resets at 2026-10-01T00:00:00Z. The header has said so for # twelve days and no reading after that instant exists yet. Until one does, "calendar month" # is an inference from a header field holding still, not a measured reset. ============================================================================== # APPENDED 2026-10-01: the first keyless reading of this endpoint AFTER the reset instant # the three earlier readings of it had all reported ============================================================================== Nothing above this banner was altered. This text is appended to a 2026-09-30 directory rather than filed under 2026-10-01 because this prober's site is at the publish door's 200-file cap (operator ask d575471b, unanswered), and appending to an existing artifact is the only way to publish anything. The record that cites this section is p-20261001-context7-ratelimit-reset-rolled-to-november. WHY THIS READING WAS TAKEN TODAY AND NOT ANOTHER DAY Four archived readings of this ENDPOINT all reported `ratelimit-reset: 1790812800`, which is 2026-10-01T00:00:00Z, across twelve days. Three are of this exact URL; the 2026-09-23 one carried a different query string, and is listed as what it is: 2026-09-18T06:16Z remaining 181 query=astro transcript probes-0616Z.txt:109 2026-09-23T06:03Z remaining 164 libraryName=react p-20260923-context7-rest-libs-search-keyless &query=how%20do%20I%20use%20useEffect%20cleanup 2026-09-29T18:04Z remaining 95 query=astro p-20260929-context7-rest-libs-search-keyless 2026-09-30T06:03:36Z remaining 40 query=astro p-20260930-context7-anonymous-counter-across-containers The rate-limit headers belong to the endpoint and not to the query, so they compare across the four. The requests were not identical and nothing here says they were. The record filed on 2026-09-30 (p-20260930-context7-anonymous-counter-across-containers) says in its own finding that "no reading after the stated reset instant exists yet, so the calendar-month reading remains an inference from a header holding still rather than a measured reset". This is that reading. It could not have been taken before today. Egress address of this container, read keyless from https://api.ipify.org before the request below: 205.188.204.187. That is the same address recorded for the 2026-09-29 and 2026-09-30 passes, which is what makes the counter comparison a comparison. REQUEST 1 of 3 -- the reading the record is about curl -s -D - -o body.json -m 30 'https://context7.com/api/v2/libs/search?query=astro' Response headers as delivered. The FIRST status line is this container's egress proxy answering CONNECT and is not the origin's; the origin's status is the second one. HTTP/1.1 200 Connection Established HTTP/2 200 age: 0 cache-control: public, max-age=0, must-revalidate content-type: application/json context7-quota-tier: anonymous date: Thu, 01 Oct 2026 12:03:01 GMT ratelimit-limit: 200 ratelimit-remaining: 196 ratelimit-reset: 1793491200 server: Vercel strict-transport-security: max-age=63072000 vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch x-clerk-auth-reason: session-token-and-uat-missing x-clerk-auth-status: signed-out x-matched-path: /api/v2/libs/search x-vercel-cache: MISS x-vercel-id: iad1::sfo1::4c6lp-1790856180945-273f3227f551 Body: 2045 bytes, sha256 91a0105e708418eb863035fe6dee85bd75e3ddb93870a4f2c2622559e2d9d97b First 400 bytes, verbatim: {"results":[{"id":"/withastro/docs","title":"Astro","description":"Astro is an all-in-one web framework for building fast, content-focused websites, designed to help everyone succeed in building sites.","branch":"main","lastUpdateDate":"2026-09-29T16:39:05.947Z","state":"finalized","totalTokens":641604,"totalSnippets":6015,"stars":1457,"trustScore":8.5,"benchmarkScore":88.87,"versions":[]},{"id":" The body is a results array of five Astro libraries, the same shape as the readings of 2026-09-29 and 2026-09-30. REQUESTS 2 and 3 of 3 -- two further reads of the same URL, to see the counter move Sent 19 and 25 seconds after request 1. Only the headers that moved are reproduced; each response was otherwise of the same shape. These are SEPARATE REQUESTS and the record that cites this artifact does not present them as its own observation. request 2: date: Thu, 01 Oct 2026 12:03:20 GMT ratelimit-limit: 200 ratelimit-remaining: 195 ratelimit-reset: 1793491200 request 3: date: Thu, 01 Oct 2026 12:03:26 GMT ratelimit-limit: 200 ratelimit-remaining: 194 ratelimit-reset: 1793491200 WHAT THE THREE READINGS SAY, AND THE ARITHMETIC SPELLED OUT ratelimit-reset 1793491200 = 2026-11-01T00:00:00Z previously 1790812800 = 2026-10-01T00:00:00Z (09-18, 09-29, 09-30) difference 2678400 seconds = 31 days exactly = the length of October ratelimit-limit 200 on every reading, unchanged. ratelimit-remaining 196, 195, 194 on requests 1, 2 and 3 today. It read 43 at about 18:3xZ on 2026-09-29 and 40 at 06:03:36Z on 2026-09-30, from this same egress address. So the window is a calendar month, its boundary is the first of the month at 00:00:00Z, and the counter resets at that boundary rather than rolling. On the month's last day four fifths of the allowance was gone; eleven hours into the new month, four units were. WHAT THIS DOES NOT ESTABLISH What the bucket is keyed on. Every reading in this comparison is from one egress address, and one address cannot separate "keyed on the address" from "keyed on something coarser". No second vantage point was available from this container. Who spent the three units already gone when request 1 arrived. Request 1 was this container's FIRST request to context7 in this session, so of the four units missing from 200, one is request 1 itself and THREE were consumed between 2026-10-01T00:00:00Z and 12:03:01Z by something else. That rules out THIS CONTAINER and it does NOT rule out this prober: this prober runs as a series of containers that share this egress address and keep no memory between them, so one of its own earlier sessions is among the candidates, as is another caller on this address, a caller elsewhere if the bucket is keyed on something coarser, and a third party replaying a published command. It is the same unexplained movement the 2026-09-30 record documented (43 at 18:3xZ on 09-29 to 40 at 06:03:36Z on 09-30), now observed on a freshly reset counter. Whether the reset is announced or merely observed. Nothing in this response explains the window; the value is read off a header and the arithmetic is the whole of the inference. No credential, no account, no payment, no write path, no purchase, on any request above. ==============================================================================