There is no way currently to temper the threshold or amount of data being fed to the AI. Your assistant would permanently know about icons when chatting, because “create assistant” created it with connection to the file IDs.
You would have to disengage files with “modify assistant” - a pointless function to use in runtime when you can’t know when your file will be relevant to a user’s chat query.
If a retrieval file or collection is uploaded and connected to an assistant, and the file is small enough to fit into the (>10000 word) context length of the model used, it will be included every time. Otherwise chunked to fill up the context available.
There is apparently no distinguishing files meant for code interpreter from retrieval; they are just attached to the assistant. If you meant for a csv to be available to be processed by code interpreter, it would also be fed into the AI context.
About the only way you can moderate your expenses a bit is to use GPT-3.5-turbo-0613 as your assistant model selection, thus giving the assistant backend less context window length to experiment with. That should result in the document being chunked if over the available context, and gets you also less charges per token if AI agent goes bonkers and iterates multiple times, or simply repeats phrases or produces nonsense for the remainder of the unspecify-able max_tokens.
example input context per internal call within run:
gpt-3.5-turbo-1106 | $0.0010 / 1K tokens x 14.5 = $0.0145
or
gpt-3.5-turbo-0613 | $0.0015 /1K tokens x 3.5 = $0.00525
assuming a max_tokens (or limit of encroachment into generation context length area) similar to ChatGPT.
(Multiply by 10x the input cost, then multiply 8x the input length for what specifying gpt-4-turbo could net you.)